一.什么是SQL注入式攻擊?

????????所謂SQL注入式攻擊，就是攻擊者把SQL命令插入到Web表單的輸入域或頁面請求的查詢字符串，欺騙服務器執行惡意的SQL命令。在某些表單中，用戶輸入的內容直接用來構造(或者影響)動態SQL命令，或作為存儲過程的輸入參數，這類表單特別容易受到SQL注入式攻擊。

例如一個簡單的登錄表單（這里把密碼寫成明文方便說明）：?
?
當在表單中填寫這樣的語句進行提交登錄時會出現這樣的SQL語句

select * from t_admin where admin_name='xxx' and admin_pwd='xxx'' or '1'

這樣會查詢出所有的用戶信息，所有存在不安全隱患

二.常見的SQL注入式攻擊過程類如：

⑴ 某個php Web應用有一個登錄頁面，這個登錄頁面控制著用戶是否有權訪問應用，它要求用戶輸入一個名稱和密碼

⑵ 登錄頁面中輸入的內容將直接用來構造動態的SQL命令，或者直接用作存儲過程的參數

⑶ 攻擊者在用戶名字和密碼輸入框中輸入"'或'1'='1"之類的內容

⑷ 用戶輸入的內容提交給服務器之后，服務器運行上面的php代碼構造出查詢用戶的SQL命令，但由于攻擊者輸入的內容非常特殊，所以最后得到的SQL命令變成：SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'.

⑸ 服務器執行查詢或存儲過程，將用戶輸入的身份信息和服務器中保存的身份信息進行對比

⑹ 由于SQL命令實際上已被注入式攻擊修改，已經不能真正驗證用戶身份，所以系統會錯誤地授權給攻擊者

如果攻擊者知道應用會將表單中輸入的內容直接用于驗證身份的查詢，他就會嘗試輸入某些特殊的SQL字符串篡改查詢改變其原來的功能，欺騙系統授予訪問權限。

系統環境不同，攻擊者可能造成的損害也不同，這主要由應用訪問數據庫的安全權限決定。如果用戶的帳戶具有管理員或其他比較高級的權限，攻擊者就可能對數據庫的表執行各種他想要做的操作，包括添加、刪除或更新數據，甚至可能直接刪除表。

三.常用的SQL注入方式

1. 使用單引號及or關鍵字

SELECT * FROM Users WHERE Username='$username' AND Password='$password'

?我們針對上面的SQL語句分析，發現如果用下面的測試數據就能夠進行SQL注入了?
?username=1′or′1′=′1password=1’or’1’=’1?
?看看整個SQL查詢語句變成：?

?SELECT * FROM Users WHERE Username='1' OR '1'='1' AND Password='1'OR '1'='1'

?假設參數值是通過GET方法傳遞到服務器的，且域名為www.example.com 那么我們的訪問請求就是：
http://www.example.com/index.php?username=1‘%20or%20’1’%20=%20’1password=1’%20or%20’1’%20=%20’1?
? 對上面的SQL語句作簡單分析后我們就知道由于該語句永遠為真，所以肯定會返回一些數據，在這種情況下實際上并未驗證用戶名和密碼，并且在某些系統中，用戶表的第一行記錄是管理員，那這樣造成的后果則更為嚴重。

2. 使用括號

SELECT * FROM Users WHERE((Username='$username')AND(Password=MD5('$password')))

?在這個例子中，存在兩個問題，一個是括號的用法，還有一個是MD5哈希函數的用法。對于第一個問題，我們很容找出缺少的右括號解決，對于第二個問題，我們可以想辦法使第二個條件失效。我們在查詢語句的最后加上一個注釋符以表示后面的都是注釋，常見的注釋起始符是/*（在Oracle中是–），也就是說，我們用如下的用戶名和密碼：?
?username=1′or′1′=′1′))/?password = foo??那么整條SQL語句就變為：?

? SELECT * FROM Users WHERE(( Username='1'or '1'='1'))/*')AND (Password=MD5('$password')))

??那么看看URL請求就變為：?
?http://www.example.com/index.php?username=1‘%20or%20’1’%20=%20’1’))/*&password=foo?
?#####

3.Union查詢SQL注入測試 ??
??Union查詢SQL注入測試 ? 還有一種測試是利用Union的，利用Union可以連接查詢，從而從其他表中得到信息，假設如下查詢：?

? SELECT Name, Phone, Address FROM Users WHERE Id=$id

?然后我們設置id的值為：?
?$id =1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCarTable ,?那么整體的查詢就變為：?

?SELECT Name, Phone,Address FROM Users WHERE Id=1 UNION ALL SELECT creaditCardNumber,1,1 FROM CreditCarTable

?顯示這就能得到所有信用卡用戶的信息。 ??盲目SQL注入測試 ? 在上面我們提到過盲SQL注入，即bind SQL Injection,它意味著對于某個操作我們得不到任何信息，通常這是由于程序員已經編寫了特定的出錯返回頁面，從而隱藏了數據庫結構的信息。 ??

但利用推理方法，有時候我們能夠恢復特定字段的值。這種方法通常采用一組對服務器的布爾查詢，依據返回的結果來推斷結果的含義。仍然延續上面的www.example.com有一個參數名為id， 那么我們輸入以下url請求：?
??http://www.exampe.com/index.php?id=1’?
?顯然由于語法錯誤，我們會得到一個預先定義好的出錯頁面，假設服務器上的查詢語句為 :
?SELECT field1,field2,field3 FROM Users WHERE Id=’Id′假設我們想要的用戶名字段的值，那么通過一些函數，我們就可以逐字符的讀取用戶名的值。在這里我們使用以下的函數：SUBSTRING(text,start,length),ASCII(char),LENGTH(text)?我們定義id為：引用Id=1’ AND ASCII(SUBSTRING(username,1,1))=97 AND ‘1’=’1?
?那么最終的SQL查詢語句為：?

SELECT field1,field2,field3 FROM Users WHERE Id='1' AND ASCII(SUBSTRING(username,1,1))=97 AND '1'='1'

?那么，如果在數據庫中有用戶名的第一字符的ASCII碼為97的話，那么我們就能得到一個真值u，那么就繼續尋找該用戶名的下一個字符；如果沒有的話，那么我們就增猜測第一個字符的ASCII碼為98的用戶名，這樣反復下去就能判斷出合法的用戶名

四.如何防范?

只要在利用表單輸入的內容構造SQL命令之前，把所有輸入內容過濾一番就可以了。過濾輸入內容可以按多種方式進行:

?(1)對于動態構造SQL查詢的場合，可以使用下面的技術：

? 第一：替換單引號，即把所有單獨出現的單引號改成兩個單引號，防止攻擊者修改SQL命令的含義。再來看前面的例子，“SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”顯然會得到與“SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的結果

??第二：刪除用戶輸入內容中的所有連字符，防止攻擊者構造出類如“SELECT * from Users WHERE login = 'mas' AND password =''”之類的查詢，因為這類查詢的后半部分已經被注釋掉，不再有效，攻擊者只要知道一個合法的用戶登錄名稱，根本不需要知道用戶的密碼就可以順利獲得訪問權限

第三：對于用來執行查詢的數據庫帳戶，限制其權限。用不同的用戶帳戶執行查詢、插入、更新、刪除操作。由于隔離了不同帳戶可執行的操作，因而也就防止了原本用于執行SELECT命令的地方卻被用于執行INSERT、UPDATE或DELETE命令

?(2)用存儲過程來執行所有的查詢。SQL參數的傳遞方式將防止攻擊者利用單引號和連字符實施攻擊。此外，它還使得數據庫權限可以限制到只允許特定的存儲過程執行，所有的用戶輸入必須遵從被調用的存儲過程的安全上下文，這樣就很難再發生注入式攻擊了。

?(3)限制表單或查詢字符串輸入的長度。如果用戶的登錄名字最多只有10個字符，那么不要認可表單中輸入的10個以上的字符，這將大大增加攻擊者在SQL命令中插入有害代碼的難度

?(4)檢查用戶輸入的合法性，確信輸入的內容只包含合法的數據。數據檢查應當在客戶端和服務器端都執行,之所以要執行服務器端驗證，是為了彌補客戶端驗證機制脆弱的安全性??

?在客戶端，攻擊者完全有可能獲得網頁的源代碼，修改驗證合法性的腳本(或者直接刪除腳本)，然后將非法內容通過修改后的表單提交給服務器。因此，要保證驗證操作確實已經執行，唯一的辦法就是在服務器端也執行驗證。你可以使用許多內建的驗證對象，例如RegularExpressionValidator，它們能夠自動生成驗證用的客戶端腳本，當然你也可以插入服務器端的方法調用。如果找不到現成的驗證對象，你可以通過CustomValidator自己創建一個。

?(5) 將用戶登錄名稱、密碼等數據加密保存。加密用戶輸入的數據，然后再將它與數據庫中保存的數據比較，這相當于對用戶輸入的數據進行了“消毒”處理，用戶輸入的數據不再對數據庫有任何特殊的意義，從而也就防止了攻擊者注入SQL命令

(6) 檢查提取數據的查詢所返回的記錄數量。如果程序只要求返回一個記錄，但實際返回的記錄卻超過一行，那就當作出錯處理。

?(7)使用預處理語句

常用SQL注入的解決方案

1.添加圖形碼進行驗證

添加圖形碼在一定程序上增加代碼的安全性，給機器強制破解有一定的攔截作用，但不能阻止所有的攻擊，故還是需要在程序上進行安全性考慮

2.使用預備義語句和參數化查詢

使用預處理語句和參數化查詢。預處理語句和參數分別發送到數據庫服務器進行解析，參數將會被當作普通字符處理。這種方式使得攻擊者無法注入惡意的SQL。常用的方式有兩種

2.1 使用PDO(PHP Data Objects )

$stmt = $pdo->prepare('SELECT * FROM t_admin WHERE admin_name = :name'); $stmt->execute(array('name' => $name)); foreach ($stmt as $row) {// do something with $row }

注意，在默認情況使用PDO并沒有讓MySQL數據庫執行真正的預處理語句（原因見下文）。為了解決這個問題，你應該禁止PDO模擬預處理語句。一個正確使用PDO創建數據庫連接的例子如下

$dbConnection->setAttribute(PDO::ATTR_EMULATE_PREPARES, false); $dbConnection->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

2.2 使用MySQLi

$stmt = $dbConnection->prepare('SELECT * FROM t_admin WHERE admin_name = ?'); $stmt->bind_param('s', $name); $stmt->execute(); $result = $stmt->get_result(); while ($row = $result->fetch_assoc()) {// do something with $row }

3.對用戶傳遞的參數進行處理

我們知道Web上提交數據有兩種方式，一種是get、一種是post，那么很多常見的sql注射就是從get方式入手的，而且注射的語句里面一定是包含一些sql語句的，因為沒有sql語句，那么如何進行，sql語句有四大句：select 、update、delete、insert，那么我們如果在我們提交的數據中進行過濾是不是能夠避免這些問題呢？?
于是我們使用正則就構建如下函數：

<?phpfunction inject_check($sql_str) { return eregi('select|insert|update|delete|');}function verify_id($id=null) { if (!$id) { exit('沒有提交參數！'); } // 是否為空判斷 elseif (inject_check($id)) { exit('提交的參數非法！'); } // 注射判斷 elseif (!is_numeric($id)) { exit('提交的參數非法！'); } // 數字判斷 $id = intval($id); // 整型化 return $id; } ?>

那么我們就能夠進行校驗了，于是我們上面的程序代碼就變成了下面的：

<?php if (inject_check($_GET['id'])) { exit('你提交的數據非法，請檢查后重新提交！'); } else { $id = verify_id($_GET['id']); // 這里引用了我們的過濾函數，對$id進行過濾 echo '提交的數據合法，請繼續！'; } ?>

好，問題到這里似乎都解決了，但是我們有沒有考慮過post提交的數據，大批量的數據呢？?
比如一些字符可能會對數據庫造成危害，比如 ’ _ ‘, ’ %’，這些字符都有特殊意義，那么我們如果進行控制呢？還有一點，就是當我們的php.ini里面的magic_quotes_gpc = off的時候，那么提交的不符合數據庫規則的數據都是不會自動在前面加’ ‘的，那么我們要控制這些問題，于是構建如下函數：

<?php function str_check( $str ) { if (!get_magic_quotes_gpc()) // 判斷magic_quotes_gpc是否打開 { $str = addslashes($str); // 進行過濾 } $str = str_replace("_", "\_", $str); // 把 '_'過濾掉 $str = str_replace("%", "\%", $str); // 把' % '過濾掉 return $str; } ?> 最后，再考慮提交一些大批量數據的情況，比如發貼，或者寫文章、新聞，我們需要一些函數來幫我們過濾和進行轉換，再上面函數的基礎上，對提交的數據進行引號轉義及將HTML標簽轉換成HTML實體，可以構建如下函數： <?php function post_check($post) { if (!get_magic_quotes_gpc()) // 判斷magic_quotes_gpc是否為打開 { $post = addslashes($post); // 進行magic_quotes_gpc沒有打開的情況對提交數據的過濾 } $post = str_replace("_", "\_", $post); // 把 '_'過濾掉 $post = str_replace("%", "\%", $post); // 把' % '過濾掉 $post = nl2br($post); // 回車轉換 $post= htmlspecialchars($post); // html標記轉換 return $post; } ?>或者根據API文檔中的： TP框架防止sql注入：

對于WEB應用來說，SQL注入攻擊無疑是首要防范的安全問題，系統底層對于數據安全方面本身進行了很多的處理和相應的防范機制，例如：

$User?=?M("User");?// 實例化User對象

$User->find($_GET["id"]);

即便用戶輸入了一些惡意的id參數，系統也會強制轉換成整型，避免惡意注入。這是因為，系統會對數據進行強制的數據類型檢測，并且對數據來源進行數據格式轉換。而且，對于字符串類型的數據，ThinkPHP都會進行escape_string處理(real_escape_string,mysql_escape_string)，如果你采用PDO方式的話，還支持參數綁定。

通常的安全隱患在于你的查詢條件使用了字符串參數，然后其中一些變量又依賴由客戶端的用戶輸入。

要有效的防止SQL注入問題，我們建議：

• 查詢條件盡量使用數組方式，這是更為安全的方式；
• 如果不得已必須使用字符串查詢條件，使用預處理機制；
• 使用自動驗證和自動完成機制進行針對應用的自定義過濾；
• 如果環境允許，盡量使用PDO方式，并使用參數綁定。

查詢條件預處理

where方法使用字符串條件的時候，支持預處理（安全過濾），并支持兩種方式傳入預處理參數，例如：

$Model->where("id=%d and username='%s' and xx='%f'",array($id,$username,$xx))->select();

// 或者

$Model->where("id=%d and username='%s' and xx='%f'",$id,$username,$xx)->select();

模型的query和execute方法 同樣支持預處理機制，例如：

$model->query('select * from user where id=%d and status=%d',$id,$status);

//或者

$model->query('select * from user where id=%d and status=%d',array($id,$status));

execute方法用法同query方法。

總結

以上是生活随笔為你收集整理的php防止sql注入的方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。