PDO准备好的语句是否足以防止SQL注入?
假设我有这样的代码:
$dbh = new PDO("blahblah");$stmt = $dbh->prepare('SELECT * FROM users where username = :username');
$stmt->execute( array(':username' => $_REQUEST['username']) );
PDO文档说:
准备好的语句的参数不需要用引号引起来。司机为您处理。
您可以假设MySQL会有所作为。另外,我真的只是对针对SQL注入使用准备好的语句感到好奇。在这种情况下,我不在乎XSS或其他可能的漏洞。
回答:
简短的回答是“ ,PDO准备将不会为您防御所有可能的SQL注入攻击。对于某些晦涩的边缘情况。
攻击
因此,让我们开始展示攻击…
$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行以上。让我们剖析这里发生的事情:
$pdo->query('SET NAMES gbk');
对于这种攻击的工作,我们所需要的编码服务器的期望既编码的连接'
为ASCII即0x27
和 有一些文字,其最后一个字节是一个ASCII\
即0x5c
。事实证明,会默认在MySQL
5.6支持5个这样的编码:big5
,cp932
,gb2312
,gbk
和sjis
。我们将gbk
在此处选择。
现在,注意SET NAMES
这里的用法非常重要。这将在 设置字符集。还有另一种方法,但是我们会尽快到达那里。
我们将用于此注入的有效负载从字节序列开始0xbf27
。在中gbk
,这是一个无效的多字节字符;在latin1
,这是字符串¿'
。请注意,在latin1
gbk
,0x27
对自己是一个文字'
字符。
我们选择此有效负载是因为,如果调用addslashes()
它,我们会在字符之前插入一个ASCII码,\
即。因此,我们将以结束,其中有两个字符序列:后跟。换句话说,就是一个
有效 字符,后跟一个未转义的。但是我们没有使用。继续下一步…0x5c``'``0xbf5c27``gbk``0xbf5c``0x27
__'``addslashes()
这里要意识到的重要一点是,默认情况下,PDO
执行真正的预处理语句。它模拟它们(对于MySQL)。因此,PDO在内部构建查询字符串,并mysql_real_escape_string()
在每个绑定的字符串值上调用(MySQL
C API函数)。
对CAPI的调用的mysql_real_escape_string()
不同之处addslashes()
在于它知道连接字符集。因此,它可以为服务器期望的字符集正确执行转义。但是,到目前为止,客户端认为我们仍在使用latin1
该连接,因为我们从未告诉过它。我们确实告诉我们正在使用的_服务器_gbk
,但是 客户端 仍然认为是latin1
。
因此,调用会mysql_real_escape_string()
插入反斜杠,并且我们'
的“转义”内容中有一个自由悬挂的字符!事实上,如果我们看一下$var
在gbk
字符集,我们会看到:
OR'OR 1 = 1 / *
这正是攻击所需要的。
这只是一个形式,但这是呈现的查询:
SELECT * FROM test WHERE name = '縗' OR 1=1 /*' LIMIT 1
恭喜,您刚刚使用PDO Prepared Statements成功攻击了一个程序…
简单修复
现在,值得注意的是,可以通过禁用模拟的准备好的语句来防止这种情况:
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
这 通常会
导致产生真正准备好的语句(即,将数据发送到与查询分开的数据包中)。但是,要知道,PDO会悄悄地退回到仿真陈述,MySQL不能原生准备:那些可被列在手册中,但要注意选择合适的服务器版本)。
正确的解决方法
这里的问题是我们没有调用C API mysql_set_charset()
代替SET
NAMES。如果这样做的话,如果我们从2006年开始使用MySQL版本,我们会很好的。
如果您使用的是较早的MySQL版本,则存在一个错误,mysql_real_escape_string()
即出于逃避目的,无效的多字节字符(例如我们的有效负载中的字符)被视为单个字节,
即使客户端已被正确告知连接编码 ,因此该攻击也可能仍然成功。该错误是固定在MySQL4.1.20,5.0.22和[5.1.11。
但是最糟糕的是,直到5.3.6 PDO
才公开C API mysql_set_charset()
,因此在以前的版本中,它
防止所有可能的命令遭受这种攻击!现在,它作为DSN参数公开,应 SET NAMES
…
拯救的恩典
正如我们在一开始所说的那样,要使这种攻击起作用,必须使用易受攻击的字符集对数据库连接进行编码。
utf8mb4
是 不容易,但可以支持 所有的 Unicode字符:所以你可以选择使用的是代替,但它只是可利用从MySQL
5.5.3。另一种选择是utf8
,它也_不易受到攻击,_ 并且可以支持整个Unicode Basic MultilingualPlane。
或者,您可以启用NO_BACKSLASH_ESCAPES
SQL模式,该模式(除其他外)会更改的操作mysql_real_escape_string()
。启用该模式,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");
因为服务器的期望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中)
- 不要使用易受攻击的字符集进行连接编码(您只能使用
utf8
/latin1
/ascii
/等)
- 启用
NO_BACKSLASH_ESCAPES
SQL模式
您是100%安全的。
否则, ,也容易受到攻击
附录
我一直在缓慢地开发一个补丁程序,以更改默认值,以不模仿将来的PHP版本。我遇到的问题是,当我这样做时,很多测试都失败了。一个问题是,模拟的Prepare只会在执行时抛出语法错误,而真正的Prepare则会在Prepare上抛出错误。因此,这可能会导致问题(这是测试很乏味的部分原因)。
以上是 PDO准备好的语句是否足以防止SQL注入? 的全部内容, 来源链接: utcz.com/qa/413402.html