最后羅嗦一句，本人錄入這篇文章用的機器上沒有 ASP 環(huán)境，所以提供的代碼未能進行測試，對這一點本人深表歉意。如果大家發(fā)現(xiàn)了代碼中的任何問題，歡迎拍磚～本人皮厚～
一、攻擊原理
Cookies 欺騙主要利用當前網(wǎng)絡上一些用戶管理系統(tǒng)將用戶登錄信息儲存在 Cookies 中這一不安全的做法進行攻擊，其攻擊方法相對于 SQL 注入漏洞等漏洞來說相對要“困難”一些，但還是很“傻瓜”。
我們知道，一般的基于 Cookies 的用戶系統(tǒng)至少會在 Cookies 中儲存兩個變量：username 和 userlevel，其中 username 為用戶名，而 userlevel 為用戶的等級。當我們的瀏覽器訪問 ASP 頁面時，它會傳出類似
GET /.../file.asp HTTP 1.0
...
Cookies: username=user&userlevel=1
...
的數(shù)據(jù)包，那么，我們只要知道了管理員的 username 和 userlevel 值（假設分別為 admin 和 5），便可以通過傳輸
GET /.../file.asp HTTP 1.0
...
Cookies: username=admin&userlevel=5
...
來獲取管理員權限。很簡單是不是？然而，在這個漏洞被發(fā)現(xiàn)之前，幾乎所有的用戶管理系統(tǒng)都依賴于 Cookies。
二、安全地儲存用戶信息
既然 Cookies 是不安全的，而我們又必須把用戶登錄信息存儲下來，那么應該存儲在什么地方呢？
我們注意到，在 ASP 中，除了 Cookies 外，還有 Session 可以儲存信息。Session 是儲存在服務器上的，不是客戶端隨隨便便就能夠更改的，所以具有極高的安全性。這樣，大家就可以把所有 Cookies 的代碼均換作 Session 了。
三、長時間儲存用戶信息
采用 Session 來保存用戶登錄信息，雖然擺脫了 Cookies 欺騙的問題，但是 Session 不能長期儲存（IIS 默認 Session 在用戶停止響應 20 分鐘后失效），于是產生了這一節(jié)所述的 Cookies + Session 混合存儲法。
這一方法有兩個變種，第一種是在 Cookies 中儲存用戶名和密碼，當用戶訪問一個頁面時，先讀取 Session，如果有內容則以 Session 為準，否則讀取 Cookies，按照 Cookies 中提供的用戶名和密碼進行“不透明”的登錄一次，用以判斷 Cookies 中的內容是否合法，若合法再進而存入 Session 中。實現(xiàn)這一方法的代碼如下：
vbs:
復制代碼代碼如下:
<%
Dim username, password
username = Session("username")
if username = "" then
' Session 中沒有用戶登錄信息
username = Request.Cookies("username")
password = Request.Cookies("password")
' 注意上面的兩句得到的 username 和 password 要進行 SQL 注入漏洞的防范（即過濾掉單引號“'”），這里略去
if username = "" or password = "" then
' 用戶沒有登錄
...
else
' 這里假設已經(jīng)創(chuàng)建了 conn 和 rs 對象
rs.Open "SELECT TOP 1 * FROM [user] WHERE username='" & username & "' AND password='" & password & "'", conn, 1, 3
if rs.eof then
' Cookies 中的信息非法
...
else
' Cookies 中的信息合法，自動登錄
Session("username") = username
...
end if
end if
else
' 用戶信息已經(jīng)存在于 Session 中，直接讀取
...
end if
%>
js:
復制代碼代碼如下:
<%
var username, password;
username = Session("username") + "";
if (username == "" || username == "undefined") {
// Session 中沒有用戶信息
username = Request.Cookies("username") + "";
password = Request.Cookies("password") + "";
// 注意上面的兩句得到的 username 和 password 要進行 SQL 注入漏洞的防范（即過濾掉單引號“'”），這里略去
if (username == "" || username == "undefined" || password == "" || password == "undefined") {
// 用戶沒有登錄
...
}
else {
// 這里假設已經(jīng)創(chuàng)建了 conn 和 rs 對象
rs.Open("SELECT TOP 1 * FROM [user] WHERE username='" + username + "' AND password='" + password + "'", conn, 1, 3);
if (rs.eof) {
// Cookies 中的信息非法
...
}
else {
// Cookies 中的信息合法，自動登錄
Session("username") = username + "";
...
}
}
}
else {
// 用戶信息已經(jīng)存在于 Session 中，直接讀取
...
}
%>
但是這種方法對于用戶來說又不太安全，原因是瀏覽器每次訪問頁面時都會把 Cookies 傳輸過去，而包含密碼的 Cookies 一旦被他人獲取將導致用戶帳號被盜。對于這種情況，又出現(xiàn)了第二種方法，即在用戶信息數(shù)據(jù)庫中增加一個字段“verifycode”，在用戶登錄時，隨機產生一個長整型校驗值存入 verifycode 字段，并且將 username 和這個 verifycode 值而不是 password 存入 Cookies。而在驗證 Cookies 中的用戶信息時，也只驗證 username 和 verifycode。這種方法的好處在于，即使用戶的 Cookies 被黑客獲取，他也只能利用這個“臨時”產生的 verifycode 登錄，而無法獲得用戶的密碼。只要此用戶再一次使用用戶名和密碼登錄，這個 verifycode 值便會改變，黑客便無法通過原來的 verifycode 登入。
這種方法的實現(xiàn)只需要在上述方法一的代碼上稍加改動。首先，在您的登錄程序中，在驗證通過存儲用戶信息的地方需要加上一段：
vbs:
復制代碼代碼如下:
<%
Response.Cookies("verifycode") = int(rnd * 2100000000)
%>
js:
復制代碼代碼如下:
<%
Response.Cookies("verifycode") = Math.floor(Math.random() * 2100000000);
%>
然后，在上面提供的驗證代碼中把對 Cookies("password") 的驗證改為對 Cookies("verifycode") 的驗證即可。
四、結論
通過我們的分析以及處理，Cookies 欺騙漏洞已經(jīng)被完全解決，從此，我們的 ASP 程序變得更加安全了。
