XSS 攻击和编码答案

【问题标题】：XSS attacks and encodingXSS 攻击和编码
【发布时间】：2020-12-23 08:10:31
【问题描述】：

就数据而言，我有一个关于 XSS 的非常基本的问题。虽然常见的预防技术是对数据进行编码，但编码是否需要双向进行，即在服务器端，当它向浏览器发送一些响应时，或者我们是否还需要编码（比如用户输入数据，例如搜索字段) 在我们将其发送到服务器之前？

【问题讨论】：

任何与安全有关的事情都必须在服务器上完成。客户端上的验证/其他数据处理只是为了访问者的方便，这与安全性没有任何关系。
@Teemu 对于 javascript 应用程序（例如 SPA），这是不正确的。
@GaborLengyel 您无法在客户端执行任何操作来阻止用户在发送请求之前对其进行操作。请注意，您甚至不需要实际页面，您可以从另一台服务器发布请求...
@Teemu 我完全理解这一点，但是 DOM XSS 可以（并且确实）在不涉及任何服务器的情况下出现，在这种情况下，您确实需要在客户端上进行编码（即使使用正确的设施隐含） .
@GaborLengyel 这种编码有什么价值？用户可以通过 DevTools 甚至使用扩展在页面上注入和执行他们想要的任何代码。如果有人想破解他们自己的帐户或其他东西，您无法阻止它。不过，如果您要链接到第三方脚本，那么进行一些检查可能会有用。

标签： javascript security xss

【解决方案1】：

您编码数据（严格来说，只有可能包含用户输入的数据，但很多时候它更容易应用于所有数据）就在它被插入页面 DOM 之前。在不同的场景中，这意味着不同的东西，这会导致很多混乱。

要直接回答您的问题之一，您不要在将数据发送到服务器之前或将其插入数据库或其他东西之前对其进行编码。通常，您不会在请求端对数据进行编码。原因是在复杂的应用程序中，您不知道数据将在何处以及在什么上下文中呈现，并且对于不同的上下文，您可能需要不同的编码。您的输入层与此无关，但这不仅仅是一个架构问题，在您知道要如何呈现该数据之前，您无法选择编码。

当然，这并不意味着您不会在请求期间将其编码为它直接进入的任何“输出”。例如，如果您有一个 SQL 数据库，您可以应用编码来防止 SQL 注入，但这是通过使用适当的数据访问层、参数化查询等自动完成的。如果在请求期间进入 XML，您还可以应用适当的 xml 编码等等。但这与 XSS 无关，它与防止其他注入漏洞有关，这些事情很可能是由您的语言或框架自动完成的，除非您做一些不寻常或不太频繁的事情。

您还可以对任何输入应用输入验证，您可以验证格式（例如电子邮件地址或日期），或者您可以验证所需的字符集等等。

但一般来说，存储从客户端接收到的数据并没有任何实际编码没有任何问题。事实上，在大多数情况下这是正确的做法（见下文了解例外情况）。

然后，只要该数据以任何方式输出，以 HTML 呈现，用于后端查询（可以是 LDAP 或 SMTP 或 SQL 或其他任何方式），您就可以根据您正在使用的上下文应用适当的编码数据。对于 html，您应用 html 编码，但例如对于 javascript（html 可以包含 javascript 块，这也适用！）您应用 javascript 编码。这是一般的输出。

话虽如此，有一些……好吧，我们称它们为特殊情况。

现代 javascript 应用程序（如单页前端）可能无需与服务器通信即可管理大量数据。用户输入有时会被写在所有地方等等。在这种情况下，SPA 的工作就是在向页面 DOM 中插入内容时应用适当的编码。这主要意味着使用您选择的框架的安全设施，大多数现代框架在默认情况下都非常擅长这一点，但是您需要知道实际将什么以及如何编码以防止 XSS。这在复杂的 SPA 中一点也不简单。可能最复杂的情况是当您想故意从客户端接收 html（假设您有一个 html 编辑器小部件），将其保存到服务器，然后再次在 SPA 中显示它，可能在编辑时具有预览功能，但这是一个单独的（大）主题，只是需要小心。

“不在数据库中编码内容”规则的一个例外可能是大型、复杂的遗留应用程序。有时您不能保证所有（旧版）数据前端都将应用正确的编码，因此您可能决定在将数据写入数据库之前对其进行编码。这样做的问题是，你甚至不能正确地编写新代码，因为如果你再次应用编码，数据将被双重编码，这也是错误的。

【讨论】：