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

Posted 2023-02-19

【中文标题】保护 Express 免受 XSS：对整个传入请求的 HTML 实体进行编码是不是足够？

【英文标题】：Protect Express against XSS: is it sufficient to encode HTML entities of whole incoming request?保护 Express 免受 XSS：对整个传入请求的 HTML 实体进行编码是否足够？

【发布时间】：2015-07-13 04:40:09

【问题描述】：

我有一个 Express 应用程序，我想保护它免受 XSS 攻击。

我红了一些关于 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 sanitizer 服务器端是什么（即使它是其中的一部分），我宁愿想知道我在代码中设置的保护措施是否能在全球范围内保护我的应用免受所有众所周知的 XSS 类型的攻击。特别是我会知道我的中间件是否不是一个坏习惯。

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

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

编辑 2

我选择 Erlend 的答案是最好的，但是 msoliman 的答案也很出色，并且与 Erlend 的答案相辅相成。

【问题讨论】：

XSS filtering function in PHP的可能重复

没错，它使用PHP而不是node.js，但它传达了基本思想。

【参考方案1】：

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

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

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

通过尝试在进入的过程中对事物进行清理，您最终可能会发现自己的清理功能不够好，并且您对数据进行了部分/错误的清理，并且修复起来会一团糟。

总结：

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

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

【参考方案2】：

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

您也可以按照以下线程检查如何在服务器端进行操作，以获得更好的安全性

Preventing XSS in Node.js / server side javascript