我们都知道，只要合理正确使用PDO,可以基本上防止SQL注入的产生，本文主要回答以下两个问题：

为什么要使用PDO而不是mysql_connect？

为何PDO能防注入？

使用PDO防注入的时候应该特别注意什么"codetitle">复制代码 代码如下:
Prepared statements and stored procedures
Many of the more mature databases support the concept of prepared statements. What are they"codetitle">复制代码 代码如下:
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代码：

复制代码 代码如下:
<"mysql:host=192.168.0.1;dbname=test;charset=utf8","root");
$st = $pdo->prepare("select * from info where id =");
$id = 21;
$name = 'zhangsan';
$st->bindParam(1,$id);
$st->bindParam(2,$name);
$st->execute();
$st->fetchAll();
"" src="/UploadFiles/2021-04-02/201502251453312.jpg">

如此只显示与mysql 3306端口的通信数据，避免不必要的干扰。

特别要注意的是wireshak基于wincap驱动，不支持本地环回接口的侦听（即使用php连接本地mysql的方法是无法侦听的），请连接其它机器（桥接网络的虚拟机也可）的MySQL进行测试。

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

其实，这与我们平时使用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, 试试效果，如以下代码：

复制代码 代码如下:
<"mysql:host=192.168.0.1;dbname=test;","root");
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$st = $pdo->prepare("select * from info where id =");
$id = 21;
$name = 'zhangsan';
$st->bindParam(1,$id);
$st->bindParam(2,$name);
$st->execute();
$st->fetchAll();
"" src="/UploadFiles/2021-04-02/201502251453324.jpg">

看到了吗？这就是神奇之处，可见这次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碰撞漏洞。

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

3. 如果使用了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>指令。

我真想不通，一些新的项目，为何不使用PDO而使用传统的mysql_XXX函数库呢？如果正确使用PDO，可以从根本上杜绝SQL注入，我强烈建议各个公司的技术负责人、一线技术研发人员，要对这个问题引起重视，尽可能使用PDO加快项目进度和安全质量。

不要再尝试自己编写SQL注入过滤函数库了（又繁琐而且很容易产生未知的漏洞）。

以上就是本文的全部内容了，希望小伙伴们能够好好读完，十分实用。