PHP手冊里面的SQL注入教程

ptjs 12年前發布 | 885 次閱讀 屌絲 計算機

SQL 注入

很多 web 開發者沒有注意到 SQL 查詢是可以被篡改的，因而把 SQL 查詢當作可信任的命令。殊不知道，SQL 查詢可以繞開訪問控制，從而繞過身份驗證和權限檢查。更有甚者，有可能通過 SQL 查詢去運行主機操作系統級的命令。

直接 SQL 命令注入就是攻擊者常用的一種創建或修改已有 SQL 語句的技術，從而達到取得隱藏數據，或覆蓋關鍵的值，甚至執行數據庫主機操作系統命令的目的。這是通過應用程序取得用戶輸入并與靜態參數組合成 SQL 查詢來實現的。下面將會給出一些真實的例子。

由于在缺乏對輸入的數據進行驗證，并且使用了超級用戶或其它有權創建新用戶的數據庫帳號來連接，攻擊者可以在數據庫中新建一個超級用戶。

Example #1 一段實現數據分頁顯示的代碼……也可以被用作創建一個超級用戶（PostgreSQL系統）。

<?php

$offset = $argv[0]; // 注意，沒有輸入驗證！
$query  = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";
$result = pg_query($conn, $query);

?>

</div>

</div> 一般的用戶會點擊 $offset 已被斌值的“上一頁”、“下一頁”的鏈接。原本代碼只會認為 $offset 是一個數值。然而，如果有人嘗試把以下語句先經過 urlencode() 處理，然后加入URL中的話： 

0;
insert into pg_shadow(usename,usesysid,usesuper,usecatupd,passwd)
    select 'crack', usesysid, 't','t','crack'
    from pg_shadow where usename='postgres';
--

</div>

</div> 那么他就可以創建一個超級用戶了。注意那個 0; 只不過是為了提供一個正確的偏移量以便補充完整原來的查詢，使它不要出錯而已。

Note:

-- 是 SQL 的注釋標記，一般可以使用來它告訴 SQL 解釋器忽略后面的語句。

對顯示搜索結果的頁面下手是一個能得到密碼的可行辦法。攻擊者所要做的只不過是找出哪些提交上去的變量是用于 SQL 語句并且處理不當的。而這類的變量通常都被用于 SELECT 查詢中的條件語句，如 WHERE, ORDER BY, LIMIT 和 OFFSET。如果數據庫支持 UNION 構造的話，攻擊者還可能會把一個完整的 SQL 查詢附加到原來的語句上以便從任意數據表中得到密碼。因此，對密碼字段加密是很重要的。

Example #2 顯示文章……以及一些密碼（任何數據庫系統）

<?php

$query  = "SELECT id, name, inserted, size FROM products
                  WHERE size = '$size'
                  ORDER BY $order LIMIT $limit, $offset;";
$result = odbc_exec($conn, $query);

?>

</div>

</div> 可以在原來的查詢的基礎上添加另一個 SELECT 查詢來獲得密碼： 

'
union select '1', concat(uname||'-'||passwd) as name, '1971-01-01', '0' from usertable;
--

</div>

</div> 假如上述語句（使用 ' 和 --）被加入到 $query 中的任意一個變量的話，那么就麻煩了。

SQL 中的 UPDATE 也會受到攻擊。這種查詢也可能像上面的例子那樣被插入或附加上另一個完整的請求。但是攻擊者更愿意對 SET 子句下手，這樣他們就可以更改數據表中的一些數據。這種情況下必須要知道數據庫的結構才能修改查詢成功進行。可以通過表單上的變量名對字段進行猜測，或者進行暴力破解。對于存放用戶名和密碼的字段，命名的方法并不多。

Example #3 從重設密碼……到獲得更多權限（任何數據庫系統）

<?php
$query = "UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';";
?>

</div>

</div> 但是惡意的用戶會把 ' or uid like'%admin%'; -- 作為變量的值提交給 $uid 來改變 admin 的密碼，或者把 $pwd 的值提交為 "hehehe', admin='yes', trusted=100 "（后面有個空格）去獲得更多的權限。這樣做的話，查詢語句實際上就變成了：

<?php

// $uid == ' or uid like'%admin%'; --
$query = "UPDATE usertable SET pwd='...' WHERE uid='' or uid like '%admin%'; --";

// $pwd == "hehehe', admin='yes', trusted=100 "
$query = "UPDATE usertable SET pwd='hehehe', admin='yes', trusted=100 WHERE
...;";

?>

</div>

</div>

下面這個可怕的例子將會演示如何在某些數據庫上執行系統命令。

Example #4 攻擊數據庫所在主機的操作系統（MSSQL Server）

<?php

$query  = "SELECT * FROM products WHERE id LIKE '%$prod%'";
$result = mssql_query($query);

?>

</div>

</div> 如果攻擊提交 a%' exec master..xp_cmdshell 'net user test testpass /ADD' -- 作為變量 $prod的值，那么 $query 將會變成

<?php

$query  = "SELECT * FROM products
                    WHERE id LIKE '%a%'
                    exec master..xp_cmdshell 'net user test testpass /ADD'--";
$result = mssql_query($query);

?>

</div>

</div> MSSQL 服務器會執行這條 SQL 語句，包括它后面那個用于向系統添加用戶的命令。如果這個程序是以 sa 運行而 MSSQLSERVER 服務又有足夠的權限的話，攻擊者就可以獲得一個系統帳號來訪問主機了。

Note:

雖然以上的例子是針對某一特定的數據庫系統的，但是這并不代表不能對其它數據庫系統實施類似的攻擊。使用不同的方法，各種數據庫都有可能遭殃。

預防措施

也許有人會自我安慰，說攻擊者要知道數據庫結構的信息才能實施上面的攻擊。沒錯，確實如此。但沒人能保證攻擊者一定得不到這些信息，一但他們得 到了，數據庫有泄露的危險。如果你在用開放源代碼的軟件包來訪問數據庫，比如論壇程序，攻擊者就很容得到到相關的代碼。如果這些代碼設計不良的話，風險就 更大了。

這些攻擊總是建立在發掘安全意識不強的代碼上的。所以，永遠不要信任外界輸入的數據，特別是來自于客戶端的，包括選擇框、表單隱藏域和 cookie。就如上面的第一個例子那樣，就算是正常的查詢也有可能造成災難。

  • 永遠不要使用超級用戶或所有者帳號去連接數據庫。要用權限被嚴格限制的帳號。
  • 檢查輸入的數據是否具有所期望的數據格式。PHP 有很多可以用于檢查輸入的函數，從簡單的變量函數和字符類型函數（比如 is_numeric()，ctype_digit()）到復雜的 Perl 兼容正則表達式函數都可以完成這個工作。

  • 如果程序等待輸入一個數字，可以考慮使用 is_numeric() 來檢查，或者直接使用 settype() 來轉換它的類型，也可以用 sprintf() 把它格式化為數字。

    Example #5 一個實現分頁更安全的方法

    <?php

    settype    ($offset, 'integer');
    $query = "SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET $offset;";

    // 請注意格式字符串中的 %d，如果用 %s 就毫無意義了
    $query = sprintf("SELECT id, name FROM products ORDER BY name LIMIT 20 OFFSET %d;",
                         $offset);

    ?> 
     </div>

</div>

  • 使用數據庫特定的敏感字符轉義函數（比如 mysql_escape_string() 和 sql_escape_string()）把用戶提交上來的非數字數據進行轉義。如果數據庫沒有專門的敏感字符轉義功能的話 addslashes() 和 str_replace() 可以代替完成這個工作。看看第一個例子，此例顯示僅在查詢的靜態部分加上引號是不夠的，查詢很容易被攻破。
  • 要不擇手段避免顯示出任何有關數據庫的信心，尤其是數據庫結構。參見錯誤報告和錯誤處理函數。
  • 也可以選擇使用數據庫的存儲過程和預定義指針等特性來抽象數庫訪問，使用戶不能直接訪問數據表和視圖。但這個辦法又有別的影響。

除此之外，在允許的情況下，使用代碼或數據庫系統保存查詢日志也是一個好辦法。顯然，日志并不能防止任何攻擊，但利用它可以跟蹤到哪個程序曾經被嘗試攻擊過。日志本身沒用，要查閱其中包含的信息才行。畢竟，更多的信息總比沒有要好。

</div> </div> </div>

 本文由用戶 ptjs 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！
寫博客

博客分類