使用PDO防sql注入的原理分析

前言

本文使用pdo的預(yù)處理方式可以避免sql注入。下面話不多說了，來一起看看詳細(xì)的介紹吧

在php手冊中'PDO--預(yù)處理語句與存儲過程'下的說明：

• 很多更成熟的數(shù)據(jù)庫都支持預(yù)處理語句的概念。什么是預(yù)處理語句？可以把它看作是想要運(yùn)行的 SQL 的一種編譯過的模板，它可以使用變量參數(shù)進(jìn)行定制。預(yù)處理語句可以帶來兩大好處：
• 查詢僅需解析（或預(yù)處理）一次，但可以用相同或不同的參數(shù)執(zhí)行多次。當(dāng)查詢準(zhǔn)備好后，數(shù)據(jù)庫將分析、編譯和優(yōu)化執(zhí)行該查詢的計劃。對于復(fù)雜的查詢，此過程要花費(fèi)較長的時間，如果需要以不同參數(shù)多次重復(fù)相同的查詢，那么該過程將大大降低應(yīng)用程序的速度。通過使用預(yù)處理語句，可以避免重復(fù)分析/編譯/優(yōu)化周 期。簡言之，預(yù)處理語句占用更少的資源，因而運(yùn)行得更快。
• 提供給預(yù)處理語句的參數(shù)不需要用引號括起來，驅(qū)動程序會自動處理。如果應(yīng)用程序只使用預(yù)處理語句，可以確保不會發(fā)生SQL 注入。（然而，如果查詢的其他部分是由未轉(zhuǎn)義的輸入來構(gòu)建的，則仍存在 SQL 注入的風(fēng)險）。
• 預(yù)處理語句如此有用，以至于它們唯一的特性是在驅(qū)動程序不支持的時PDO 將模擬處理。這樣可以確保不管數(shù)據(jù)庫是否具有這樣的功能，都可以確保應(yīng)用程序可以用相同的數(shù)據(jù)訪問模式。  

下邊分別說明一下上述兩點(diǎn)好處：

1.首先說說mysql的存儲過程，mysql5中引入了存儲過程特性，存儲過程創(chuàng)建的時候，數(shù)據(jù)庫已經(jīng)對其進(jìn)行了一次解析和優(yōu)化。其次，存儲過程一旦執(zhí)行，在內(nèi)存中就會保留一份這個存儲過程，這樣下次再執(zhí)行同樣的存儲過程時，可以從內(nèi)存中直接中讀取。mysql存儲過程的使用可以參看：https://www.jb51.net/article/7032.htm

對于PDO，原理和其相同，只是PDO支持EMULATE_PREPARES（模擬預(yù)處理）方式，是在本地由PDO驅(qū)動完成，同時也可以不使用本地的模擬預(yù)處理，交由mysql完成，下邊會對這兩種情況進(jìn)行說明。

2.防止sql注入，我通過tcpdump和wireshark結(jié)合抓包來分析一下。

在虛擬機(jī)上執(zhí)行一段代碼，對遠(yuǎn)端mysql發(fā)起請求：

<?php

$pdo = new PDO("mysql:host=10.121.95.81;dbname=thor_cms;charset=utf8", "root","qihoo@360@qihoo");

$st = $pdo->prepare("select * from share where id =? and uid = ?");

$id = 6;
$uid = 521;

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

$st->execute();
$ret = $st->fetchAll();

print_r($ret);

通過tcpdump抓包生成文件：

tcpdump -ieth0 -A -s 3000 port 3306 -w ./mysql.dump

sz mysql.dump

通過wireshark打開文件：

可以看到整個過程：3次握手--Login Request--Request Query--Request Quit

查看Request Query包可以看到：

咦？這不也是拼接sql語句么？

其實，這與我們平時使用mysql_real_escape_string將字符串進(jìn)行轉(zhuǎn)義，再拼接成SQL語句沒有差別，只是由PDO本地驅(qū)動完成轉(zhuǎn)義的（EMULATE_PREPARES）

這種情況下還是有可能造成SQL 注入的，也就是說在php本地調(diào)用pdo prepare中的mysql_real_escape_string來操作query，使用的是本地單字節(jié)字符集，而我們傳遞多字節(jié)編碼的變量時，有可能還是會造成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));

而正確的轉(zhuǎn)義應(yīng)該是給mysql Server指定字符集，并將變量發(fā)送給MySQL Server完成根據(jù)字符轉(zhuǎn)義。

那么，如何才能禁止PHP本地轉(zhuǎn)義而交由MySQL Server轉(zhuǎn)義呢？

PDO有一項參數(shù)，名為PDO::ATTR_EMULATE_PREPARES ，表示是否使用PHP本地模擬prepare，此項參數(shù)默認(rèn)true,我們改為false后再抓包看看。

先在代碼第一行后添加

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

再次用tcpdump抓包，通過wireshark我們可以看到：

php對sql語句發(fā)送采用了prepare--execute方式

這次的變量轉(zhuǎn)義處理交由mysql server來執(zhí)行。

既然變量和SQL模板是分兩次發(fā)送的，那么就不存在SQL注入的問題了，但明顯會多一次傳輸，這在php5.3.6之后是不需要的。

使用PDO的注意事項

1.  php升級到5.3.6+，生產(chǎn)環(huán)境強(qiáng)烈建議升級到php 5.3.9+ php 5.4+，php 5.3.8存在致命的hash碰撞漏洞。

2. 若使用php 5.3.6+, 請在在PDO的DSN中指定charset屬性。小于5.3.6 : $dbh = new PDO($dsn,$user,$pass,array(PDO::MYSQL_ATTR_INIT_COMMAND => "set names utf8"));

3. 如果使用了PHP 5.3.6及以前版本，設(shè)置PDO::ATTR_EMULATE_PREPARES參數(shù)為false（即由MySQL server進(jìn)行變量處理），php 5.3.6以上版本已經(jīng)處理了這個問題，無論是使用本地模擬prepare還是調(diào)用mysql server的prepare均可。

4. 如果使用了PHP 5.3.6及以前版本, 因Yii框架默認(rèn)并未設(shè)置ATTR_EMULATE_PREPARES的值，請在數(shù)據(jù)庫配置文件中指定emulatePrepare的值為false。 

注：

1.為什么在DSN中指定了charset, 還需要執(zhí)行set names <charset>呢？

其實set names <charset>有兩個作用：

　　告訴mysql server, 客戶端（PHP程序）提交給它的編碼是什么

      告訴mysql server, 客戶端需要的結(jié)果的編碼是什么

也就是說，如果數(shù)據(jù)表使用gbk字符集，而PHP程序使用UTF-8編碼，我們在執(zhí)行查詢前運(yùn)行set names utf8, 告訴mysql server正確編碼即可，無須在程序中編碼轉(zhuǎn)換。這樣我們以utf-8編碼提交查詢到mysql server, 得到的結(jié)果也會是utf-8編碼。省卻了程序中的轉(zhuǎn)換編碼問題，不要有疑問，這樣做不會產(chǎn)生亂碼。

那么在DSN中指定charset的作用是什么? 只是告訴PDO, 本地驅(qū)動轉(zhuǎn)義時使用指定的字符集（并不是設(shè)定mysql server通信字符集），設(shè)置mysql server通信字符集，還得使用set names <charset>指令。

2.PDO::ATTR_EMULATE_PREPARES屬性設(shè)置為false引發(fā)的血案:http://my.oschina.net/u/437615/blog/369481

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，如果有疑問大家可以留言交流，謝謝大家對億速云的支持。