[转美学原理]PDO防注入原理分析以及选取PDO的注意事项

 

大家都晓得,只要合理正确选拔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::ATTRubicon_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::ATT陆风X8_EMULATE_PREPARES参数为false(即由MySQL进行变量处理),php
    5.3.6之上版本现已处理了这些标题,无论是使用当地模拟prepare依然调用mysql
    server的prepare均可。在DSN中钦点charset是低效的,同时set names
    <charset>的执行是不可或缺的。

 

4. 若是利用了PHP 5.3.6及以前版本,
因Yii框架默许并未设置ATTCRUISER_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注入过滤函数库了(又麻烦而且很简单生出未知的尾巴)。

好小说不得不转。

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