PDO 准备好的语句足以防止 SQL 注入吗？

Question

假设我有这样的代码：

$dbh = new PDO("blahblah");

$stmt = $dbh->prepare('SELECT * FROM users where username = :username');
$stmt->execute( array(':username' => $_REQUEST['username']) );

PDO 文档说：

准备好的语句的参数不需要加引号； 司机会为您处理。

这真的是我需要做的一切来避免 SQL 注入吗？ 真的那么容易吗？

如果 MySQL 有影响的话，你可以假设它。 另外，我真的只是对使用准备好的语句来对抗 SQL 注入感到好奇。 在这种情况下，我不关心 XSS 或其他可能的漏洞。

Answer 1

简短的回答是是，如果使用得当，PDO 准备是足够安全的。

---

我正在改编 这个答案来讨论 PDO...

长答案并不那么容易。 它基于此处演示的攻击。

攻击

那么，让我们首先展示攻击......

$pdo->query('SET NAMES gbk');
$var = "\xbf\x27 OR 1=1 /*";
$query = 'SELECT * FROM test WHERE name = ? LIMIT 1';
$stmt = $pdo->prepare($query);
$stmt->execute(array($var));

在某些情况下，这将返回超过 1 行。 让我们剖析一下这里发生的事情：

1. 选择字符集

   $pdo->query('设置名称 gbk'); 
     

   要使此攻击发挥作用，我们需要服务器期望连接上的编码将 ' 编码为 ASCII，即 0x27 和 得到一些最终字节为 ASCII \ 的字符，即 0x5c。 事实证明，MySQL 5.6 默认支持 5 种这样的编码：big5、cp932、gb2312、gbk和<代码>sjis。 我们将在这里选择gbk。

   现在，请注意此处 SET NAMES 的使用，这一点非常重要。 这将字符集设置在服务器上。 还有另一种方法可以做到这一点，但我们很快就会实现。

2. 有效负载

   我们将用于此注入的有效负载以字节序列 0xbf27 开头。 在 gbk 中，这是一个无效的多字节字符； 在 latin1 中，它是字符串 ¿'。 请注意，在 latin1 和 gbk 中，0x27 本身就是一个文字 '性格。

   我们选择此有效负载是因为，如果我们对其调用 addslashes()，我们将插入一个 ASCII \ 即 0x5c，在 ' 字符之前。 因此，我们最终会得到 0xbf5c27，它在 gbk 中是一个两个字符序列：0xbf5c 后跟 0x27 。 或者换句话说，一个有效字符后跟一个未转义的'。 但我们没有使用 addslashes()。 那么继续下一步...

3. $stmt->execute()

   这里要认识到的重要一点是，PDO 默认情况下不执行真正的准备好的语句。 它模拟它们（对于 MySQL）。 因此，PDO 在内部构建查询字符串，对每个绑定字符串值调用 mysql_real_escape_string() （MySQL C API 函数）。

   对 mysql_real_escape_string() 的 C API 调用与 addslashes() 的不同之处在于它知道连接字符集。 因此它可以对服务器期望的字符集正确执行转义。 然而，到目前为止，客户端认为我们仍在使用 latin1 进行连接，因为我们从未告诉过它。 我们确实告诉服务器我们正在使用gbk，但客户端仍然认为它是latin1。

   因此，对 mysql_real_escape_string() 的调用会插入反斜杠，并且我们的“转义”内容中有一个自由悬挂的 ' 字符！ 事实上，如果我们查看 gbk 字符集中的 $var，我们会看到：

   缞' OR 1=1 /*

   这正是攻击所需要的。

4. 查询

   这部分只是形式，但这是呈现的查询：

   SELECT * FROM test WHERE name = '缞' OR 1=1 /*' LIMIT 1 
     

恭喜，您刚刚使用 PDO 准备语句成功攻击了一个程序...

简单的修复

现在，值得注意的是您可以防止这种情况发生通过禁用模拟准备语句：

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

这通常会产生真正的准备语句（即数据在与查询不同的数据包中发送）。 但是，请注意，PDO 会默默后备 模拟 MySQL 本身无法准备的语句：它可以的语句是 手册中列出，但要注意选择合适的服务器版本）。

正确的修复

这里的问题是我们使用了SET NAMES而不是C API的mysql_set_charset()。 否则的话，攻击就不会成功。 但最糟糕的是，PDO 直到 5.3.6 才公开 mysql_set_charset() 的 C API，因此在之前的版本中，它无法针对每个可能的命令阻止这种攻击！
它现在公开为 DSN 参数，应该是使用而不是 SET NAMES...

前提是我们使用 2006 年以来的 MySQL 版本。如果您使用的是早期的 MySQL 版本，则 mysql_real_escape_string() 中的“http://bugs.mysql.com/bug.php?id=8378” rel="noreferrer">bug 意味着无效的多字节字符，例如我们的有效负载被视为用于转义目的的单个字节即使客户端已被正确告知连接编码，因此这种攻击仍然会成功。 该错误已在 MySQL 4.1.20，5.0.22 和 5.1.11 。

正如

我们在一开始所说的，要使这种攻击起作用，数据库连接必须使用易受攻击的字符集进行编码。 utf8mb4 不是容易受到攻击，但可以支持每个 Unicode 字符：因此您可以选择使用它，但它从 MySQL 5.5.3 起才可用。 另一种选择是 utf8，也不易受攻击，并且可以支持整个 Unicode Basic多语言飞机。

或者，您可以启用 NO_BACKSLASH_ESCAPES SQL 模式，它（除其他外）改变 mysql_real_escape_string() 的操作。 启用此模式后，0x27 将被替换为 0x2727 而不是 0x5c27，因此转义进程无法创建有效的以前不存在的任何易受攻击的编码中的字符（即 0xbf27 仍然是 0xbf27 等），因此服务器仍会拒绝该字符串，因为该字符串无效。 但是，请参阅 @eggyal 的回答，了解使用此 SQL 模式（尽管不是使用 PDO）可能产生的不同漏洞。

安全示例

以下示例是安全的：

mysql_query('SET NAMES utf8');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

因为服务器期望 utf8...

mysql_set_charset('gbk');
$var = mysql_real_escape_string("\xbf\x27 OR 1=1 /*");
mysql_query("SELECT * FROM test WHERE name = '$var' LIMIT 1");

因为我们已经正确设置了字符集，以便客户端和服务器匹配。

$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$pdo->query('SET NAMES gbk');
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

因为我们已经关闭了模拟准备语句。

$pdo = new PDO('mysql:host=localhost;dbname=testdb;charset=gbk', $user, $password);
$stmt = $pdo->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$stmt->execute(array("\xbf\x27 OR 1=1 /*"));

因为我们已经正确设置了字符集。

$mysqli->query('SET NAMES gbk');
$stmt = $mysqli->prepare('SELECT * FROM test WHERE name = ? LIMIT 1');
$param = "\xbf\x27 OR 1=1 /*";
$stmt->bind_param('s', $param);
$stmt->execute();

因为 MySQLi 始终执行真正的准备好的语句。

总结

如果您：

• 使用现代版本的 MySQL（5.1 晚期、所有 5.5、5.6 等）和 PDO 的 DSN 字符集参数（在 PHP ≥ 5.3.6 中）

OR

• Don不使用易受攻击的字符集进行连接编码（仅使用 utf8 / latin1 / ascii / 等）

OR

• 启用 NO_BACKSLASH_ESCAPES SQL 模式

您 100% 安全。

否则，即使您正在使用 PDO 准备语句，您也很容易受到攻击...

附录

我一直在慢慢地开发一个补丁，以将默认值更改为不模拟为未来版本的 PHP 做准备。 我遇到的问题是，当我这样做时，很多测试都会中断。 一个问题是模拟的准备只会在执行时抛出语法错误，但真正的准备会在准备时抛出错误。 因此这可能会导致问题（这也是测试失败的部分原因）。

Answer 2

准备好的语句/参数化查询足以防止 SQL 注入，但仅限于应用程序中的每个查询始终使用时。

如果您在应用程序的其他任何地方使用未经检查的动态 SQL，它仍然容易受到二阶注入的攻击。

二阶注入意味着数据在包含在查询中之前已在数据库中循环一次，并且更难实现。 AFAIK，您几乎从未见过真正设计的二阶攻击，因为攻击者通常更容易通过社交工程进入，但有时会因为额外的良性 ' 字符或而出现二阶错误相似的。

当您可以将一个值存储在数据库中并稍后在查询中用作文字时，您就可以完成二阶注入攻击。 举个例子，假设您在网站上创建帐户时输入以下信息作为新用户名（假设此问题使用 MySQL 数据库）：

' + (SELECT UserName + '_' + Password FROM Users LIMIT 1) + '

如果用户名没有其他限制，准备好的语句仍将确保上面的嵌入查询在插入时不会执行，并将值正确存储在数据库中。 但是，想象一下，稍后应用程序从数据库中检索您的用户名，并使用字符串连接将该值包含在新查询中。 您可能会看到其他人的密码。 由于用户表中的前几个名称往往是管理员，因此您可能也刚刚放弃了农场。 （另请注意：这是不以纯文本形式存储密码的又一个原因！）

然后，我们看到，如果预准备语句仅用于单个查询，而忽略其他一些查询，则它们不如果您遵循良好的应用程序设计原则，以便将数据访问与程序的其余部分分开，则可以轻松执行或审核每个查询是否正确使用参数化。 在这种情况下，sql注入（一阶和二阶）都被完全阻止。

---

_{^*事实证明，MySql/PHP（很久很久以前）在涉及宽字符时处理参数方面很愚蠢，并且有一种罕见情况这里的其他高票答案中概述了它可以允许注入通过参数化查询。}

Answer 3

不，他们并不总是这样。

这取决于您是否允许将用户输入放置在查询本身中。 例如：

$dbh = new PDO("blahblah");

$tableToUse = $_GET['userTable'];

$stmt = $dbh->prepare('SELECT * FROM ' . $tableToUse . ' where username = :username');
$stmt->execute( array(':username' => $_REQUEST['username']) );

容易受到 SQL 注入攻击，并且在此示例中使用准备好的语句将不起作用，因为用户输入用作标识符，而不是数据。 这里正确的答案是使用某种过滤/验证，例如：

$dbh = new PDO("blahblah");

$tableToUse = $_GET['userTable'];
$allowedTables = array('users','admins','moderators');
if (!in_array($tableToUse,$allowedTables))    
 $tableToUse = 'users';

$stmt = $dbh->prepare('SELECT * FROM ' . $tableToUse . ' where username = :username');
$stmt->execute( array(':username' => $_REQUEST['username']) );

注意：您不能使用 PDO 绑定 DDL（数据定义语言）之外的数据，即这不起作用：

$stmt = $dbh->prepare('SELECT * FROM foo ORDER BY :userSuppliedData');

上述方法的原因不起作用是因为 DESC 和 ASC 不是数据。 PDO 只能转义数据。 其次，你甚至不能在它周围加上 ' 引号。 允许用户选择排序的唯一方法是手动过滤并检查它是 DESC 或 ASC。

Answer 4

不，这还不够（在某些特定情况下）！ 默认情况下，当使用 MySQL 作为数据库驱动程序时，PDO 使用模拟的准备语句。 使用 MySQL 和 PDO 时，您应该始终禁用模拟的准备好的语句：

$dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

始终应该做的另一件事是设置数据库的正确编码：

$dbh = new PDO('mysql:dbname=dbtest;host=127.0.0.1;charset=utf8', 'user', 'pass');

另请参阅此相关问题：如何防止 PHP 中的 SQL 注入？

请注意，这只能保护您免受 SQL 注入，但您的应用程序仍然可能容易受到其他类型的攻击。 例如，您可以通过使用正确的编码和引用样式再次使用 htmlspecialchars() 来防止 XSS。

Answer 5

是的，这就足够了。 注入类型攻击的工作方式是通过某种方式让解释器（数据库）来评估应该是数据的东西，就好像它是代码一样。 仅当您在同一介质中混合代码和数据时（例如，当您将查询构造为字符串时），这才有可能。

参数化查询通过分别发送代码和数据来工作，因此永远不可能在其中找到漏洞。

不过，您仍然可能容易受到其他注入类型的攻击。 例如，如果您在 HTML 页面中使用数据，您可能会受到 XSS 类型的攻击。

Answer 6

就我个人而言，我总是首先对数据进行某种形式的清理，因为您永远不能信任用户输入，但是当使用占位符/参数绑定时，输入的数据将单独发送到服务器的 sql 语句，然后绑定在一起。 这里的关键是，这将提供的数据绑定到特定类型和特定用途，并消除了更改 SQL 语句逻辑的任何机会。

Answer 7

即使您要使用 html 或 js 检查来防止前端 sql 注入，您也必须考虑前端检查是“可绕过的”。

您可以禁用js或使用前端开发工具（现在由firefox或chrome内置）编辑模式。

因此，为了防止 SQL 注入，清理控制器内的输入日期后端是正确的。

我建议您使用 filter_input() 本机 PHP 函数来清理 GET 和 INPUT 值。

如果您想继续安全性，为了合理的数据库查询，我想建议您使用正则表达式来验证数据格式。
preg_match() 在这种情况下会帮助你！
但要小心！ 正则表达式引擎并不那么轻。 仅在必要时使用它，否则您的应用程序性能将会降低。

安全是有成本的，但不要浪费你的性能！

简单的例子：

如果你想仔细检查从 GET 收到的值是否是一个数字，小于 99
if(!preg_match('/[0-9]{1,2}/')){...}
所以

if (isset($value) && intval($value)) <99) {...}

，最终的答案是：“不！PDO 准备语句不能阻止所有类型的 sql 注入”； 它不会阻止意外的值，只是阻止意外的串联