攻防實戰：注水漏洞的利用和防範

參加IT認證考試前，筆者習慣到網上去搜搜。亂逛之餘，不小心就來到了PROMETRIC的中文站。筆者發現整個站點都是ASP程序，況且剛才還有個考場的登錄界面，要是能發現什麼漏洞就好了。
探測漏洞

隨手找了個頁面(http://www.promet.ric.com.cn/openpage.asp?page_id=0)，在參數0後面加上個單引號。返回的頁面顯示：500伺服器內部錯誤。在IE的「Internet選項→高級」中有一個「顯示友好HTTP錯誤信息」的選項，取消前面的鉤。現在，我們可以看到詳細的錯誤信息：

Microsoft OLE DB Provider for ODBC Drivers 錯誤 '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Line 1: Incorrect syntax near ''./audit.asp，行18

原來PROMETRIC用的是MSSQL，看來存在嚴重的注入漏洞(由於涉嫌攻擊步驟，此處不詳細敘述)。

漏洞原理

SQL注入的漏洞通常是由於程序員對它不了解，設計程序時某個參數過濾不嚴格所致。就拿剛才測試用的鏈接中的page_id這個參數來講，肯定就沒有進行過濾檢查，源程序中的查詢語句如下所示：

Select * From Table Where page_id='0'

當我們提交http://www.prometric.com.cn/openpage.asp?page_id=0 and 1=1時，查詢語句就變成了：

Select * From Table Where page_id='0' and 1=1

當我們提交其他的查詢語句時，程序也會進行執行判斷，如：

http://www.prometric.com.cn/openpage.asp?page_id=0 and user>0

查詢語句變成了：

Select * From Table Where page_id='0' and user>0

user是MSSQL的一個內置函數，指的是當前連接資料庫的用戶名，是一個nvarchar值。當它與整型量0進行大小比較時，MSSQL會試圖將user的值轉換成int類型，於是MSSQL就會報錯：

[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the nvarchar value 'web' to a column of data type int.

錯誤信息的後面顯示的是庫名、表名、數據等。如果對方屏蔽了錯誤信息呢？這時，我們就要利用Unicode、Substr等函數通過條件判斷來進行猜測了。

如何利用

大家可以利用小竹開發的NBSI2 MSSQL(以下簡稱「NBSI2」)工具。不過大家要注意，工具永遠只是工具，只能用來提高效率和準確性，自己一定得了解原理。

通過NBSI2，我們順利地導出了PRO METRIC中文站資料庫中的表名和數據，這裡面包括各個考場的登錄用戶和密碼。

通過跨庫查詢，筆者還發現BALANCE表中的BALANCE欄位存放了考場預付款的餘額信息，只要進行跨庫更新，這個金額完全可以改變。

這時候，筆者突發奇想，既然可以得到考場程序，我們是不是可以私設一個考場……

心動不如行動，馬上開始安裝考試系統。安裝過程非常複雜，需要config.dts文件(網站上沒有)。

正當筆者不知怎麼辦的時候，突然發現了企業郵箱服務，PROMETRIC為每一個考場都開設了新浪企業郵箱。

這些考場會不會為了方便沒有改默認密碼呢？果然很多考場沒有更改默認密碼，筆者很輕鬆地就進入了這些郵箱。經過一番搜索，終於在一個考場的郵箱中找到了PROMETRIC發過來的config.dts文件……

到這裡，本次安全測試算是告一段落了。試想一下，如果私自安裝了考場程序，我們是不是可以隨意修改考生信息？如果更改預付金，是不是還可以免費報名考試？而且利用考場ID和密碼，我們在網站上可以更改任何一個考場的註冊信息，然後通過社會工程手段，克隆出一個虛假的考場是完全有可能的。

後記

不知大家還記不記得上期《電腦報》上有關Oracle注入漏洞的文章。雖然兩者在技術實現手段、危害上都不一樣，但它們有一個共同點――從一個小小的地方撕開缺口，從而造成極大的危害。

在筆者所探測的網站中，有些網站只注意過濾地址欄中提交的非法字元，卻忽視了搜索功能中提交的字元，這樣網站依然會存在注入漏洞。

網路安全是一項非常重要的、整體性很強的工作，每一個地方都需注意，否則造成的損失難以估計。