隨着網絡安全技術的發展,SQL注入做爲一種很流行的攻擊方式被愈來愈多的人所知曉。不少網站也都對SQL注入作了防禦,許多網站管理員的作法就是添加一個防注入程序。這時咱們用常規的手段去探測網站的SQL注入漏洞時會被防注入程序阻擋,遇到這種狀況咱們該怎麼辦?難道就沒有辦法了嗎?答案是否認的。javascript
咱們知道,通常的防注入程序都是基於「黑名單」的,根據特徵字符串去過濾掉一些危險的字符。通常狀況下,黑名單是不安全的,它存在被繞過的風險。好比有的防注入程序只過濾了經過GET、POST方式提交的數據,對經過Cookie方式提交的數據卻並無過濾,這時咱們該怎麼辦?在本文你將會找到答案。html
Cookie注入原理java
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注入的相關知識,下面咱們來看如何肯定一個網站是否存在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方式提交的數據進行了過濾,具體來看下代碼,如圖1七、圖18和圖19:
圖17
圖18
圖19
經過分析上面的代碼,咱們肯定了Cookie注入產生的緣由。網站程序是經過request("id")方式獲取客戶端提交的數據,而且在防注入程序中沒有對經過request.cookies方式提交的數據進行過濾。
如今咱們找到了問題的根源,那麼如何來修復這一漏洞呢?有兩種解決辦法:1、在獲取客戶端提交的數據時指明數據提交方式,能夠採用Request.QueryString("id")方式來獲取經過GET方式提交的數據。2、修改防注入程序,增長對Request.Cookies("id")數據提交方式的過濾。
這裏咱們採用第一種方法對網站代碼進行修改,其實很簡單,只須要修改一句代碼便可。修改後的代碼是這樣,具體看下圖20:
圖20
將修改後的代碼上傳到網站服務器上,替換掉舊的文件。如今咱們再來看下還可否利用Cookie注入,如圖21。
圖21
由上圖咱們看到如今已經不能經過Cookie進行注入了,漏洞被修復。
來源:瑞星網