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

• 不當的類型處理；
  
• 不安全的數據庫配置；
  
• 不合理的查詢集處理；
  
• 不當的錯誤處理；
  
• 轉義字符處理不合適；
  
• 多個提交處理不當。

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

強制字符格式（類型）

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

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

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

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

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

完整示例代碼：

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

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