SQL~~Encoding-Based SQL Injection Exploit
最近公司客戶網站的內容管理系統被惡意入侵，因為客戶是用 Linux + PostgreSQL 系統，而我恰好是公司中較熟悉這兩套系統的，公司就派我去處理。我查了一下，答案就在不遠處，我就在 PostgreSQL 的網站上找到了答案，這是一個新型態的 SQL injection 。
Encoding-Based SQL Injection Exploit
The widely-used practice of escaping ASCII single quote "'" by turning it into "\'" is unsafe when operating in multibyte encodings that allow 0x5c (ASCII code for backslash) as the trailing byte of a multibyte character; this includes at least SJIS, BIG5, GBK, GB18030, and UHC.
It is clear that CVE-2006-2314 is a fairly nasty problem, since a proper fix may require changes in application code rather than just a quick update of a library or server.
Technical Information on Encoding-Based SQL Injection Exploit
這個 SQL injection 的特點，在於利用字元編碼而達到植入隱碼的目的。在字元集中，採用多位元組編碼，且低位元組允許使用單引號 (') 的字元編碼，都屬於高危險群。理論上，其影嚮有限，但不幸的是，多數華文網站所採用的 BIG5/GBK 字元編碼，都屬於高危險群。至於採用 UTF8 字元編碼的網站，則不受影嚮。接下來說明這個 SQL injection 的運作方式。
罪在 Non-encoding-aware client ，不在 PostgreSQL Server
在 SQL 語法中，使用單引號 (') 包括住字串，如果字串內容中包含了單引號，則要用兩個單引號 ( '' ) 表示，此稱為 escaping 。假設在某多位元組字元編碼的字元集中，有一個字元的編碼為 (0xC8') ，而被包含在一字串中，如 0xC8'; select * from users 。若要將此字串用於一個 SELECT 命令中，則正確寫法應為： SELECT '0xC8'; select * from users'。然而，有些 client 端應用程式，並未妥善地識別字元編碼，因此會做多餘的 escaping ，而將上面的 SELECT 敘述寫成 SELECT '0xC8''; select * from users' 。當 PostgreSQL Server 收到此敘述時，由於 PostgreSQL 總是妥善地識別字元編碼，因此會正確地將此訊息斷成兩個 SQL 命令，即 SELECT '0xC8''; 和 select * from users'，這就達成了植入隱碼的目的。很明顯地，這是客戶端應用程式的問題，而不是 PostgreSQL Server 的問題，個人以為，影嚮層面並不限於 PostgreSQL 的使用者。