htmlencoding是一个避免SQL注入攻击的合适解决方案吗？

Question

我听说它声称防止SQL注入攻击的最简单的解决方案是在插入数据库之前对所有文本进行html编码。然后，显然，在解压缩时解码所有文本。这个想法是，如果文本只包含＆符号，分号和字母数字，那么你就不能做任何恶意的事情。

虽然我看到一些似乎有效的案例，但我预见到使用这种方法会出现以下问题：

• 它声称是一颗银弹。可能会阻止此技术的用户理解所有可能的相关问题 - 例如二阶攻击。
• 它不一定能阻止任何二阶/延迟有效载荷攻击。
• 它使用的工具不是为其设计的目的。这可能导致代码的未来用户/开发者/维护者之间的混淆。它也可能与效果的表现相差甚远。
• 它为每次读取和写入数据库增加了潜在的性能损失。
• 它使数据更难直接从数据库中读取。
• 它增加了磁盘上数据的大小。 （每个字符现在约为5个字符 - 反过来，这也可能影响磁盘空间要求，数据分页，索引大小和索引性能等等？）
• 高范围unicode字符和组合字符可能存在问题吗？
• 某些html [en | de]编码例程/库的行为略有不同（例如，某些编码撇号，有些则不编码。可能会有更多差异。）然后，这会将数据与用于读取的代码相关联。写下来。如果使用[en | de]编码不同的代码，则数据可能会被更改/损坏。
• 这可能会使处理（或至少调试）任何已经类似编码的文本变得更加困难。

我有什么遗失的吗？ 这实际上是解决SQL注入攻击问题的合理方法吗？ 试图以这种方式防止注射攻击是否有任何根本问题？

Answer 1

你应该通过使用参数绑定来阻止sql注入（例如，永远不要将sql字符串与用户输入连接，但是使用占位符作为参数，让你使用的框架做正确的转义）。另一方面，Html编码应该用于防止跨站点脚本。

Answer 2

绝对不是。

参数化查询应该阻止SQL注入。或者在最糟糕的情况下，通过转义SQL的SQL参数，而不是HTML。每个数据库都有自己的规则，例如mysql API（和大多数框架）为此提供了特定的功能。存储时不应修改数据库中的数据本身。

在将Web内容返回到客户端的浏览器时，转义HTML实体可防止XSS和其他攻击。

Answer 3

您如何理解HTML编码文本在解码后仅包含＆符号，分号和字母数字？

我真的可以在HTML中编码一个“'” - 这是让你遇到麻烦所需的事情之一（因为它是SQL中的字符串分隔符）。

因此，仅当您将HTML编码文本放入数据库时​​，它才有效。

那么你在任何文本搜索中都会遇到麻烦......并且可以在外面呈现可读文本（比如在SQL管理器中）。我认为这是一个非常糟糕的架构设置，因为你还没有解决问题，只是用管道录下了一个明显的攻击向量。

数字字段仍然存在问题，除非您的HTML处理是完美的，鉴于此解决方法，我不会假设。

使用SQL参数;）

Answer 4

启用SQL注入的单个字符是SQL字符串delimer '，也称为十六进制27或十进制39。

此字符在SQL和HTML中以相同的方式表示。因此，HTML编码根本不会影响SQL注入攻击。