htmlencoding 是避免 SQL 注入攻击的合适解决方案吗？
我听说它声称防止 SQL 注入攻击的最简单解决方案是在插入数据库之前对所有文本进行 html 编码。然后，显然，在提取文本时对其进行解码。这个想法是，如果文本只包含＆符号、分号和字母数字，那么你就不能做任何恶意的事情。
虽然我看到许多这种方法似乎有效的案例，但我预见到使用这种方法会出现以下问题：
- 它声称是灵丹妙药。可能会阻止该技术的用户理解所有可能的相关问题 - 例如二阶攻击。
- 它不一定能防止任何二阶/延迟有效负载攻击。
- 它使用工具的目的与设计目的不同。这可能会导致代码的未来用户/开发人员/维护人员感到困惑。它的效果也可能远非最佳。
- 它给数据库的每次读写增加了潜在的性能影响。
- 它使得直接从数据库读取数据变得更加困难。
- 它增加了磁盘上数据的大小。 （现在每个字符约为 5 个字符 - 反过来，这也可能会影响磁盘空间要求、数据分页、索引大小和索引性能等？）
- 高范围 unicode 字符和组合字符是否存在潜在问题？
- 一些 html [en|de] 编码例程/库的行为略有不同（例如，有些编码撇号，有些则不编码。可能存在更多差异。）然后，这会将数据与用于读取和读取的代码联系起来。写下来。如果使用[en|de]编码不同的代码，则数据可能会被更改/损坏。
- 它可能会使处理（或至少调试）任何已经进行类似编码的文本变得更加困难。
我有什么遗漏的吗？
这实际上是防止 SQL 注入攻击问题的合理方法吗？
尝试以这种方式防止注入攻击是否存在任何根本问题？
I've heard it claimed that the simplest solution to preventing SQL injection attacks is to html encode all text before inserting into the database. Then, obviously, decode all text when extracting it. The idea being that if the text only contains ampersands, semi-colons and alphanumerics then you can't do anything malicious.
While I see a number of cases where this may seem to work, I foresee the following problems in using this approach:
- It claims to be a silver bullet. Potentially stopping users of this technique from understanding all the possible related issues - such as second-order attacks.
- It doesn't necessarily prevent any second-order / delayed payload attacks.
- It's using a tool for a purpose other than that which it was designed for. This may lead to confusion amongst future users/developers/maintainers of the code. It's also likley to be far from optimal in performance of effect.
- It adds a potential performance hit to every read and write of the database.
- It makes the data harder to read directly from the database.
- It increases the size of the data on disk. (Each character now being ~5 characters - In turn this may also impact disk space requirements, data paging, size of indexes and performance of indexes and more?)
- There are potential issues with high range unicode characters and combining characters?
- Some html [en|de]coding routines/libraries behave slightly differently (e.g. Some encode an apostrophe and some don't. There may be more differences.) This then ties the data to the code used to read & write it. If using code which [en|de]codes differently the data may be changed/corrupted.
- It potentially makes it harder to work with (or at least debug) any text which is already similarly encoded.
Is there anything I'm missing?
Is this actually a reasonable approach to the problem of preventing SQL injection attacks?
Are there any fundamental problems with trying to prevent injection attacks in this way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您应该通过使用参数绑定来防止 sql 注入（例如，永远不要将 sql 字符串与用户输入连接起来，而是使用参数的占位符并让您使用的框架进行正确的转义）。另一方面，应该使用 Html 编码来防止跨站点脚本编写。
You should prevent sql injection by using parameter bindings (eg. never concatenate your sql strings with user input, but use place holders for your parameters and let the framework you use do the right escaping). Html encoding, on the other hand, should be used to prevent cross-site scripting.
绝对不是。
应通过参数化查询来防止 SQL 注入。或者在最坏的情况下，通过转义 SQL 的 SQL 参数，而不是 HTML。每个数据库对此都有自己的规则，例如 mysql API（和大多数框架）为此提供了特定的函数。数据库中的数据本身在存储时不应被修改。
将 Web 内容返回到客户端浏览器时，转义 HTML 实体可以防止 XSS 和其他攻击。
Absolutely not.
SQL injections should be prevented by parametrized queries. Or in the worst case by escaping the SQL parameter for SQL, not HTML. Each database has its own rules about this, mysql API (and most frameworks) for example provides a particular function for that. Data itself in the database should not be modified when stored.
Escaping HTML entities prevents XSS and other attacks when returning web content to clients' browsers.
您如何得知 HTML 编码文本在解码后仅包含 & 符号、分号和字母数字？
我确实可以在 HTML 中对“'”进行编码 - 这是让您陷入麻烦的事情之一（因为它是 SQL 中的字符串分隔符）。
因此，只有将 HTML 编码文本放入数据库时它才有效。
然后你在任何文本搜索和外部可读文本的呈现上都会遇到一些麻烦（就像在 SQL 管理器中一样）。我认为这是一个非常糟糕的架构情况，因为您还没有解决问题，只是用胶带封住了明显的攻击向量。
数字字段仍然存在问题，除非您的 HTML 处理是完美的，考虑到解决方法，我不会假设这一点。
使用 SQL 参数；）
How you get the idea that HTML Encoded text only contains ampersands, semi-colons and alphanumerics after decoding?
I can really encode a "'" in HTML - and that is one of the things needed to get yo into trouble (as it is a string delimiter in SQL).
So, it works ONLY if you put the HTML encoded text into the database.
THEN you havequite some trouble with any text search... and presentation of readable text outside (like in SQL manager). I would consider that a really bad architected sitaution as you have not solved the issue just duct-taped away an obvious attack vector.
Numeric fields are still problematic, unless your HTML handling is perfect, which I would not assume given that workaround.
Use SQL parameters ;)
启用 SQL 注入的单个字符是 SQL 字符串分隔符
'，也称为十六进制 27 或十进制 39。该字符在 SQL 和 HTML 中的表示方式相同。因此 HTML 编码根本不会影响 SQL 注入攻击。
The single character that enables SQL injection is the SQL string delimer
', also known as hex 27 or decimal 39.This character is represented in the same way in SQL and in HTML. So an HTML encode does not affect SQL injection attacks at all.