PDO准备好的语句是否足以阻止SQL注入？

时间：2008-09-25 15:43:35

标签： php security pdo sql-injection

假设我有这样的代码：

$dbh = new PDO("blahblah");

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

PDO文件说：

  

不需要引用准备语句的参数;司机为你处理。

这是否真的是我需要做的就是避免SQL注入？真的那么容易吗？

如果它有所作为，你可以假设MySQL。另外，我真的只是对使用针对SQL注入的预处理语句感到好奇。在这种情况下，我不关心XSS或其他可能的漏洞。

7 个答案:

答案 0 :(得分：747)

简短的回答是 NO ，PDO准备不会保护您免受所有可能的SQL注入攻击。对于某些不起眼的边缘案例。

我正在调整this answer来讨论PDO ......

长期答案并非如此简单。它基于攻击demonstrated here。

攻击

所以，让我们开始展示攻击...... 

$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('SET NAMES 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()。但我们并未使用mysql_real_escape_string()。那么下一步......

  3. <强> $ stmt-＆GT;执行（）

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

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

    因此，对'的调用会插入反斜杠，我们在＆＃34;转义＆＃34;中有一个免费挂起的$var字符。内容！事实上，如果我们在gbk字符集中查看SELECT * FROM test WHERE name = '縗' OR 1=1 /*' LIMIT 1 ，我们会看到：

    縗' OR 1=1 /*

    这正是攻击所需要的。

  4. 查询

    这部分只是一种形式，但这里是渲染的查询：

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

    5. 恭喜，您刚刚使用PDO Prepared Statements成功攻击了一个程序...

    简单修复

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

    mysql_set_charset()

    这将通常导致真正准备好的语句（即，数据在查询的单独数据包中发送）。但是，请注意PDO将默默地fallback模拟MySQL无法本机准备的语句：手册中可能listed的语句，但要注意选择适当的服务器版本）。

    正确修复

    这里的问题是我们没有调用C API SET NAMES而不是mysql_real_escape_string()。如果我们这样做，只要我们从2006年开始使用MySQL版本，我们就可以了。

    如果你正在使用早期的MySQL版本，那么PDO中的bug意味着无效的多字节字符（例如我们的有效负载中的字符）被视为用于转义目的的单个字节即使客户端已正确通知连接编码，因此这种攻击仍然会成功。该错误已在MySQL 4.1.20，5.0.22和5.1.11中修复。

    但最糟糕的是，mysql_set_charset()没有公布SET NAMES的C API直到5.3.6，所以在以前的版本中不能阻止此攻击为每一个可能的命令！  现在它被公开为DSN parameter，应该使用代替 mysql_real_escape_string() ...

    拯救恩典

    正如我们在开始时所说的那样，要使此攻击起作用，必须使用易受攻击的字符集对数据库连接进行编码。 utf8mb4 不易受攻击并且可以支持每个 Unicode字符：因此您可以选择使用它 - 但它自MySQL 5.5.3起才可用。另一种选择是utf8，它也不易受攻击并且可以支持整个Unicode Basic Multilingual Plane。

    或者，您可以启用NO_BACKSLASH_ESCAPES SQL模式，该模式（以及其他内容）会改变0x27的操作。启用此模式后，0x2727将替换为0x5c27而不是0xbf27，因此转义进程无法在任何易受攻击的编码中创建有效字符以前不存在（即0xbf27仍然是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"); 等） - 所以服务器仍然会将该字符串拒绝为无效。但是，请参阅@eggyal's answer以了解使用此SQL模式可能产生的其他漏洞（尽管不使用PDO）。

    安全示例

    以下示例是安全的：

    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();

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

    utf8

    因为MySQLi一直都做真实的准备陈述。

    结束

    如果你：

    • 使用MySQL的现代版本（后期5.1，全部5.5,5.6等） AND PDO的DSN字符集参数（在PHP≥5.3.6中）

    或

    • 请勿使用易受攻击的字符集进行连接编码（仅使用latin1 / ascii / NO_BACKSLASH_ESCAPES / etc）

    或

    • 启用{{1}} SQL模式

    你100％安全。

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

    附录

    我一直在慢慢研究修补程序，将默认设置更改为不模拟准备未来版本的PHP。我遇到的问题是，当我这样做时，很多测试都会中断。一个问题是模拟的准备只会在执行时抛出语法错误，但真正的准备会在准备时抛出错误。因此，这可能会导致问题（并且是测试结果的一部分）。

答案 1 :(得分：503)

准备好的语句/参数化查询通常足以阻止 * 上的第一顺序注入。如果在应用程序中的任何其他位置使用未经检查的动态sql，则仍然容易受到第二顺序注入。

二阶注入意味着数据在被包含在查询中之前已经在数据库中循环了一次，并且更难以实现。 AFAIK，你几乎从来没有看到真正设计的二阶攻击，因为攻击者通常更容易进行社交工程，但是你有时会因为额外的良性'字符或类似物而出现二阶错误。 / p>

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

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

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

然后，我们看到，准备好的语句足以用于单个查询，但是它们本身不足以防止整个应用程序中的sql注入攻击，因为它们缺乏强制执行的机制所有对应用程序内数据库的访问都使用安全代码。但是，用作良好应用程序设计的一部分 - 可能包括代码审查或静态分析等实践，或者使用限制动态sql的ORM，数据层或服务层 - 准备好的语句 是解决Sql Injection问题的主要工具。 如果您遵循良好的应用程序设计原则，那么您的数据访问将与其他人分开程序，每个查询正确使用参数化变得容易执行或审计。在这种情况下，完全阻止sql注入（第一和第二顺序）。

* 事实证明，当涉及到宽字符时，MySql / PHP对于处理参数只是愚蠢（还可以），而且还有稀有 other highly-voted answer here中概述的案例，可以允许注入通过参数化查询。

答案 2 :(得分：39)

不，他们并不总是。

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

$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。

答案 3 :(得分：24)

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

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

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

答案 4 :(得分：24)

这还不够（在某些特定情况下）！默认情况下，当使用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');

另请参阅此相关问题：How can I prevent SQL injection in PHP?

另请注意，这只是关于数据库方面的事情，您在显示数据时仍需要注意自己。例如。通过使用正确的编码和引用样式再次使用htmlspecialchars()。

答案 5 :(得分：9)

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

答案 6 :(得分：-1)

Eaven如果你要阻止sql注入前端，使用html或js检查，你必须考虑前端检查是否可绕过＆＃34;。

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

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

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

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

安全性有成本，但不要浪费你的表现！

简单的例子：

如果你想仔细检查从GET收到的值是否小于99     （！的preg_match（＆＃39; / [0-9] {1,2} /＆＃39;））如果{...} 

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

所以，最终答案是：＆＃34;不！ PDO准备语句不会阻止所有类型的SQL注入＆＃34 ;;它不会阻止意外值，只会意外连接

相关问题
最新问题