php - MYSQL 不安全但为什么

Question

这个问题已经有答案了:

Sql Injection protection with only str_replace (1 个回答)

Is mysql_real_escape_string() broken? (3 个回答)

已关闭 7 年前。

我有一个用 MYSQL 和 PHP 创建的应用程序，据说 MYSQL 会受到 SQL 注入(inject) - (我尊重这一点)但为什么呢？我的代码在这种情况下可以正常工作，或者有人可以证明我错了吗？

有一个包含 2 个字段的表单，用户名和密码，我将其发布在页面上。这是我的代码:

$user = stripslashes($user);
$pwd = trim($pwd);
$pwd = stripslashes($pwd);
$user = mysql_real_escape_string($user);
$pwd = mysql_real_escape_string($pwd);
$pwd = md5($pwd);

$rs = mysql_query("select * from `login` where upper(USER_ID) = upper('$user') AND PASS = '$pwd'");

我的用户名是管理员。

所以，这就是我的代码，我正在进行转义，这怎么会受到SQL注入(inject)呢？对于那些认为 PDO 是 future 的人来说，这是一个公开的挑战 :)。

谢谢。

Answer 1

$user = stripslashes($user);

只要您使用 addslashes 就可以了首先。

$pwd = trim($pwd);

我不喜欢这样，因为您正在默默地从我选择的密码中删除字符。如果我的密码是:" liIo1sor&DINg "怎么办？ ？

mysql_real_escape_string(x)

这样做的问题是，您正在拒绝一种替代方案，这种方案本质上可以确保您容易受到 SQLi 的攻击，而不是转义，而转义则可能会出现一些随机漏洞并破坏您的网站。

来自:http://php.net/manual/en/pdo.prepared-statements.php

If an application exclusively uses prepared statements, the developer can be sure that no SQL injection will occur (however, if other portions of the query are being built up with unescaped input, SQL injection is still possible).

这是来自官方 PHP 文档。你的方法可能是安全的，但是你有一个非常完美的方法可用......那么为什么要选择可能安全的方法呢？

所以让我们假设 mysql_real_escape_string()是完美的，将普遍防止注入(inject)。您仍然遇到一个问题，如果您按照本文中的方式构建所有 SQL 查询，那么您(或其他开发人员)可能会添加一个参数，然后忘记转义它 。这不是一个安全的起点，并且鼓励冒险的开发。

md5($pwd);

正如其他人所说，md5 不应该用于散列密码。如果可以的话，您应该使用 bcrypt、scrypt 或 pbkdf2。您还省略了每个用户独特且随机的盐。如果您决定不使用准备好的语句，这一点尤其重要，因为您的数据库将不可避免地被盗(开玩笑:P)。有关存储密码的更多信息:https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords