`addslashes()` 真的可以防止 SQL 注入吗？为什么应该使用 `mysql_real_escape_string()` 来代替？

addslashes() 与 mysql_real_escape_string() 预防 SQL 注入

虽然经常被吹捧为 addslashes() 的更安全替代方案，但 mysql_real_escape_string() 仍然是防止 PHP 应用程序中 SQL 注入漏洞的推荐方法。了解 addslashes() 的局限性是构建强大安全性的关键。

考虑一下：依赖于 addslashes() 进行用户输入清理的 SQL 查询遇到包含单引号 (') 的字符串。 addslashes() 可能会错误地将此引号识别为多字节字符的一部分，从而使查询容易受到注入。

攻击者可以通过附加连字符 (-) 或类似的字符来终止某些 Unicode 编码（如 ISO-8859-1，但不是 UTF-8）中的多字节序列，从而利用此漏洞。这会欺骗 addslashes() 将单引号视为有效多字节字符的一部分，绕过转义机制并允许恶意代码执行。

该漏洞是特定于编码的。 UTF-8 是一种广泛使用的 Unicode 编码，通常不会受到这种特定攻击，因为它不使用相同的多字节终止字符。

为了获得最佳的 SQL 注入保护，请始终将 mysql_real_escape_string() 优先于 addslashes()。 通过应用程序级输入验证和使用准备好的语句进行数据库交互来补充这一点。 通过承认 addslashes() 的弱点并实施这些最佳实践，开发人员可以显着降低 SQL 注入攻击的风险。

以上是`addslashes()` 真的可以防止 SQL 注入吗？为什么应该使用 `mysql_real_escape_string()` 来代替？的详细内容。更多信息请关注PHP中文网其他相关文章！