保护 Express 免受 XSS：对整个传入请求的 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。

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

编辑

我的问题不是什么是最好的 HTML sanitizer 服务器端（即使它是它的一部分），我更想知道我在代码中放置的保护措施是否可以保护我的应用程序免受所有众所周知的 XSS 类型的侵害。特别是我会知道我的中间件是否不是一个坏习惯。

事实上，PHP中的XSS 过滤功能至少没有涵盖基于 DOM 的 XSS 攻击（因为它只涵盖了服务器端的 HTML 清理）。

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

编辑 2

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

Answer 1

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

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

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

通过尝试在进入的过程中清理事物，您最终可能会发现您的清理功能不够好，并且您部分/错误地清理了数据，并且修复起来会很混乱。

总结：

a) 中途根据域进行验证和拒绝

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