SQL 注入

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

直接 SQL 指令注入就是攻擊者常用的一種建立或修改已有 SQL 語句的技術,從而達到取得隱藏資料,或覆蓋關鍵的值,甚至執行資料庫主電腦動作系統指令的目的。這是通過套用程式取得會員輸入並與靜態參陣列合成 SQL 查詢來實現的。下面將會給出一些真實的例子。

由於在缺乏對輸入的資料進行驗證,並且使用了超級會員或其它有權建立新會員的資料庫帳號來連線,攻擊者可以在資料庫中新增一個超級會員。

例子 27-2. 一段實現資料分頁顯示的代碼……也可以被用作建立一個超級會員(PostgreSQL系統)。

<?php

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

?>
一般的會員會點閱 $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';
--

那麼他就可以建立一個超級會員了。注意那個 0; 只不過是為了提供一個正確的偏移量以便補充完整原來的查詢,使它不要出錯而已。

注: -- 是 SQL 的注解旗標,一般可以使用來它告訴 SQL 直譯器忽略後面的語句。

對顯示搜尋結果的頁面下手是一個能得到密碼的可行辦法。攻擊者所要做的只不過是找出哪些送出上去的變量是用於 SQL 語句並且處理不當的。而這類的變量通常都被用於 SELECT 查詢中的條件語句,如 WHERE, ORDER BY, LIMITOFFSET。若果資料庫支援 UNION 構造的話,攻擊者還可能會把一個完整的 SQL 查詢附加到原來的語句上以便從任意資料表中得到密碼。因此,對密碼欄位加密是很重要的。

例子 27-3. 顯示文章……以及一些密碼(任何資料庫系統)

<?php

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

?>
可以在原來的查詢的基礎上增加另一個 SELECT 查詢來獲得密碼:

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

假如上述語句(使用 '--)被加入到 $query 中的任意一個變量的話,那麼就麻煩了。

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

例子 27-4. 從重設密碼……到獲得更多權限(任何資料庫系統)

<?php
$query 
"UPDATE usertable SET pwd='$pwd' WHERE uid='$uid';";
?>
但是惡意的會員會把 ' 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
...;"
;

?>

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

例子 27-5. 攻擊資料庫所在主電腦的動作系統(MSSQL Server)

<?php

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

?>
若果攻擊送出 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);

?>

MSSQL 伺服器會執行這條 SQL 語句,內含它後面那個用於向系統增加會員的指令。若果這個程式是以 sa 運行而 MSSQLSERVER 服務又有足夠的權限的話,攻擊者就可以獲得一個系統帳號來訪問主電腦了。

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

預防措施

也許有人會自我安慰,說攻擊者要知道資料庫結構的訊息才能實施上面的攻擊。沒錯,確實如此。但沒人能保證攻擊者一定得不到這些訊息,一但他們得到了,資料庫有洩露的危險。若果你在用開放原始碼的軟體包來訪問資料庫,比如論壇程式,攻擊者就很容得到到關聯的代碼。若果這些代碼設計不良的話,風險就更大了。

這些攻擊總是建立在發掘安全意識不強的代碼上的。所以,永遠不要信任外界輸入的資料,特別是來自於用戶端的,內含選取框、表單隱藏功能變數和 cookie。就如上面的第一個例子那樣,就算是標準的查詢也有可能造成災難。

  • 永遠不要使用超級會員或所有者帳號去連線資料庫。要用權限被嚴格限制的帳號。

  • 檢查輸入的資料是否具有所期望的資料格式。PHP 有很多可以用於檢查輸入的函數,從簡單的變量函數字元類型函數(比如 is_numeric()ctype_digit())到複雜的 Perl 相容正則表達式函數都可以完成這個工作。

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

    例子 27-6. 一個實現分頁更安全的方法

    <?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);

    ?>

  • 使用資料庫特定的敏感字元轉義函數(比如 mysql_escape_string()sql_escape_string())把會員送出上來的非數字資料進行轉義。若果資料庫沒有專門的敏感字元轉義功能的話 addslashes()str_replace() 可以代替完成這個工作。看看第一個例子,此例顯示僅在查詢的靜態部分加上引號是不夠的,查詢很容易被攻破。

  • 要不擇手段避免顯示出任何有關資料庫的信心,尤其是資料庫結構。參見錯誤報告錯誤處理函數

  • 也可以選取使用資料庫的存儲過程和預定義指標等特性來抽像數庫訪問,使會員不能直接訪問資料表和檢視。但這個辦法又有別的影響。

除此之外,在容許的情況下,使用代碼或資料庫系統儲存查詢日誌也是一個好辦法。顯然,日誌並不能防止任何攻擊,但利用它可以追蹤到哪個程式曾經被嘗試攻擊過。日誌本身沒用,要查閱其中包括的訊息才行。畢竟,更多的訊息總比沒有要好。