哪些 SQL 注入方法不会被“破坏”？通过 mysql_real_escape_string();？

发布于 2024-11-19 19:12:00 字数 212 浏览 2 评论 0原文

是否存在仅使用 utf8 编码的 mysql_real_escape_string(); 无法保护的 SQL 注入方法列表？

对于整数，我使用 intval(); 它足够安全吗？

对于那些认为我想获得“教程”来攻击任何人的人：不，我不会。我只是想知道如何让我的应用程序更加安全，并且我想知道它们是否能够 99% 地抵御黑客攻击

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

献世佛 2024-11-26 19:12:00

如果给定有效的数据库连接，mysql_real_escape_string() 在所有情况下都应该是安全的字符串数据（除了这个答案）。

但是，字符串之外的任何内容，它都不会转义：

$id = mysql_real_escape_string($_GET["id"]);

mysql_query("SELECT * FROM table WHERE id = $id");

仍然容易受到攻击，因为您不必“突破”字符串来添加邪恶的附加命令。

If given a valid database connection, mysql_real_escape_string() is supposed to be safe for string data under all circumstances (with the rare exception described in this answer).

However, anything outside a string, it won't escape:

$id = mysql_real_escape_string($_GET["id"]);

mysql_query("SELECT * FROM table WHERE id = $id");

is still vulnerable, because you don't have to "break out" of a string to add an evil additional command.

回复收藏 0 原文

桃酥萝莉 2024-11-26 19:12:00

sql注入的方法并不多。它们总是由于输入没有被正确清理和转义造成的。因此，虽然 mysql_real_escape_string() 将使任何字符串安全地包含在数据库查询中，但您应该遵循以下避免技术来保护您的数据和用户免受 SQL 注入。

切勿以超级用户或数据库所有者的身份连接到数据库。始终使用权限非常有限的自定义用户。
检查给定的输入是否具有预期的数据类型。
如果应用程序等待数字输入，请考虑使用 is_numeric() 验证数据，或使用 settype() 默默地更改其类型
引用传递给的每个非数字用户提供的值具有特定于数据库的字符串转义函数的数据库。因此 mysql_real_escape_string() 将使所有字符串安全地包含在对 mysql 数据库的 SQL 查询中
您还可以学习使用存储过程和预准备语句，它们往往非常安全，但会产生其他影响

另请参阅: 关于 SQL 注入的 PHP 页面