JavaScript DOM XSS 注入验证答案

【问题标题】：JavaScript DOM XSS Injection validationJavaScript DOM XSS 注入验证
【发布时间】：2009-10-27 00:53:35
【问题描述】：

在将 HTML 嵌入 DOM 时，此正则表达式是否足以捕获所有跨站点脚本尝试。 eg: 比如用document.write()

(javascript:|<\s*script.*?\s*>)

本文档引用自 modsecurity.com http://www.modsecurity.org/documentation/Ajax_Fingerprinting_and_Filtering_with_ModSecurity_2.0.pdf

它会捕获所有 script.?\s*> UTF-8 中的变体吗？

【问题讨论】：

标签： javascript regex dom utf-8 xss

【解决方案1】：

很遗憾没有。如果攻击者真的在尝试，实际上有很多方法可以绕过该正则表达式。对于现代浏览器，该正则表达式应该做得很好，但它并不详尽。例如，类似这样的东西可以在不明确说明脚本或 javascript 的情况下打开 javascript

<img src="blah.jpg" alt="" onmousedown="alert('a')" />

查看here（有些过时但明白了重点）和here 了解更多示例

【讨论】：

本来要提到的，但上面的链接到owasp.org/index.php/… 做得很好——甚至 CSS 也可以成为 XSS 的来源。这么多攻击向量。
感谢这些资源和简单的例子。

【解决方案2】：

这个正则表达式是否足以捕获所有跨站点脚本尝试

哈哈哈哈哈哈哈哈哈。

对不起。但真的……不，这还不是冰山一角。

Daniel 提到了另一种注入脚本的方法，但实际上有数百种。根本不可能使用简单的正则表达式来清理 HTML。唯一的方法（即使那样也不是微不足道的）是正确解析 HTML，丢弃所有格式错误的序列和元素/属性名称，除了一些已知安全的名称。

当然，这仅适用于您实际上是有意接受 HTML 输入并且您希望限制其潜在危害的情况。如果情况是您正在接受文本，但在退出时忘记正确转义，则需要修复 HTML 转义，因为再多的输入嗅探都无法解决输出问题。

这就是为什么 mod_security 完全是假的。它通过捕获一些最基本的注入技术给你一种提高安全性的错觉，同时让其他所有东西都通过易受攻击的应用程序。它最终不会阻止您被黑客入侵，但是您添加的注入签名越多，它就越会拒绝和破坏合法请求。例如，它可能会阻止我输入此消息，因为它包含字符串 <script>。

【讨论】：

大声笑..也许你的正则表达式不符合标准：D我明白你的意思。

【解决方案3】：

其他受访者是对的：有许多情况下可能会发生注入。请记住，解决方案必须同时考虑可能发生注入的多种情况。黑名单（或“已知不良”）过滤方法不起作用，因为它们成为使用意外字符集编码注入、创造性地使用空格和其他技术的攻击的牺牲品。有关详细信息，请参阅OWASP DOM Based XSS。该页面的链接在“问题”方面进行教育。

至于解决方案，请考虑我们刚刚发布的OWASP XSS DOM Prevention Cheat Sheet。备忘单中引用了几个工具包，可帮助您实施转义或编码策略。可能我最喜欢的方法是JXT，以确保服务器编写的客户端代码被适当地编码和转义。从它的谷歌代码页：

<!-- Automatically escaped content -->
Hello ${user.getName()}!

<!-- Example tag with 3 different contextual encoding requirements -->
<img src="/profile-photo?user=${user.getId()}"
     alt="Photo of ${user.getName()}"
     onclick="openProfile('${user.getId()}')" />

<!-- Override the default escape, rare, but occasionally needed: -->
<jxt:out value="${user.getProfileHtml()}" escape="none"/>

请注意，这包括上下文的自动转义，还包括允许未转义输出的自定义标记，以防您的页面/应用程序的特殊元素被购物车漂白编码机制破坏。

【讨论】：