Web 安全防护指南基础篇-XSS攻击
ʕ •ᴥ•ʔ (๑˃̵ᴗ˂̵) ପ( ˘ᵕ˘ ) ੭
1 XSS攻击原理
存在 XSS 攻击的地方一般为：评价功能、论坛私信、留言、在线信箱….
一般分类为：
- 反射型跨站攻击： 浏览器---服务器交互
- 存储型跨站攻击：浏览器---服务器---数据库交互
- DOM型跨站攻击：浏览器---服务器交互
可以实现：获取用户 Cookie、进行内网探测、弹出广告等。
上传的业务流程如下图：
其中两个关键点是：
- 入库处理：攻击脚本需存储在数据库中，可供当前应用的使用者读取。
- 出库处理：由当前功能的使用者按照正常的业务流程从数据库中读取信息，这时攻击脚本即开始执行。
XSS 攻击成功必须满足以下四个条件：
（1）入库处理
- 目标网页有攻击者可控的输人点。
- 输人信息可以在受害者的浏览器中显示。
- 输入具备功能的可执行脚本，且在信息输入和输出的过程中没有特殊字符的过滤和字符转义等防护措施，或者说防护措施可以通过一定的手段绕过。
（2）出库处理
- 浏览器将输入解析为脚本，并具备执行该脚本的能力。
如果要实现一个 XSS 存储型跨站攻击，以上四点缺一不可。如果需要做针对 XSS 攻击的防御，只要针对上述任何一点做好防御，攻击就无法正常开展，XSS 漏洞也就不存在了。
总结
作为攻击者，如果要利用存储型跨站漏洞攻击，则先要将攻击脚本存储在服务器端，并且保证攻击脚本在读取后可顺利执行。当应用功能对上述条件均满足时，才可保证漏洞被成功利用。
作为防护者，了解到实施存储型跨站攻击的前提及必要条件后，从防护角度，可以选择禁止攻击脚本存储在数据库，即在入 库时做处理;或者对攻击脚本进行转义，避免出库时顺利执行。满足以上两种条件中的任何一个即可实现有效的防护。
2 XSS漏洞测试流程
由于 XSS 漏洞需要使用者浏览后才可触发，某些后台需要管理员触发后才能被发现，如果用户一直不触发，漏洞就一直无法检查出来。
漏洞的标准挖掘思路如下：
- 漏洞挖掘，寻找输入点。
- 寻找输出点。
- 确定测试数据输出位置。
- 输入简单的跨站代码进行测试。
2.1 寻找输入点
一般情况下， XSS 攻击是通过“HTML注入” 方式来实现的。也就是说，攻击者通过提交参数，意图修改当前页面的 HTML 结构。XSS 攻击成功时，提交的参数格式在当前页面拼接成可执行的脚本。可见，XSS 漏洞存在的要求就是：当前页面存在参数显示点，且参数显示点可被用户控制输入。因此，寻找用户端可控的输入点是 XSS 攻击成功的第一步。
在一个常规的网站中，存储型 XSS 一般发生在留言板、 在线信箱、评论栏等处，表现特征是用户可自行输入数据，并且数据会提交给服务器。通常可以通过观察页面的交互行为来确定输入点。通常情况下，要求可提交数据量至少在20字符以上，否则JavaScript脚本很难执行。在日常应用中，如留言板、意见反馈点、私信、文件上传信息输入框、在线提交信息、在线信箱、评论栏等功能都允许用户输人100字左右，均能达到 XSS 攻击对允许输人字符的要求。
2.2 寻找输出位置
XS S攻击的受害者是访问过包含 XSS 恶意代码页面的用户，输入内容需要在用户页面上进行展示才能展开 XSS 攻击。针对一般的留言板、 评论栏系统，安全人员能根据经验轻松地判断出输出点的位置；对于一些不常见的系统，可以通过将输入内容在回显页面中进行搜索来确定输出位置。测试主要基于两个目的：
- 确定网站对输入内容是否进行了输出，判断是否可以展开 XSS 攻击。
- 有时候需要根据输出的位置的 HTML 环境来编写有效的 XSS 代码。
XSS盲打后台
指在攻击者对数据提交后展现的后台未知的情况下，网站采用了攻击者插入了带真实攻击功能的 XSS 攻击代码（通常是使用script标签引入远程的js）的数据，称作XSS盲打。当未知后台在展现时没有对这些提交的数据进行过滤，那么后台管理人员在操作时就会触发 XSS 来实现攻击者预定好的“真实攻击功能”。
通过上面两个步骤的测试，可发现具体的输入点及输出位置，那么存在 XSS 漏洞的基本条件就已经具备了。但 XSS 攻击在这个测试点是否能顺利进行，就需要通过一些基本的跨站代码来测试，如果其中环节被过滤，则攻击依然无效。测试 XSS 攻击的经典方式就是弹窗测试，即在输入中插入一段可以产生弹窗效果的JavaScript脚本，如果刷新页面产生了弹窗，表明 XSS攻击测试成功。
2.3 XSS进阶测试方法
