我一直在尝试使用innerHTML来尝试找出需要加强我正在开发的Web应用程序的安全性的地方，然后我遇到了一个我没想到的有趣的注入方法。

这让我想知道a。)是否应该完全使用innerHTML，b。)如果不关心，为什么一直避免使用其他代码插入方法，尤其是eval。

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

我是否会使用eval造成其他问题？除了纯代码注入以外，还有其他安全问题吗？

或者，是否应该对innerHTML进行同样的处理？同样危险吗？

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

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

(但是，如果您要添加代码，那就没问题了)

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

问题是什么

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

例如，如果您基于用户来自GET参数的输入来设置节点的innerHTML。"用户A"可以向您的页面发送"用户B"的HTML版本，上面写着"窃取用户数据并通过AJAX发送给我"。

有关更多信息，请参见此处。

我该怎么做才能缓解这种情况？

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

• 使用具有转义功能的模板引擎(例如Mustache)。 (默认情况下，它将转义HTML)
• 使用textContent手动设置节点文本
• 不接受用户向文本字段中的任意输入，而是自己清理数据。

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

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

房间里的大象

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

尽管这里的主要问题显然是不受信任的代码，并且您说性能不是问题，但我仍然觉得我必须提到两者在替代方案方面极其缓慢。

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

最重要的是，触发XSS的方式比您想象的要多。以下所有内容均有效：

• onerror，onload，onclick，onhover，onblur等都有效
• 使用字符编码绕过过滤器(上面突出显示了空字节)

但是，eval属于另一类-它是副产品，大多数时候会造成混淆。如果您属于eval而不是innerHTML，那么您将是非常小的一部分。

所有这些的关键是使用解析器对数据进行清理，该解析器将与笔测试人员发现的内容保持最新。周围有几个。他们绝对需要至少过滤OWASP列表中的所有内容-这些非常普遍。

innerHTML本身并不是不安全的。 (Nor是eval，如果仅在代码上使用的话。由于其他一些原因，这实际上不是一个好主意。)显示访问者提交的内容时会出现不安全感。这种风险适用于您嵌入用户内容的任何机制：客户端上的eval，innerHTML等，以及服务器端的print，echo等。

您在访问者页面上放置的所有内容都必须经过清理。无论是在构建初始页面还是在客户端异步添加初始页面时，都不要紧。

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