让用户定义innerHTML的漏洞
Posted
技术标签:
【中文标题】让用户定义innerHTML的漏洞【英文标题】：vulnerabilities of letting user define innerHTML 【发布时间】：2011-08-15 04:28:51 【问题描述】：假设我有一个
【参考方案1】：如果他们输入的内容没有离开页面，没有比他们通过 firebug 或 chrome 检查器编辑 DOM 更大的风险。如果您接受他们的输入然后按原样显示，这是一个巨大的安全风险，尤其是当其他用户在您的网站上时。
【讨论】：
对于他们输入“不离开页面”的内容，我是否必须使用iframe？
不，您只需处理提交按钮单击，获取 textarea 文本，然后将 div 的 innerHTML 设置为该值。
我还是不明白你在说什么 :( 如果你把 textarea 文本作为 div 的 innerHTML 那么这不会容易受到恶意 JavaScript 的攻击吗？
如果您不将用户输入的文本发送到服务器，则不会。如果您只是将其保留在该页面上，则没有风险。他们可以打开他们的检查器并自己弄乱 HTML（你永远无法阻止这个，如果我愿意，我现在可以在这个页面上做）。如果您处理他们的文本，然后将其显示给其他用户，那么您和您的用户就会受到攻击。
太好了，谢谢！现在一切都说得通了:)【参考方案2】：
好吧，如果您对内容进行编码以使其中的任何 javascript 都不会执行，那么它应该是安全的。
如果您不这样做，那么用户可以上传 javascript，该 javascript 将在下次其他用户查看该页面时执行。
我想修改我的回复以考虑到@Brigham cmets。只有在处理 div 选项卡之类的 innerHTML 时，转义才能可靠地工作，如果您正在处理使用用户生成的值作为属性或在脚本标签内，则转义/编码将不起作用。
我将向您推荐 OWASP XSS 指南（@Brigham 最初引起我的注意）以获取更多信息：https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#Untrusted_Data
【讨论】：
对内容进行编码以消除 Javascript 的可能性是相当困难的。例如，在 IE 中，可以在 CSS 中运行 Javascript：owasp.org/index.php/… @Brigham，感谢您提供的链接，这很有趣。我肯定会用它作为参考。然而，这个特定的问题并不是关于将用户输入放置在文档中的任意位置。问题是关于替换 div 的主体。在这种情况下，编码应该处理所有可能的攻击。甚至您引用的文档也指出：“对于您放入 HTML 文档正文（例如 标记内）的不受信任的数据，HTML 实体编码是可以的。” 【参考方案3】：用户可以执行跨站点脚本。它可以注入恶意客户端代码
看看http://en.wikipedia.org/wiki/Cross-site_scripting
【讨论】：
我很确定 OP 正在谈论用户正在输入的内容的实时预览，在这种情况下，为什么要在自己的机器上运行任何恶意软件（更不用说这功能与 XSS 的定义不一致）【参考方案4】：他们想要的任何东西都可以包含一个<script> 标签，该标签从他们自己的服务器中提取一个 .js 文件。然后，如果您将该内容显示给其他用户，该脚本可以执行各种操作来从毫无戒心的用户那里提取信息。
【讨论】：
以上是关于让用户定义innerHTML的漏洞的主要内容，如果未能解决你的问题，请参考以下文章
无法在 IF 语句中读取 null 的属性“innerHTML”[重复]
由于 XSS 漏洞，如何将此 innerhtml 循环转换为内部文本？