隨着網絡安全技術的發展，SQL注入作爲一種很流行的攻擊方式被越來越多的人所知曉。很多網站也都對SQL注入做了防護，許多網站管理員的做法就是添加一個防注入程序。這時我們用常規的手段去探測網站的SQL注入漏洞時會被防注入程序阻擋，遇到這種情況我們該怎麼辦？難道就沒有辦法了嗎？答案是否定的。
我們知道，一般的防注入程序都是基於“黑名單”的，根據特徵字符串去過濾掉一些危險的字符。一般情況下，黑名單是不安全的，它存在被繞過的風險。比如有的防注入程序只過濾了通過GET、POST方式提交的數據，對通過Cookie方式提交的數據卻並沒有過濾，這時我們該怎麼辦？在本文你將會找到答案。
Cookie注入原理
Cookie最先是由Netscape（網景）公司提出的，Netscape官方文檔中對Cookie的定義是這樣的：Cookie是在HTTP協議下，服務器或腳本可以維護客戶工作站上信息的一種方式。
Cookie的用途非常廣泛，在網絡中經常可以見到Cookie的身影。它通常被用來辨別用戶身份、進行session跟蹤，最典型的應用就是保存用戶的賬號和密碼用來自動登錄網站和電子商務網站中的“購物車”。
Cookie注入簡單來說就是利用Cookie而發起的注入攻擊。從本質上來講，Cookie注入與傳統的SQL注入並無不同，兩者都是針對數據庫的注入，只是表現形式上略有不同罷了。
要想深入瞭解Cookie注入的成因，必須要瞭解ASP腳本中的request對象。它被用來獲取客戶端提交的數據。先來看下ASP開發文檔中對request對象的描述，如圖1所示：
圖1
Request對象的使用方法一般是這樣的：request.[集合名稱]（參數名稱），比如獲取從表單中提交的數據時可以這樣寫：request.form("參數名稱")，但ASP中規定也可以省略集合名稱，直接用這樣的方式獲取數據：request("參數名稱")，當使用這樣的方式獲取數據時，ASP規定是按QueryString、Form、Cookies、ServerVariables的順序來獲取數據的。這樣，當我們使用request("參數名稱")方式獲取客戶端提交的數據，並且沒有對使用request.cookies("參數名稱")方式提交的數據進行過濾時，Cookie注入就產生了。
Cookie注入典型步驟
上面我們介紹了Cookie注入的相關知識，下面我們來看如何確定一個網站是否存在Cookie注入漏洞。
1.尋找形如“.asp?id=xx”類的帶參數的URL。
2.去掉“id=xx”查看頁面顯示是否正常，如果不正常，說明參數在數據傳遞中是直接起作用的。
3.清空瀏覽器地址欄，輸入“javascript:alert(document.cookie="id="+escape("xx"));”，按Enter鍵後彈出一個對話框，內容是“id=xx”，然後用原來的URL刷新頁面，如果顯示正常，說明應用是用Request("id")這種方式獲取數據的。
4.重複上面的步驟，將常規SQL注入中的判斷語句帶入上面的URL：“javascript:alert(document.cookie="id="+escape("xx and 1=1"));”
“javascript:alert(document.cookie="id="+escape("xx and 1=2"));”。
和常規SQL注入一樣，如果分別返回正常和不正常頁面，則說明該應用存在注入漏洞，並可以進行cookie注入。
5.使用常規注入語句進行注入即可。
Cookie注入攻擊實例
通過上面的介紹，相信讀者對Cookie注入的原理和一般的注入流程都有了一定的瞭解，那麼下面我們就通過一個實際案例來講解一下Cookie注入攻擊。
我們的目標是這個站http://knowsec.3322.org，這是我爲了演示Cookie注入攻擊而搭建的一個網站。先來看一下網站頁面，如圖2所示：
圖2
我們隨便查看一條新聞，如圖3所示：
圖3
通過URL我們瞭解到這是一個ASP的動態頁面，現在我們用常規的手段去探測一下該網站是否存在SQL注入漏洞。關於SQL注入漏洞的介紹和利用可以參考這篇文章（http://www.rising.com.cn/newsletter/news/2012-05-24/11580.html），這裏不再贅述。我們先在參數值後面加一單引號，然後提交，發現提示“請不要在參數中包含非法字符嘗試注入”，並記錄了我們的IP地址。這時可以確定該網站添加了防注入程序，對SQL注入中經常用到的字符做了過濾，如圖4所示：
圖4
接着我們再用經典的and 1=1和and 1=2試下，發現都被過濾掉，具體如下圖5和圖6：
圖5
圖6
看來我們檢測SQL注入漏洞的常規手段不能繞過防注入程序。那我們還有其他辦法嗎？答案是有，我們用下面的方法來試下。
1.我們把上面URL（http://knowsec.3322.org/onews.asp?Id=33）問號後面的參數去掉，然後訪問該頁面，提示數據庫出錯，如圖7所示。
圖7
2.現在我們清空瀏覽器地址欄，輸入“javascript:alert(document.cookie="id="+escape("33"));”，按Enter鍵提交，會彈出一個對話框，如圖8所示。
圖8
3.現在我們再來訪問這個URL（http://knowsec.3322.org/onews.asp），發現可以正常訪問了，如圖9所示。
圖9
4.根據上面返回的結果來分析，該網站是通過類似owen=request("id")的方式來獲取瀏覽器提交的參數值的。
5.依此類推，我們可以把and 1=1和and 1=2帶入上面的語句中去判斷是否有SQL注入漏洞，如圖10和圖11。
圖10
圖11
6.現在我們已經可以確定該網站存在注入漏洞，並且可以通過Cookie進行注入。
由於手工進行Cookie注入比較繁瑣，效率比較低。在理解了Cookie注入的原理以後，我們可以用工具來提高效率。首先我們需要用Cookie注入中轉工具來生成一箇中轉頁面。先來看下這個小工具的界面和使用方法，如圖12。
圖12
我們以URL（http://knowsec.3322.org/onews.asp?id=33）來演示該工具的用法。先切換到COOKIE注入項，在“注入鍵名”處輸入“id=”，在“注入URL地址”和“來源頁”處都輸入“http://knowsec.3322.org/onews.asp”，“正常的Cookie值”處不用修改，將“POST提交值”jmdcw=後面的值修改爲33。如下圖13所示：
圖13
各項都填好後選擇“生成ASP”，之後會在和該工具同一目錄下生成一個ASP中轉頁面。將該頁面上傳到一個ASP空間，這裏我把它放在我一臺支持ASP腳本解析的機器上。現在我們來訪問一下http://192.168.30.128/jmCook.asp?jmdcw=33，如圖14所示。
圖14
OK，可以正常訪問。現在就可以按常規方法構造注入語句去注入了。這裏我把它直接放到阿D注入工具裏去跑，很快就返回了結果，如圖15。
圖15
現在我們成功得到了管理員的賬號和密碼，密碼是加密過的，但很容易破解，加密算法是將密碼每個字符的ASCII碼數值加上對應位數的值，再轉換爲對應字符。賬號root的密碼解密後是654321。由於本篇文章講解的是Cookie注入，所以後面拿WebShell的流程就不再講述了，如果有興趣可以參考其他資料。
Cookie注入防禦總結
上面我們以攻擊者的視角通過一個實際案例講述了Cookie注入攻擊，但我們的目的不是爲了去攻擊別人，而且爲了更好的防禦。俗話說“知己知彼，百戰不殆”，只有理解了攻擊者是如何攻擊的，我們才能更有效地防禦。
現在我們對上面案例中用到的網站程序進行加固，來詳細談下如何化解Cookie注入攻擊，先來看下出現漏洞頁面的代碼，如圖16所示。
圖16
通過上面的代碼我們可以得知，服務器端在獲取到參數id的值後沒有做任何處理，直接帶入SQL語句中執行查詢，這樣就產生了一個SQL注入漏洞。
但由於該程序加了防注入程序，對通過GET、POST方式提交的數據進行了過濾，具體來看下代碼，如圖17、圖18和圖19：
圖17
圖18
圖19
通過分析上面的代碼，我們確定了Cookie注入產生的原因。網站程序是通過request("id")方式獲取客戶端提交的數據，並且在防注入程序中沒有對通過request.cookies方式提交的數據進行過濾。
現在我們找到了問題的根源，那麼如何來修復這一漏洞呢？有兩種解決辦法：一、在獲取客戶端提交的數據時指明數據提交方式，可以採用Request.QueryString("id")方式來獲取通過GET方式提交的數據。二、修改防注入程序，增加對Request.Cookies("id")數據提交方式的過濾。
這裏我們採用第一種方法對網站代碼進行修改，其實很簡單，只需要修改一句代碼即可。修改後的代碼是這樣，具體看下圖20：
圖20
將修改後的代碼上傳到網站服務器上，替換掉舊的文件。現在我們再來看下還能否利用Cookie注入，如圖21。
圖21
由上圖我們看到現在已經不能通過Cookie進行注入了，漏洞被修復。