[转]PDO防注入原理分析以及使用PDO的注意事项

原文:http://zhangxugg-163-com.iteye.com/blog/1835721

好随笔不得不转。

大家都知情,只要合理正确运用PDO,可以基本上制止SQL注入的发出,本文紧要回应以下多少个问题:

缘何要拔取PDO而不是mysql_connect?

为何PDO能防注入?

采纳PDO防注入的时候应该特别注意什么?

 

一、为什么要事先利用PDO?

PHP手册上说得很明亮:

Prepared statements and stored procedures
Many of the more mature databases support the concept of prepared
statements. What are they? They can be thought of as a kind of
compiled template for the SQL that an application wants to run, that
can be customized using variable parameters. Prepared statements offer
two major benefits: 

The query only needs to be parsed (or prepared) once, but can be
executed multiple times with the same or different parameters. When
the query is prepared, the database will analyze, compile and optimize
its plan for executing the query. For complex queries this process can
take up enough time that it will noticeably slow down an application
if there is a need to repeat the same query many times with different
parameters. By using a prepared statement the application avoids
repeating the analyze/compile/optimize cycle. This means that prepared
statements use fewer resources and thus run faster.

 

The parameters to prepared statements don’t need to be quoted; the
driver automatically handles this. 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).

 

即拔取PDO的prepare格局,紧假诺提高相同SQL模板查询性能、阻止SQL注入

与此同时,PHP手册中提交了警戒音讯

Prior to PHP 5.3.6, this element was silently ignored. The same behaviour can be partly replicated with the PDO::MYSQL_ATTR_INIT_COMMAND driver option, as the following example shows.
Warning

The method in the below example can only be used with character sets that share the same lower 7 bit representation as ASCII, such as ISO-8859-1 and UTF-8. Users using character sets that have different representations (such as UTF-16 or Big5) must use the charset option provided in PHP 5.3.6 and later versions.

 

情趣是说,在PHP
5.3.6及以前版本中,并不协助在DSN中的charset定义,而相应使用PDO::MYSQL_ATTR_INIT_COMMAND设置初始SQL, 即我们常用的 set names gbk指令。

 

自己看出一些主次,还在尝试接纳addslashes达到防注入的目的,殊不知这样实在问题更多,
详情请看http://www.lorui.com/addslashes-mysql\_escape\_string-mysql\_real\_eascape\_string.html

还有部分做法:在实践数据库查询前,将SQL中的select, union,
….之类的第一词清理掉。这种做法分明是那多少个荒唐的处理模式,假使提交的正文中真的含有
the students’s union , 替换后将篡改本来的内容,滥杀无辜,不可取。

 

二、为何PDO能防SQL注入?
请先看之下PHP代码:

<?php

$pdo = new PDO(“mysql:host=192.168.0.1;dbname=test;charset=utf8″,”root”);

$st = $pdo->prepare(“select * from info where id =? and name = ?”);

 

$id = 21;

$name = ‘zhangsan’;

$st->bindParam(1,$id);

$st->bindParam(2,$name);

 

$st->execute();

$st->fetchAll();

?>

 

环境如下:

PHP 5.4.7

Mysql 协议版本 10

MySQL Server 5.5.27

 

为了彻底搞明白php与mysql server通讯的底细,我专门利用了wireshark抓包举行探讨之,安装wireshak之后,我们设置过滤条件为tcp.port==3306, 如下图:
图片 1
 

 

 

 

如此这般只呈现与mysql 3306端口的通信数据,避免不必要的搅和。

专门要留意的是wireshak基于wincap驱动,不襄助本地环回接口的侦听(即采用php连接本地mysql的法子是心有余而力不足侦听的),请连接其他机器(桥接网络的虚拟机也可)的MySQL进行测试。

 

然后运行我们的PHP程序,侦听结果如下,大家发现,PHP只是简单地将SQL间接发送给MySQL Server :

 

图片 2

 

 

 

其实,这与大家平日应用mysql_real_escape_string将字符串举办转义,再拼接成SQL语句没有差距(只是由PDO本地驱动完成转义的),分明这种场所下依然有可能导致SQL注入的,也就是说在php本地调用pdo prepare中的mysql_real_escape_string来操作query,使用的是当地单字节字符集,而我辈传递多字节编码的变量时,有可能如故会招致SQL注入漏洞(php 5.3.6原先版本的问题之一,这也就表达了为啥在动用PDO时,指出升级到php 5.3.6+,并在DSN字符串中指定charset的原委。

 

针对php 5.3.6从前版本,以下代码依然可能引致SQL注入问题:

$pdo->query(‘SET NAMES GBK’); 

$var = chr(0xbf) . chr(0x27) . ” OR 1=1 /*”; 

$query = “SELECT * FROM info WHERE name = ?”; 

$stmt = $pdo->prepare($query); 

$stmt->execute(array($var)); 

 

缘由与地点的辨析是如出一辙的。

 

而不利的转义应该是给mysql Server指定字符集,并将变量发送给MySQL Server完成遵照字符转义。

 

那么,怎样才能禁止PHP本地转义而交由MySQL Server转义呢?

PDO有一项参数,名为PDO::ATTR_EMULATE_PREPARES ,表示是否利用PHP本地模拟prepare,此项参数默认值未知。而且按照大家正好抓包分析结果来看,php 5.3.6+默认仍旧使用当地变量转,拼接成SQL发送给MySQL Server的,我们将那项值设置为false, 试试效果,如以下代码:

<?php

$pdo = new PDO(“mysql:host=192.168.0.1;dbname=test;”,”root”);

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

 

$st = $pdo->prepare(“select * from info where id =? and name = ?”);

$id = 21;

$name = ‘zhangsan’;

 

$st->bindParam(1,$id);

$st->bindParam(2,$name);

$st->execute();

$st->fetchAll();

?>

 

革命行是我们刚进入的始末,运行以下顺序,使用wireshark抓包分析,得出的结果如下:
图片 3
 

图片 4
 

 

探望了吧?这就是神奇之处,可见这一次PHP是将SQL模板和变量是分五次发送给MySQL的,由MySQL完成变量的转义处理,既然变量和SQL模板是分一次发送的,那么就不设有SQL注入的问题了,但需要在DSN中指定charset属性,如:

$pdo = new PDO(‘mysql:host=localhost;dbname=test;charset=utf8’, ‘root’);

 

那般,即可从根本上杜绝SQL注入的题材。假若你对此不是很领悟,可以发邮件至zhangxugg@163.com, 一起商量。

 

三、使用PDO的注意事项

略知一二以上几点过后,大家就可以总结运用PDO杜绝SQL注入的多少个注意事项:

1.  php升级到5.3.6+,生产条件强烈指出升级到php 5.3.9+ php
5.4+,php 5.3.8留存致命的hash碰撞漏洞。

 

  1. 若使用php 5.3.6+, 请在在PDO的DSN中指定charset属性

  2. 只要应用了PHP
    5.3.6及从前版本,设置PDO::ATTR_EMULATE_PREPARES参数为false(即由MySQL举办变量处理),php
    5.3.6以上版本已经处理了这多少个题目,无论是使用当地模拟prepare如故调用mysql
    server的prepare均可。在DSN中指定charset是无济于事的,同时set names
    <charset>的推行是不可或缺的。

 

4. 一旦使用了PHP 5.3.6及此前版本,
因Yii框架默认并未设置ATTR_EMULATE_PREPARES的值,请在数据库配置文件中指定emulatePrepare的值为false。

 

那么,有个问题,假设在DSN中指定了charset, 是否还索要履行set names
<charset>呢?

是的,不可以省。set names <charset>其实有多少个效能:

A.  告诉mysql server, 客户端(PHP程序)提交给它的编码是如何

B.  告诉mysql server, 客户端需要的结果的编码是何许

也就是说,借使数据表使用gbk字符集,而PHP程序行使UTF-8编码,大家在执行查询前运行set
names utf8, 告诉mysql
server正确编码即可,无须在程序中编码转换。那样大家以utf-8编码提交查询到mysql
server,
拿到的结果也会是utf-8编码。省却了程序中的转换编码问题,不要有疑点,这样做不会爆发乱码。

 

这就是说在DSN中指定charset的效益是怎么样? 只是告诉PDO,
本地驱动转义时使用指定的字符集(并不是设定mysql
server通信字符集),设置mysql server通信字符集,还得利用set names
<charset>指令。

 

万一图片丢失,可以发邮件至zhangxugg@163.com, 索取PDF版本。

 

我真想不通,一些新的档次,为啥不利用PDO而使用传统的mysql_XXX函数库呢?假设不易利用PDO,可以从根本上杜绝SQL注入,我强烈提议各样集团的技能官员、一线技术研发人员,要对这些问题引起注重,尽可能采取PDO加快项目进度和平安质地。

 

不用再品尝自己编辑SQL注入过滤函数库了(又麻烦而且很容易暴发未知的漏洞)。

 

相关文章