所有已知的 javascript framekillers 都容易受到 XSS 的攻击吗？
window.location如果是，在突破 iframe 之前进行消毒是否足够？
最好的方法是什么？
您能否举一个可能的 XSS 攻击示例？
谢谢！
UPD：我问的原因是因为我收到了一个漏洞扫描警报，说包含的 JS framekiller 代码是由用户控制的top.location.replace(document.location)XSS 漏洞。document.location
问问题
2929 次
1 回答
2
他们的描述是正确的：' document.location '、' window.location '、' self.location '之类的变量（部分）由不受信任的用户控制。这是因为在不可信域和页面位置（'http://non.trusted.domain.com/mypage'）和不可信请求字符串（'http://my.domain'）中选择（子）字符串.com/? myrequest ') 是根据用户的意图形成的，可能并不总是对你有好处。
出了什么问题：这种用户依赖性不一定是 XSS 漏洞。事实上，要形成 XSS，您需要有一些代码有效地使用页面输出流中某处不受信任的用户控制的内容。在简单的 framekiller 示例中，top.location.replace(window.location)没有 XSS 的危险。
我们可以谈论 XSS 的一个例子是这样的代码
document.write('<a href="' + document.location + '?newvar=newvalue">Click here</a>')
用您的代码构造类似 URIhttp://test.com/?dummy"<script>alert("Test")</script>"dummy并替换document.location将在受信任网页的上下文中触发不受信任的脚本。由于构建这样的 URI 并将其不转义传递是一项挑战，真正的 XSS 将在一些更复杂的场景中工作，这些场景包括将不可信变量逐字插入语言指令流中，无论是 HTML、CSS、JS、PHP 等。
另一个著名的 XSS 无感知开发示例是JSON的发明历史。虽然 JSON 非常受欢迎（我也是它的支持者之一），但最初它的目的是作为将 JS 数据存储为纯 JS 格式数据结构片段的“quick-n-dirty”方式。为了“解析” JSON 块，只需对它们进行eval()就足够了。幸运的是，人们很快就意识到这整个想法有多么有缺陷，所以现在任何头脑清醒的知识渊博的开发人员都会使用适当的安全 JSON 解析器来代替。
于 2012-12-25T21:09:56.890 回答