针对XSS保护Express：对整个传入请求的HTML实体进行编码是否足够？

Question

我有一个我想要防范XSS的Express应用程序。

我重写了一些关于XSS的页面 - 包括OWASP个，鉴于我的应用程序特性，我决定编写一个编码HTML实体的中间件 - 更准确地说是XML实体，包括<>"' - 我在路线中使用它之前的请求参数。

我还在连接时刷新会话cookie，以防止cookie被盗。

我如何构建应用

• 所有AJAX请求都是POST（所有参数都由中间件重写）
• 我不使用GET参数
• 我使用的路径参数应该是int，并且当它们不是时我会引发错误。
• 唯一不是来自用户输入的数据来自OAuth个人数据检索，当我们进入我的应用时，我也会对其进行消毒
• 在页面加载时执行的客户端JS只涉及来自数据库的数据，假设中间件进入数据库时​​会被清理。
• window.location安全使用
• 我还没有使用任何外部客户端JS库（如JQuery或FileUpload） - 也许我稍后会在代码中添加它们
• 当用户输入内容时，它总是发送到服务器（通过AJAX POST），我借此机会发回已清理的输入以在JS和/或DOM中使用它而不是初始输入
• 我不使用eval

我的感觉

我得出结论，使用这种行为（清理外部数据）我避免了所有存储和反映的XSS，正确使用windows.location可以防止我使用基于DOM的XSS。

这个结论是对的，还是我忘记了什么？我还应该使用一些helmet功能吗？

修改

我的问题不是什么是最好的HTML清理服务器端（即使它是其中的一部分），我宁愿要知道我是否在全球范围内对我的代码中的保护措施保护我的应用程序免受攻击所有众所周知的XSS类型。特别是我会知道我的中间件是不是一个坏习惯。

确实XSS filtering function in PHP至少没有涵盖基于DOM的XSS攻击（因为它只涉及服务器端的HTML清理）。

我列出了我的应用程序的一些特性，以便对我忘记的任何一点或者将应用程序暴露给XSS漏洞的糟糕架构模式提供反馈。

修改2

我选择Erlend的答案是最好的，但msoliman的答案也很出色，并且是对Erlend的答案的补充。

Answer 1

虽然你在这里做得很好，但我认为你应该考虑这个问题：逃避数据以避免XSS需要依赖于上下文。 OWASP XSS预防备忘单详细解释了这一点。

恕我直言，当从客户端接收数据时，您应该确保数据根据域有效。这就是你正在做的路线参数。你希望它是一个int，如果不是，就拒绝它。对于其他数据类型，您应该做同样的事情。这是一个有效的名字吗？ （名字通常不包含＆lt;或＆gt;）。这是有效的邮政编码吗？这将阻止大量攻击，因为攻击通常包含在给定上下文中无效的字符。

当谈到停止攻击时，XSS，SQL注入等都是同一问题的子类。在将数据添加到HTML（或XML或SQL查询等）时，您必须转义数据，并且您需要为给定的上下文转义。如何转义数据取决于它是否在标签之间，作为属性值，在CSS等中。

通过尝试清理过程中的内容，您可能最终会发现您的santization功能不够好，并且您已经部分/错误地清理了数据，并且修复它将会很麻烦。

总结：

a）在

中的路上根据域进行验证和拒绝

b）在输出期间执行基于上下文的转义

Answer 2

您可以清理客户端的html .. Sanitize/Rewrite HTML on the Client Side

此外，您可以按照以下主题检查服务器端如何做以提高安全性

Preventing XSS in Node.js / server side javascript