在客户端 javascript 或 websocket 服务器上转义？答案

【问题标题】：Escape in client-side javascript or on websocket server?在客户端 javascript 或 websocket 服务器上转义？
【发布时间】：2021-07-01 17:53:45
【问题描述】：

许多来源推荐使用“过滤输入，转义输出”的方式来管理内容。我一直很好地遵循这一点，但发生了一种情况，我可能想违反这个口头禅，但我不确定这样做的潜在成本。

我有一个 pubsub websocket 服务器 (node.js)，其目的是从另一台服务器读取数据，然后通过 websocket 将其发送给订阅的客户端。

我现在正在做的是当客户端通过 websocket 服务器接收数据时，数据会在客户端 javascript 中转义为 HTML。这似乎很脆弱。我的安全专业知识有限，因此让客户端 javascript 进行编码可能是我不知道的漏洞。作为一个假设的例子，也许客户端是一个旧的浏览器，它不完全理解转义功能，导致它很容易受到攻击。一般来说，让浏览器客户端进行这种转义似乎有点奇怪。

我正在考虑将 HTML 的转义从客户端转移到 websocket 服务器。唯一需要的编码是将字符串转换为 html 实体，但必须对字符串进行未解析、编码、然后重新解析并发送到客户端。这可能会增加大量开销，因为每个字符串可能有几 KB 长。 websocket 服务器应该只是发布者和订阅者之间的管道，因此应该尽可能快，但安全性更为重要。

websocket 服务器的客户端只需要将数据显示为 html，因此我相信客户端不需要对数据执行不同的操作。（如果一种新的客户端必须以不同的方式使用数据，我会设置一个新的 websocket 服务器或新的订阅，它不会对要发送的数据进行编码。）

这并没有完全违反“过滤输入，转义输出”的想法，因为原始数据保持不变。中间“客户端”，即 websocket 服务器，将在将数据发送到浏览器之前接收并保护数据，这就像普通 web 服务器从数据库中获取数据然后将 HTML 发送到浏览器时的操作方式一样。

我现在考虑的选项是：

在客户端 javascript 中继续将数据编码为 html 实体
在发送给客户端之前在 websocket 服务器上编码为 html 实体

在 websocket 服务器上编码可能会产生开销，但似乎这是最安全的事情，因为它发生在服务器端。在安全方面犯错导致我不想在客户端 js 中编码 HTML。

由于充满未知数，在客户端上编码对我来说似乎是最危险的选择。

我使用Underscore的转义函数https://underscorejs.org/docs/modules/escape.html在客户端js中转义html。

我应该将转义的 html 移动到 websocket 服务器还是保留在客户端 javascript 中？将其保存在客户端 javascript 中时，我应该注意哪些漏洞？

【问题讨论】：

标签： javascript validation security

【解决方案1】：

简单规则：如果和何时您正在显示它并且专门针对正在使用的上下文进行转义。

换句话说，将其作为纯文本发送，如果您在 HTML 上下文中显示它，则将其转义为 HTML。

过早转义是您最终会在 HTML 中出现像 &amp; 这样的垃圾，因为您忘记了它是否已经转义，并进行了双重转义。

实际上，这意味着您的输入、传输、数据库中的持久性和重新传输步骤都是“原始的”。将内容插入 HTML 文档的最后一步是转义。

【讨论】：

感谢您的回复。这是我第一次不得不在客户端 javascript 中转义。在这种情况下这样做是否合适？发送潜在的恶意文本以插入页面，然后依赖未知的客户端逃脱它对我来说听起来有点危险。但我承认我不确定这个过程可能面临的任何实际问题。
典型的 webserver 和 websocket 服务器之间的区别在于 webserver 正在创建一个 html 文档，而 websocket 服务器不是，但是如果我在 websocket 服务器上转义，我知道它是安全的客户端，但如果我在客户端这样做，我不确定。
“未知客户端逃逸”是怎么回事？除非客户端正在运行一些极其糟糕的 JavaScript 实现，否则它会没事的。如果他们的 JavaScript 被破坏，那么他们可能会遇到比 XSS 问题更大的问题。让客户决定是否/何时逃跑。请记住，使用 WebSocket 时，客户端实际上可能不是 Web 浏览器，它可能很容易成为根本不使用 HTML 的本机应用程序，因此让客户端为它实际使用的显示方法执行客户端需要做的事情。