19

我一直在用 innerHTML 做一些试验，试图找出我需要在我正在开发的 web 应用程序上加强安全性的地方，并且我在mozilla 文档上遇到了一种我没有想到的有趣的注入方法。

var name = "<img src=x onerror=alert(1)>";
element.innerHTML = name; // Instantly runs code.

这让我想知道 a.) 我是否应该使用 innerHTML，以及 b.) 如果这不是问题，为什么我一直在避免使用其他代码插入方法，尤其是 eval。

假设我在浏览器上运行 javascript 客户端，并且我正在采取必要的预防措施以避免在易于访问的函数中暴露任何敏感信息，并且我已经达到了一个任意指定的点，我已经决定 innerHTML 不是安全的风险，并且我已经优化了我的代码，以至于我不必担心性能受到非常小的影响......

我是否通过使用 eval 产生任何其他问题？除了纯代码注入之外，还有其他安全问题吗？

或者，innerHTML 是我应该表现出同样关心的东西吗？是否同样危险？

4

3 回答 3

21

tl;博士;

是的，你的假设是正确的。

innerHTML如果您添加不受信任的代码，设置很容易受到 XSS 攻击。

（不过，如果您要添加代码，那问题就不大了）

如果要添加用户添加的文本，请考虑使用textContent，它将对其进行转义。

问题是什么

innerHTML设置 DOM 节点的 HTML 内容。当您将 DOM 节点的内容设置为任意字符串时，如果您接受用户输入，则很容易受到 XSS 攻击。

例如，如果您根据参数innerHTML中的用户输入设置节点的GET。“用户 A”可以向“用户 B”发送一个带有 HTML 的页面版本，上面写着“窃取用户的数据并通过 AJAX 将其发送给我”。

请在此处查看此问题以获取更多信息。

我能做些什么来减轻它？

如果要设置节点的 HTML，您可能需要考虑的是：

  • 使用像Mustache这样具有转义功能的模板引擎。（默认情况下会转义 HTML）
  • 用于手动textContent设置节点文本
  • 不接受用户对文本字段的任意输入，自己清理数据。

有关防止 XSS 的更通用方法，请参阅此问题。

代码注入是一个问题。你不想成为接收端。

房间里的大象

innerHTML这不是和的唯一问题eval。当你改变innerHTML一个 DOM 节点的时候，你就是在销毁它的内容节点并创建新的节点。当你打电话时eval，你正在调用编译器。

虽然这里的主要问题显然是不受信任的代码，并且您说性能不是问题，但我仍然觉得我必须提到这两者对于它们的替代方案来说非常缓慢。

于 2013-05-31T15:02:24.367 回答
6

快速的回答是：你没有想到任何新东西。如果有的话，你想要一个更好的吗？

<scr\0ipt>alert("XSSed");</scr\0ipt>

底线是触发 XSS 的方法比你想象的要多。以下所有内容均有效：

  • onerror, onload, onclick, onhover,onblur等等...都是有效的
  • 使用字符编码绕过过滤器（上面突出显示的空字节）

eval然而，它属于另一类——它是一种副产品，大部分时间都是为了混淆。如果你堕落eval而不堕落innerHTML，那你就属于非常非常少的少数。

所有这一切的关键是使用解析器清理您的数据，该解析器与渗透测试人员的发现保持同步。周围有几个。他们绝对需要至少过滤OWASP列表中的所有内容——这些内容非常常见。

于 2013-05-31T15:04:23.950 回答
2

innerHTML本身并不是不安全的。eval（如果仅在您的代码中使用，也不是。由于其他几个原因，这实际上是一个坏主意。）显示访问者提交的内容时会出现不安全性。这种风险适用于您在客户端嵌入用户内容的任何机制：eval,等，以及服务器端的 , 等。innerHTMLprintecho

您从访问者那里放置在页面上的任何内容都必须经过消毒。无论您是在初始页面正在构建还是在客户端异步添加时执行此操作都无关紧要。

innerHTML 所以......是的，如果您使用它显示用户提交的内容，则在使用时需要小心。

于 2013-05-31T15:04:55.423 回答