Question

我一直在尝试使用innerHTML来尝试找出我需要在我正在处理的webapp上加强安全性的地方，我在the mozilla docs遇到了一个有趣的注入方法，我没有想到了。

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

它让我想知道a。）如果我应该使用innerHTML，b。）如果它不是一个问题，为什么我一直在避免其他代码插入方法，特别是eval。

让我们假设我在浏览器上运行javascript客户端，我正在采取必要的预防措施，以避免在易于访问的功能中暴露任何敏感信息，并且我已经得到了一些任意指定的点我已经决定innerHTML是不是安全风险，我已经优化了我的代码，以至于我不一定担心会有轻微的性能损失......

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

或者替代地，innerHTML是否应该表现出同样的关注？这同样危险吗？

Answer 1

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

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

（如果您正在添加您的代码，那就不是问题了）

如果您要添加用户添加的文字，请考虑使用textContent。它会逃脱它。

问题是什么

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

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

有关详细信息，请参阅此处this question。

我可以做些什么来缓解它？

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

有关预防XSS的更常用方法，请参阅this question。

代码注入是个问题。你不想在接收端。

这不是innerHTML和eval的唯一问题。当您更改DOM节点的innerHTML时，您正在销毁其内容节点并改为创建新节点。当你调用eval时，你正在调用编译器。

虽然这里的主要问题显然是不受信任的代码，而且你说性能不是问题，但我仍然觉得我必须提到两者对于他们的选择极其缓慢。

Answer 2

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

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

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

然而，

eval属于另一类 - 它是副产品，大部分时间都是混淆的。如果你落到eval而不是innerHTML，那么你就属于非常非常小的一部分。

所有这一切的关键是使用解析器来清理数据，该解析器能够及时了解笔测试人员发现的内容。周围有几个。他们绝对需要至少过滤OWASP列表中的所有内容 - 这些非常常见。

Answer 3

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

您在访问者页面上放置的任何内容都必须进行清理。无论是在构建初始页面时还是在客户端异步添加，都无关紧要。

所以......是的，您需要在使用innerHTML 时显示一些注意事项，如果您正在显示用户提交的内容。