就是資安

在上個月的一篇文章中，我們看到 WhiteHat Security 對於避免 SQL Injection 的危害提出了 10 個手法。其中第 7 個手法，使用”參數化的查詢 (在 Java 的程式語言中主要是透過 PreparedStatement 來提供) 並避免使用動態式的查詢”對許多人來說應該算是老生常談了。事實上，程式內未採用參數化查詢大多不是因為技術上的考量，因為除了極少數的情況 (通常與效能有關) 外，參數化查詢都是可以順利運作的。在無法採用參數化查詢的原因中，最常見的情況就是使用了預儲程序 (Stored Procedure)。預儲程序如果小心使用，對於 SQL Injection 其實也有一定的防護能力。但是預儲程序畢竟不像參數化查詢那般嚴謹，所以提供這些功能的程式碼無法事先做太多的防範措施，大多數防護的責任還是落在系統開發者自行開發的程式上。而參數化查詢因為會嚴格限制每個參數的型別，所以提供此一功能的程式就可以做好萬全的準備，讓系統開發者在撰寫自己的程式時不需太過擔心。所以除非被限制必須使用預儲程序來存取資料，否則我們就應該採用參數化查詢來存取資料。

參數化查詢與預儲程序之間的取捨，往往還有許多其他非技術的因素，但是這並不是我這篇文章的重點，所以這個問題就在此打住。當我們確實採用了參數化的查詢後，是否就可以對 SQL Injection 高枕無憂了呢?很可惜的是，答案依舊是否定的。如果我們仔細審視第一段的藍色文字，可以發現後半段是避免使用動態式的查詢。而前、後段文字使用”並”加以連結，所以一旦使用者違反了後半段文字的限制，即使使用參數化查詢依舊會遭受 SQL Injection 的攻擊。因為這點對於部分的系統開發者來說或許並不是那麼熟悉，所以接下來我將以實際的例子 (Java 語法) 來加以說明。我假設我們擁有一個稱為 users 的資料表，內含 name 與 password 兩個欄位，分別表示使用者的姓名與密碼。而在此資料表中有一個使用者的姓名與密碼分別為 ‘cyril wang’ 與 ’1234’。

知名的微網誌 Twitter 在 21 日的 AM 2:54 收到警告，表示該網站存在一個跨網站腳本攻擊 (XSS) 的安全漏洞。但是根據其他網誌的報導，一個來自日本的資安研究員 Masato Kinugawa 表示他早在八月中就告知 Twitter 此一問題的存在，並利用此一漏洞做了一些不具破壞性的展示。Masato Kinugawa 將 Twitter 的頁面裝飾成七彩的顏色，並稱之為 Rainbow tweets。此一漏洞被揭露之後，許多人就開始發揮創意，不但產生各式各樣不同的行為，連觸發動作也由原來必須將滑鼠移到連結上 (onMouseOver) 改成自動啟動。後來甚至有了具備自動感染功能的蠕蟲出現，受害者包含前英國首相 Gordon Brown 的妻子 Sarah Brown。

這次的跨網站腳本攻擊來自於當使用者輸入的內容包含連結時 (如 http://www.twitter.com/) Twitter 會自動將其轉換成 html 的連結標籤 (<a>)，但是解析程式對於 @ 這個特殊字元的處理出現問題而導致。受影響的範圍主要為使用 Twitter 主網站服務的用戶，對於使用 3rd party 程式存取 Twitter 服務的用戶則不受影響。Twitter 則對外宣稱在收到通知之後的數個小時 (AM 7:00) 之內就把漏洞修補好了。

雖然 SQL Injection 提出至今已經經過了許多年，但是 SQL Injection 依舊是目前網站應用程式的主要弱點之一，更是資料外洩的主要管道。根據 WhiteHat Security 的一份 White Paper 的內容指出，可以採用下列 10 個方法來避免 SQL Injection 產生危害：

1. 將資料庫與網站伺服器分別安裝在不同的機器上，並確保機器維持在最新的更新狀態。(Install the database on a different machine than the Web server or application server. Make sure all the latest patches are applied.)
2. 應該將資料庫內所有預設帳號與密碼加以關閉，尤其是管理者的帳號更是不可掉以輕心。(The database should have all the default accounts and passwords disabled, including the super-user account.)
3. 建立一個應用程式專用的帳號，並給予其執行任務所需的最小權限。將所有範例表格以及不需使用的 stored procedure 加以移除。(Create an application user account in your database that has minimum privileges necessary for that application to access the data. Remove all the sample tables. Disable access to any stored procedure that is not required by that application user.)
4. 找出所有需要執行的 SQL 指令，並僅允許這些指令的執行。(Identify the list of SQL statements that will be used by the application and only allow such SQL statements from the application, e.g. Select, Insert, Update, etc.)
5. 在不需要使用 insert 或 update 的情形下使用 view 的方式來存取資料庫，可以應用在搜尋或是登入功能。(Use read-only views for SQL statements that do not require any inserts or updates, e.g. Search functionality or Login functionality.)
6. 檢查輸入 (包含資料類型、長度、格式等) 並去除不必要的內容。(Sanitize the input by validating it in your code.)
7. 使用參數化的查詢並避免使用動態式的查詢。以 Java 為例，應該使用 PreparedStatement 物件而非 Statement 物件。(Use parameterized queries instead of dynamic queries. For example, in Java, use Prepared Statement instead of Statement Object.)
8. 採用合適的錯誤處理與記錄功能以確保資料庫發生錯誤時的訊息或其他技術資訊不會因此而洩漏。(Employ proper error handling and logging within the application so that a database error or any other type of technical information is not revealed to the user.)
9. 選擇不易猜測的資料庫表格/欄位名稱。(Choose names for tables and fields that are not easy to guess.)
10. 盡可能的使用 stored procedures。(Use stored procedures instead of raw SQL wherever possible.)

嚴格來說，第 7 點才是目前專門針對 SQL Injection 最主要也是最有效的控制措施。然而其他控制措施雖然並不是特別針對 SQL Injection 這類威脅，但是卻可以減少當系統發生問題時所產生的危害，因此也有其實施的效益。雖說如此，對於第 9 點與第 10 點我個人倒是有一些不同的看法。