目前来说,web攻防主要分为3部分:XSS、CSRF、SQL注入。
XSS分类
XSS攻击可以分为以下三类:
反射型跨站攻击:指的是将用户输入的数据通过URL的形式直接或未经过完善的安全过滤就在浏览器中输出,会导致输出的数据中存在可被浏览器执行的代码数据。涉及浏览器-服务器交互。
存储型跨站攻击:指的是Web应用将用户输入的数据信息未经处理直接存入数据库中,当页面进行数据库的查询展示时,会把攻击的代码直接在页面中输出展示。只要用户访问带有XSS攻击脚本的网页时,就会触发攻击效果,具有较强的稳定性。涉及浏览器-服务器-数据库交互。
DOM型跨站攻击:严格来说,基于DOM的XSS攻击并非按照“数据书否保存在服务器端”来划分,其从效果上来说也算是反射性XSS。但是这种XSS实现方法比较特殊,利用JavaScript的DOM节点编程可以改变HTML代码这个原理来形成的XSS攻击。一般攻击时需要对具体的DOM结构进行分析,构造攻击语句难度较大,较为少见。涉及浏览器-服务器交互。
目前危害比较严重的是存储型跨站攻击,攻击者可以利用JS脚本获取用户Cookie、弹出广告等行为。
XSS测试方法
测试基本跨站代码
1 | <script>alert(/xss/)</script> |
闭合标签测试
举个栗子,当评论框的内容是在<textarea></textarea>
中显示的时候,即使评论中有脚本也会被浏览器当成文本内容显示,并不会执行脚本内容。因此需要先闭合前面的<textarea>
标签,再构造攻击语句。
1 | </textarea><script>alert(/xss/)</script> |
大小写混合测试
随着Web安全防护技术的进步,稍有安全意识的开发者可能会使用黑名单过滤来进行防护。所谓黑名单过滤,就是将<script>
等易于触发脚本执行的标签作为黑名单,当提交的内容含有黑名单的关键词时会将关键词过滤掉显示。我们可以采用大小写混写的方式,尝试能否绕过黑名单的限制。
1 | <scRIPt>alert(/xss/)</scRIPt> |
针对这种防护效果的缺陷,实际应用中可以对输入的内容强制大小写转换以提升黑名单的可信度。
多套嵌套测试
由于后端会过滤掉黑名单的关键词,我们可以构造一个多余的关键词让服务器主动删除。
1 | <scr<script>ipt>alert( )</scr</script>ipt> |
宽字节绕过测试
主要针对GBK编码的网站才有这个漏洞,不过现在普遍采用的都是UTF-8编码,很少会有这种漏洞环境。具体原理可以自行百度。
多标签测试
在测试XSS的过程中,能够触发弹窗效果的远不止<script>
这一种标签,在不同的浏览器、不同的场景下,能够触发攻击效果的代码也不相同。具体可以参考这两个链接:XSS Filter Evasion Cheat Sheet、XSS Filter Evasion Cheat Sheet 中文版
XSS防护
过滤特殊字符
常在数据入库时使用。此方法定义了一个标签黑名单,其中包括很多HTML特性、JavaScript关键词、空字符、特殊字符等。当检测到提交内容存在这些字符时替换为空白。不过,这种方法具有一定的局限性,需要根据新增的HTML标签来进行动态的调整。
使用实体化编码
主要在输出内容时使用,有两种常见的安全编码。
HTML编码
编码前 | 编码后 |
---|---|
& | & |
< | < |
> | > |
“ | " |
‘ | ' &apos |
/ | / |
JavaScript编码
编码前 | 编码后 |
---|---|
‘ | \’; |
“ | \” |
\ | \; |
/ | \/; |
HttpOnly
HttpOnly是cookie的一个属性,一旦设置了这个属性,浏览器将禁止JavaScript读取cookie。不过它并没有从根本上解决xss的问题,只能防止用户的cookie不被泄露。
CSRF介绍
CSRF攻击指的是攻击者伪造一个页面,页面功能伪造当前用户的请求。当用户点击伪造页面时,会自动向当前用户的服务器提交攻击者伪造的业务请求。从而在用户不知情的情况下,以当前用户身份发送业务请求并支执行。
CSRF攻击必须满足三个条件才能执行成功:
用户处于登陆状态。
伪造的请求参数与正常应用的请求一致。
后台未对用户业务开展合法性做校验。
CSRF漏洞利用场景
当用户是管理员时,如果存在CSRF漏洞,则攻击者可以在用户不知情的情况下发起某项业务(如添加账号、删除文章)并执行。
针对个人用户,如果CSRF配合存储型XSS漏洞,可实现在页面上嵌入伪造链接,从而大大增加用户点击的可能性,形成触发攻击的隐患。
在部分管理系统中,为了系统使用便捷性,可以在后台web页面上开发特定功能来实现针对管理系统的参数调整,如果漏洞被利用,将会对系统造成极大危害。
CSRF漏洞防护
添加中间环节
由于攻击者只能发起请求却不能对请求的返回值做处理,因此可以在请求被执行前做处理。一是可以由后端返回一个需要二次确认的对话框,让用户主动确认;二是可以添加验证码来确认是否为当前用户发起的请求
验证用户请求合法性
验证referer
因为CSRF是伪造的页面,因此地址和真实的业务地址不会一样。
利用token
在访问页面时给用户下发一个token,每次发起请求时都携带这个token。由于攻击者无法获取到token,所以提交的请求不会成功。
免责声明
本文代码仅供参考学习,切勿用于实际系统之中!
参考文献
本文内容大部分来自蔡晶晶、张兆心等编著的《Web安全防护指南》,在此表示感谢。