web常见的攻击方式
web攻击定义
Web攻击(WebAttack)是针对用户上网行为或网站服务器等设备进行攻击的行为
- 一般攻击方法:植入恶意代码,修改网站权限, 获取网站用户隐私信息等等
- 常见的web攻击方式:
- XSS (Cross Site Scripting) 跨站脚本攻击
- CSRF(Cross-site request forgery)跨站请求伪造
- SQL注入攻击
XSS
XSS,跨站脚本攻击,允许攻击者将恶意代码植入到提供给其它用户使用的页面中
XSS
涉及到 三方 ,即 攻击者 、 客户端 与 Web
应用
XSS
的攻击目标是盗取存储在客户端的cookie
或者其他网站用于 识别客户端身份的敏感信息 。一旦获取到合法用户的信息后,攻击者甚至可以 假冒合法用户 与网站进行交互
-
案例:
一个搜索页面,根据
url
参数决定关键词的内容<input type="text" value="<%= getParameter("keyword") %>"> <button>搜索</button> <div> 您搜索的关键词是:<%= getParameter("keyword") %> </div>
当攻击者输入:
"><script>alert('XSS');</script>
时,会得到一下代码<input type="text" value=""><script>alert('XSS');</script>"> <button>搜索</button> <div> 您搜索的关键词是:"><script>alert('XSS');</script> </div>
浏览器无法分辨出
alert('XSS');
是恶意代码,因而将其执行;当
alert('XSS')
部分js代码替换为获取用户登录信息并将其发送到攻击者自己服务器上,那么攻击者就成功获取了用户的用户信息,完成了XSS攻击。 -
根据攻击的来源,
XSS
攻击可以分成:- 存储型
- 反射型
- DOM 型
存储型 XSS
存储型 XSS 的攻击步骤:
- 攻击者将恶意代码提交到目标网站的数据库中
- 用户打开目标网站时,网站服务端将恶意代码从数据库取出,拼接在 HTML 中返回给浏览器
- 用户浏览器接收到响应后解析执行,混在其中的恶意代码也被执行
- 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作
这种攻击常见于带有用户保存数据的网站功能,如论坛发帖、商品评论、用户私信等
反射性 XSS
反射型 XSS 的攻击步骤:
- 攻击者构造出特殊的 URL,其中包含恶意代码
- 用户打开带有恶意代码的 URL 时,网站服务端将恶意代码从 URL 中取出,拼接在 HTML 中返回给浏览器
- 用户浏览器接收到响应后解析执行,混在其中的恶意代码也被执行
- 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作
反射型 XSS 跟存储型 XSS 的区别 是:存储型 XSS 的恶意代码存在数据库里,反射型 XSS 的恶意代码存在 URL 里。
反射型 XSS 漏洞常见于通过 URL 传递参数的功能,如网站搜索、跳转等。
由于需要用户主动打开恶意的 URL 才能生效,攻击者往往会结合多种手段诱导用户点击。
POST 的内容也可以触发反射型 XSS,只不过其触发条件比较苛刻(需要构造表单提交页面,并引导用户点击),所以非常少见
DOM型 XSS
DOM 型 XSS 的攻击步骤:
- 攻击者构造出特殊的 URL,其中包含恶意代码
- 用户打开带有恶意代码的 URL
- 用户浏览器接收到响应后解析执行,前端 JavaScript 取出 URL 中的恶意代码并执行
- 恶意代码窃取用户数据并发送到攻击者的网站,或者冒充用户的行为,调用目标网站接口执行攻击者指定的操作
DOM 型 XSS 跟前两种 XSS 的区别:DOM 型 XSS 攻击中,取出和执行恶意代码由浏览器端完成,属于前端 JavaScript 自身的安全漏洞,而其他两种 XSS 都属于服务端的安全漏洞
XSS的预防
xss攻击的两大要素:
- 攻击者提交恶意代码
- 浏览器执行恶意代码
预防:
设想: 前端对用户可以提交恶意代码的地方进行约束:如校验用户输入内容过滤可以代码字符<
>
/
""
等等
问题: 如果攻击者绕过前端直接向后端写入数据,后端进行过滤后存入数据库,在返回给前端时,这些内容在不同的地方展示方式不同
举例:
一个正常的用户输入了 5 < 7
这个内容,在写入数据库前,被转义,变成了 5 < 7
- 当
5 < 7
作为HTML时可以正常显示为 5 < 7 - 当
5 < 7
通过 Ajax 返回,然后赋值给 JavaScript 的变量时,前端得到的字符串就是转义后的字符。这个内容不能直接用于 Vue 等模板的展示,也不能直接用于内容长度计算。不能用于标题、alert 等
所以,过滤不是预防xss的最好方式;也不是最可靠的方式。
下面就要通过防止浏览器执行恶意代码:
-
在使用
.innerHTML
、.outerHTML
、document.write()
时要特别小心,不要把不可信的数据作为 HTML 插到页面上,而应尽量使用.textContent
、.setAttribute()
等 -
如果用
Vue/React
技术栈,并且不使用v-html
/dangerouslySetInnerHTML
功能,就在前端render
阶段避免innerHTML
、outerHTML
的 XSS 隐患 -
DOM 中的内联事件监听器,如
location
、onclick
、onerror
、onload
、onmouseover
等,<a>
标签的href
属性,JavaScript 的eval()
、setTimeout()
、setInterval()
等,都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API,很容易产生安全隐患,请务必避免
<!-- 链接内包含恶意代码 -->
<a href="UNTRUSTED">1</a>
<script>
// setTimeout()/setInterval() 中调用恶意代码
setTimeout("UNTRUSTED")
setInterval("UNTRUSTED")
// location 调用恶意代码
location.href = 'UNTRUSTED'
// eval() 中调用恶意代码
eval("UNTRUSTED")
CSRF
CSRF(Cross-site request forgery)跨站请求伪造:攻击者诱导受害者进入第三方网站,在第三方网站中,向被攻击网站发送跨站请求
利用受害者在被攻击网站已经获取的注册凭证,绕过后台的用户验证,达到冒充用户对被攻击的网站执行某项操作的目
一个典型的CSRF攻击有着如下的流程:
- 受害者登录a.com,并保留了登录凭证(Cookie)
- 攻击者引诱受害者访问了b.com
- b.com 向 a.com 发送了一个请求:a.com/act=xx。浏览器会默认携带a.com的Cookie
- a.com接收到请求后,对请求进行验证,并确认是受害者的凭证,误以为是受害者自己发送的请求
- a.com以受害者的名义执行了act=xx
- 攻击完成,攻击者在受害者不知情的情况下,冒充受害者,让a.com执行了自己定义的操作
csrf
可以通过get
请求,即通过访问img
的页面后,浏览器自动访问目标地址,发送请求
同样,也可以设置一个自动提交的表单发送post
请求,如下:
<form action="http://bank.example/withdraw" method=POST> <input type="hidden" name="account" value="xiaoming" /> <input type="hidden" name="amount" value="10000" />
<input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script>
访问该页面后,表单会自动提交,相当于模拟用户完成了一次POST
操作
还有一种为使用a
标签的,需要用户点击链接才会触发
访问该页面后,表单会自动提交,相当于模拟用户完成了一次POST操作
<a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank"> 重磅消息!!<a/>
CSRF的特点
- 攻击一般发起在第三方网站,而不是被攻击的网站。被攻击的网站无法防止攻击发生
- 攻击利用受害者在被攻击网站的登录凭证,冒充受害者提交操作;而不是直接窃取数据
- 整个过程攻击者并不能获取到受害者的登录凭证,仅仅是“冒用”
- 跨站请求可以用各种方式:图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中,难以进行追踪
CSRF的预防
CSRF通常从第三方网站发起,被攻击的网站无法防止攻击发生,只能通过增强自己网站针对CSRF的防护能力来提升安全性
防止csrf
常用方案如下:
-
阻止不明外域的访问
-
- 同源检测
- Samesite Cookie
-
提交时要求附加本域才能获取的信息
-
- CSRF Token
- 双重Cookie验证
这里主要讲讲token
这种形式,流程如下:
- 用户打开页面的时候,服务器需要给这个用户生成一个Token
- 对于GET请求,Token将附在请求地址之后。对于 POST 请求来说,要在 form 的最后加上
<input type=”hidden” name=”csrftoken” value=”tokenvalue”/>
- 当用户从客户端得到了Token,再次提交给服务器的时候,服务器需要判断Token的有效性
SQL
Sql 注入攻击,是通过将恶意的 Sql
查询或添加语句插入到应用的输入参数中,再在后台 Sql
服务器上解析执行进行的攻击
流程如下所示:
- 找出SQL漏洞的注入点
- 判断数据库的类型以及版本
- 猜解用户名和密码
- 利用工具查找Web后台管理入口
- 入侵和破坏
预防方式如下:
- 严格检查输入变量的类型和格式
- 过滤和转义特殊字符
- 对访问数据库的Web应用程序采用Web应用防火墙
总结
常见的攻击:
-
XSS 跨站脚本攻击
- 存储型,恶意代码存在服务器中,服务器安全漏洞,谨慎使用V-HTML、innerHTML、outerHTML、document.write来预防
- 反射性,恶意代码存在url中,l浏览器解析执行恶意代码,服务器安全漏洞,前端在render阶段预防
- dom型,恶意代码存在url中,把含恶意字符串作为代码运行,前端安全漏洞
-
CSRF 跨域伪请求攻击
- 特点:
- 攻击发起在第三网站,被攻击网站无法防止攻击
- 攻击者冒用用户登录凭证,在网站上进行操作,不是直接窃取数据
- 整个攻击过程中不能获取用户登录凭证,只是“冒用”身份
- 跨站请求方式众多,难以追踪
- 预防:
- 同源策略
- Samesite Cookie
- 双重token
- 特点:
-
SQL注入
- 服务器漏洞
- 利用漏洞注入恶意sql进行破坏
预防
- 严格检查输入变量的类型和格式
- 过滤和转义特殊字符
- 对访问数据库的Web应用程序采用Web应用防火墙
以上内容仅为个人学习归纳总结,如有错误烦请指出