DOM XSS 是误报吗答案

【问题标题】：Is it a false postive for DOM XSSDOM XSS 是误报吗
【发布时间】：2015-11-01 20:23:26
【问题描述】：

我使用 IBM AppScan 扫描我的网站。其中一个漏洞被称为“DOM XSS”。经过调查，我怀疑这可能是误报。有谁知道我的以下代码可以基本注入它吗？

【问题讨论】：

标签： security web xss

【解决方案1】：

这似乎是一个子域解析例程，将document.domain 设置为inter-origin communication 的此值。

例如如果当前 URL 是 http://www.example.com/，则 document.domain 设置为 example.com。

这似乎是误报，因为即使使用不受信任的输入来设置域以放松同源策略限制，设置 document.domain 仅对当前域的子域有效，因此它将是很难将其操纵成恶意的东西。

也就是说，如果example.edu 将其document.domain 设置为example.com，则浏览器将不会接受这一点，因为域本身不匹配并且浏览器将不允许将任何内容设置为顶级域尝试com 的情况。

解析 href 并不是最好的方法 - location object 中还有其他可用的属性，例如 .hostname。如果解析例程中存在缺陷，则可以通过在 URL 中的其他位置提交主机名来欺骗代码：

http://www.example.com?injectedHostname=http://www.example.org

话虽如此，我看不出您当前的功能实现如何被滥用。

【讨论】：

【解决方案2】：

这不是传统的 HTML/脚本注入 DOM，因此它不是人们通常所说的“DOM XSS”，但 AppScan 检测到它，因为数据从不受信任的来源（文档 URL）流向危险的sink（安全敏感的document.domain 属性），这通常是一件有风险的事情。

如果攻击者可以影响document.domain，则确实有可能允许跨域脚本，尽管它必须来自相邻域（因为document.domain 不能设置为例如TLD）所以这样可以稍微减少伤害。

如果您必须从浏览器地址自动设置document.domain，那么为了安全地进行设置，您应该（a）直接读取location.hostname，而不是尝试拆分location.href， (b) 确保应用程序的部署使其仅响应其真实主机名。如果攻击者将他们自己的 DNS 指向您服务器的 IP 地址，则应用程序不应该出现。完成此操作后，您仍然必须忽略警告。

如果可以将document.domain 设置为不是来自输入的特定静态值（例如从配置中获取），那将是一种更好的方法。

【讨论】：