测试Web应用程序是否存在跨站点脚本漏洞(3)
改变测试用例d,WSc_R我恐怕无法充分对此进行说明：研究输入的值会输出什么样的 HTML 页面非常重要。如果它们不能产生输出，那么不要在它们上面浪费时间。如果可以，请进行研究，因为您需要根据输出对测试进行相应的修改。我使用了各种变化形 式来找出能接受和显示脚本代码的参数。因为这涉及太多内容，因此在这里无法一一进行讨论，但是请务必注意以下几种情况：
8w g B H h3T*a7\2F
1.
>"'><script>alert(‘XSS')</script>
2.
>%22%27><img%20src%3d%22javascript:alert(%27XSS%27)%22>
%F"O3`(e/~ W5F
3.~$Hx9]P
>"'><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26%23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26%23x3a;alert(%26quot;XSS%26quot;)>BEUU{#^'}.re!t6~
{ X0s[ry y
4.Hx NR w pxF
AK%22%20style%3D%22background:url(javascript:alert(%27XSS%27))%22%20OS%22
9GE;a I;P/|R
5.
%22%2Balert(%27XSS%27)%2B%22
6.
<table background="javascript:alert(([code])"></table>N[@N2z#O([
7.-@xh v$B$QU
<object type=text/html data="javascript:alert(([code]);"></object>@ P H0@!xK{ n
8.
<body onload="javascript:alert(([code])"></body>Q@)S9c B:?"E[h
%@(p+EI8j q
有许多变化形式可以尝试。关键在于了解程序究竟使用何种方式处理输入和显示输出页面。如同这些例子所展示的，常见的变化形式经常是在脚本代码前面加 上 “>””，以尝试封闭网站可能在输出中生成的标记。还可以对代码进行 URL 编码，尝试绕过服务器端的输入过滤功能。此外，因为尖括号“<>”通常会在输入时被过滤和从输出中删除，所以还必须尝试不需要尖括号的 XSS，例如 ”&{alert('XSS')};”
n K7w3T%W {!O g
持久和动态pP g;O e(Kd(hx j
找出一个成功的 XSS 颇费周折，因为在开始时 XSS 攻击可能并不是那么显而易见的。随便举一个例子，如果向网站添加一条新留言并在“msgTitle”值中注入代码，在提交数据后，您可能不会立即看到脚本 代码被执行。但是，当您访问留言板的时侯，将会在 HTML 页面中使用“msgTitle”值并将其作为脚本代码执行。这种情况被称作持久性 XSS 攻击，如果包含脚本代码的值将被保存到客户端或者后端系统并在稍候的时间被执行，便会发生此种攻击。
而与此相对的是动态 XSS 攻击，这种攻击会立即执行并只发生一次。比如，如果某个链接或 GET 请求在某个用来控制页面输出的查询字符串中包含了脚本代码，那么在点击链接后会立即显示输出。+laD b0b0c e(O L l G
总结CVGR!} g:K4c
XSS 测试通常只是整个 Web 应用程序安全性审查工作的一小部分，但是在执行测试时必须细致和彻底。在多年的工作中，我一直强调使用电子表格或其他方式来记录站点的所有页面，以及每个 页面接受的输入值（查询字符串、cookie、POST 数据、SOAP），这是在测试前必须进行的一个重要步骤。与此同等重要的是，理解输入以及它在输出的 HTML 页面上的呈现方式。如果您知道了应用程序处理输入的方式，就会非常迅速地完成许多工作。不要浪费时间测试那些不会作为输出显示的输入。与开发人员和 PM 进行交流，并在开始测试前建立完善的威胁模型。
页:
[1]