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