在插入数据库而不是输出之前逃避HTML是一个坏主意吗？

Question

我一直在研究一个不允许HTML格式化的系统.我目前使用的方法是在HTML实体插入数据库之前将其转义.我被告知我应该将原始文本插入数据库,并在输出时转义HTML实体.

我在这里看到的其他类似问题看起来像HTML仍然可以用于格式化的情况,所以我要求的情况是根本不会使用HTML.

Answer 1

是的,因为在某个阶段您需要访问输入的原始输入.这是因为...

• 你永远不知道你想如何显示它 - 用JSON,HTML,作为短信？
• 您可能需要按原样将其显示给用户.

我确实看到了你从不想输入HTML的观点.你还用什么去剥离HTML标签？如果它是正则表达式,那么请留意可能输入类似内容的混淆用户...

3<4 :->

3如果它是一个正则表达式,他们只会得到它.

Answer 2

在插入数据库之前执行转义时,您也会限制自己.假设您决定不使用HTML作为输出,而是使用JSON,纯文本等.

如果你已经在你的数据库中存储了转义的html,你首先必须'unescape'存储在数据库中的值,只是为了再次将它重新转换为不同的格式.

还看到了关于xss预防的完美owasp文章

Answer 3

1. 假设您有文本R&B，并将其存储为R&B. 如果有人搜索R&B，它不会与搜索 SQL 匹配：

   SELECT * FROM table WHERE title LIKE ?
   

   对于相等、排序等也是如此。

   或者，如果有人搜索life span，它可能会返回与转义的无关的匹配项<span>。虽然这有点正交，但可以通过使用 Elasticsearch 等外部服务或将原始文本版本存储在另一个字段中来解决；类似于@limscoder 的建议。

2. 如果您通过 API 公开数据，消费者可能不会期望数据被转义。添加文档可能会有所帮助。

3. 几个月后，一名新的团队成员加入。作为一名训练有素的开发人员，他总是使用 HTML 转义，现在只看到所有内容都是双重转义的（例如，标题显示为类似He said "nuff"而不是He said "nuff"）。

4. 一些转义函数有附加选项。在取消转义时忘记使用相同的函数/选项可能会导致与原始值不同的值。

   当多个开发人员/消费者处理相同的数据时，更有可能发生这种情况。