HTML应该在持久化之前进行编码吗？

HTML应该在存储到数据库之前进行编码吗？或者，在进入浏览器时进行编码是正常的做法吗

数据库中所有基于文本的字段长度是否应该增加四倍以允许额外存储

---

寻找最佳实践，而不是一个明确的是或否：-）

出于安全原因，是的，您应该首先将html转换为它们的实体，然后插入到数据库中。当您允许用户（或者更确切地说是坏人）使用html标记，然后您将它们处理/插入到数据库中时，就会发起诸如XSS之类的攻击。XSS是大多数安全漏洞的根本原因之一。因此，您肯定需要在存储html之前对其进行编码。

做法是在显示之前对html进行编码

如果您在显示之前对编码保持一致，那么您已经做好了一点

XSS

预防工作

---

您应该将原始表单保存在数据库中。这保留了原始版本，您可能希望对其执行其他处理，而不是对编码版本执行其他处理。

数据库中的数据是真正的HTML还是应用程序数据，如您刚刚知道的名称或注释，最终将作为HTML页面的一部分

如果是应用程序数据，我认为最好：

• 以环境固有的形式表示它（例如，在数据库中未编码），以及
• 确保其在跨越代表性边界时正确翻译（生成HTML页面时进行编码）

如果您是MVC的粉丝，这也有助于将视图/控制器与模型（以及持久存储格式）分离

表示法

例如，假设有人留下评论“我爱M&M”。在代码中用纯文本字符串

“我爱M&M”

表示它可能是最容易的，而不是用HTML编码的字符串

“我爱M&M”

。从技术上讲，代码中存在的数据还不是HTML，如果数据尽可能简单、准确地表示，那么使用起来就最容易了。这些数据以后可能会在不同的视图中使用，例如桌面应用程序。这些数据可能存储在数据库、平面文件或XML文件中，以后可能与其他程序共享。对于另一个程序来说，最简单的假设是字符串的格式为“本机”表示：

“我爱M&Ms”

在数据库和平面文件中，而

“我爱M&Ms”

在XML文件中。如果看到编码在XML文件中的HTML编码值（

“I love&；amp；Ms”

），我会感到畏缩

翻译

稍后，当数据即将跨越表示边界（例如，以HTML显示、存储在数据库、纯文本文件或XML文件中）时，重要的是确保数据已正确转换，以便以下一个环境固有的格式准确表示。简而言之，当您要在HTML页面上显示它时，请确保将其翻译为正确编码的HTML（手动或通过工具），以便在页面上准确显示该值。当您将其存储在数据库中或在查询中使用时，请使用转义和/或准备好的语句和绑定变量，以确保在数据库中准确表示相同的概念值。当您将其存储在XML文件中时，确保对其进行XML编码

在跨越表示边界时未能正确转换是注入攻击（如SQL注入攻击）的来源。当您使用多种表示/语言（例如Java、SQL、HTML、Javascript、XML等）时，请注意这一点

--

---

另一方面，如果您真的试图将HTML页面片段保存到数据库中，那么我不清楚您所说的“存储前编码”是什么意思。如果它是严格有效的HTML，那么所有必要的值都应该已经编码（例如，

&；

，

，等等）。

数据库供应商特定的输入转义，HTML转义输出。

我不同意任何人认为它应该在显示时解码，只有开发人员在显示之前对其进行解码，才能在其到达数据库之前对其进行编码，从而发生攻击。然而，如果你在展示它之前对它进行解码，那么它总是有可能被其他新手开发人员所使用，比如新员工或者糟糕的实现。如果它坐在那里不编码，它只是在等待在互联网上弹出，像疱疹一样传播。丢失原始数据不应该是一个问题。编码+解码每次都应产生相同的数据。只有我的两分钱。

最佳实践通常是社区维基。：）嗯，我试图避免对每个请求进行编码，因为这是一项重复的任务。有趣的是：）+1在显示时编码很好，而不是在存储时编码，因为如果你需要以不同的方式处理原始数据，你将拥有原始数据。这可能并不总是好的，因为我在这里丢失了原始数据@Mahesh如果原始数据是XSS攻击怎么办？将恶意HTML插入数据库不会带来安全风险。只有将恶意HTML呈现给浏览器才是一个问题。因此，在将HTML插入数据库时，不必用字符引用替换HTML特殊字符。只需要替换/转义SQL的上下文特殊字符。