php資料庫安全性－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);
?>

一般的使用者會點選 $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; 只不過是為了提供一個正確的偏移量以便補充完整原來的查詢，使它不要出錯而已。

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 = &#39;$size&#39;
        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 子句下手，這樣他們就可以更改資料表中的一些資料。這種情況必須要知道資料庫的結構才能修改查詢成功進行。可以透過表單上的變數名稱對欄位進行猜測，或是進行暴力破解。對於存放使用者名稱和密碼的字段，命名的方法並不多。

Example #3 從重置密碼…到獲得更多權限（任何資料庫系統）

<?php
    $query = "UPDATE usertable SET pwd=&#39;$pwd&#39; WHERE uid=&#39;$uid&#39;;";
?>

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

<?php
    // $uid == &#39; or uid like&#39;%admin%&#39;; --
    $query = "UPDATE usertable SET pwd=&#39;...&#39; WHERE uid=&#39;&#39; or uid like &#39;%admin%&#39;; --";
    // $pwd == "hehehe&#39;, admin=&#39;yes&#39;, trusted=100 "
    $query = "UPDATE usertable SET pwd=&#39;hehehe&#39;, admin=&#39;yes&#39;, trusted=100 WHERE
        ...;";
?>

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

Example #4 攻擊資料庫所在主機的作業系統（MSSQL Server）

<?php
    $query  = "SELECT * FROM products WHERE id LIKE &#39;%$prod%&#39;";
    $result = mssql_query($query);
?>

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

<?php
    $query = "SELECT * FROM products WHERE id LIKE &#39;%a%&#39;
        exec master..xp_cmdshell &#39;net user test testpass /ADD&#39;--";
    $result = mssql_query($query);
?>

MSSQL 伺服器會執行這條SQL 語句，包括它後面那個用來新增使用者給系統的指令。如果這個程式是以 sa 運作而 MSSQLSERVER 服務又有足夠的權限的話，攻擊者就可以獲得一個系統帳號來存取主機了。

Note:

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

預防措施

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

这些攻击总是建立在发掘安全意识不强的代码上的。所以，永远不要信任外界输入的数据，特别是来自于客户端的，包括选择框、表单隐藏域和 cookie。就如上面的第一个例子那样，就算是正常的查询也有可能造成灾难。

永远不要使用超级用户或所有者帐号去连接数据库。要用权限被严格限制的帐号。

检查输入的数据是否具有所期望的数据格式。PHP 有很多可以用于检查输入的函数，从简单的变量函数和字符类型函数（比如 is_numeric()， ctype_digit()）到复杂的Perl 兼容正则表达式函数都可以完成这个工作。

如果程序等待输入一个数字，可以考虑使用 is_numeric() 来检查，或者直接使用 settype() 来转换它的类型，也可以用 sprintf() 把它格式化为数字。

Example #5 一个实现分页更安全的方法

<?php
    settype($offset, &#39;integer&#39;);
    $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() 可以代替完成这个工作。看看第一个例子，此例显示仅在查询的静态部分加上引号是不够的，查询很容易被攻破。

要不择手段避免显示出任何有关数据库的信心，尤其是数据库结构。

也可以选择使用数据库的存储过程和预定义指针等特性来抽象数库访问，使用户不能直接访问数据表和视图。但这个办法又有别的影响。

除此之外，在允许的情况下，使用代码或数据库系统保存查询日志也是一个好办法。显然，日志并不能防止任何攻击，但利用它可以跟踪到哪个程序曾经被尝试攻击过。日志本身没用，要查阅其中包含的信息才行。毕竟，更多的信息总比没有要好。