根據(jù)相關(guān)技術(shù)原理，SQL注入可以分為平臺層注入和代碼層注入。前者由不安全的數(shù)據(jù)庫配置或數(shù)據(jù)庫平臺的漏洞所致；后者主要是由于程序員對輸入未進行細致地過濾，從而執(zhí)行了非法的數(shù)據(jù)查詢。基于此，SQL注入的產(chǎn)生原因通常表現(xiàn)在以下幾方面：

• 不當?shù)念愋吞幚?#xff1b;
  
• 不安全的數(shù)據(jù)庫配置；
  
• 不合理的查詢集處理；
  
• 不當?shù)腻e誤處理；
  
• 轉(zhuǎn)義字符處理不合適；
  
• 多個提交處理不當。

在某些表單中，用戶輸入的內(nèi)容直接用來構(gòu)造動態(tài)sql命令，或者作為存儲過程的輸入?yún)?shù)，這些表單特別容易受到sql注入的攻擊。而許多網(wǎng)站程序在編寫時，沒有對用戶輸入的合法性進行判斷或者程序中本身的變量處理不當，使應(yīng)用程序存在安全隱患。這樣，用戶就可以提交一段數(shù)據(jù)庫查詢的代碼，根據(jù)程序返回的結(jié)果，獲得一些敏感的信息或者控制整個服務(wù)器，于是sql注入就發(fā)生了

強制字符格式（類型）

• 對于整形變量， 運用 intval函數(shù)將數(shù)據(jù)轉(zhuǎn)換成整數(shù)
  
• 浮點型參數(shù):運用 floatval或doubleval函數(shù)分別轉(zhuǎn)換單精度和雙精度浮點型參數(shù)
  
• 字符型參數(shù):運用 addslashes函數(shù)來將單引號“’”轉(zhuǎn)換成“\’”，雙引號“"”轉(zhuǎn)換成“"”，反斜杠“\”轉(zhuǎn)換成“\”，NULL字符加上反斜杠“\”如果是字符型，先判斷magic_quotes_gpc是否為On,當不為On的時候運用 addslashes轉(zhuǎn)義特殊字符
  

使用pdo 使用 prepared statements （ 預(yù)處理語句 ）和參數(shù)化的查詢。這些SQL語句被發(fā)送到數(shù)據(jù)庫服務(wù)器，它的參數(shù)全都會被單獨解析。使用這種方式，攻擊者想注入惡意的SQL是不可能的

• 使用PDO訪問MySQL數(shù)據(jù)庫時，真正的real prepared statements 默認情況下是不使用的。為了解決這個問題，你必須禁用 prepared statements的仿真效果。下面是使用PDO創(chuàng)建鏈接的例子：

  <?php $dbh = new PDO('mysql:dbname=mydb;host=127.0.0.1;charset=utf8', 'root', 'pass'); $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, false); ?>

  這可以確保SQL語句和相應(yīng)的值在傳遞到mysql服務(wù)器之前是不會被PHP解析的（禁止了所有可能的惡意SQL注入攻擊）

完整示例代碼：

如下幾種情況，pdo prepared statements 將不能起到防范的作用

• PDO::ATTR_EMULATE_PREPARES 啟用或禁用預(yù)處理語句的模擬。 有些驅(qū)動不支持或有限度地支持本地預(yù)處理。使用此設(shè)置強制PDO總是模擬預(yù)處理語句（如果為 TRUE ），或試著使用本地預(yù)處理語句（如果為 FALSE）。如果驅(qū)動不能成功預(yù)處理當前查詢，它將總是回到模擬預(yù)處理語句上。
  
• 不能讓占位符 ? 代替一組值，這樣只會獲取到這組數(shù)據(jù)的第一個值，
  select * from table where userid in ( ? );
  如果要用in來查找，可以改用find_in_set()實現(xiàn)：
  $ids = '1,2,3,4,5,6'; select * from table where find_in_set(userid, ?);
  
• 不能讓占位符代替數(shù)據(jù)表名或列名，如：
  select * from table order by ?;
  
• 不能讓占位符 ? 代替任何其他SQL語法，如：
  select extract( ? from addtime) as mytime from table;