Cookies欺騙分析與防護

2022-02-19 11:29:34 字數 4002 閱讀 9794

今天來談談cookies欺騙是怎麼回事以及如何避免。

使用者在登入之後通常會儲存使用者資訊,以便在其他需要許可權的頁面去驗證使用者資訊是否具有訪問許可權。

有同學說我在登入的時候已經很注意sql注入問題了,還有什麼不安全的地方麼?

當然有!這個要首先談乙個問題,那就是使用者身份驗證的流程 如下圖:

因此我們可以看出,乙個頁面是否能夠被訪問,判斷依據是通過儲存資訊區域中使用者的資訊來判斷的

而登入頁面的作用就是 驗證 使用者輸入的使用者名稱+密碼的組合是否在資料庫中存在,如果存在則把資訊儲存在儲存資訊的區域,以便各個頁面去判斷許可權

ok,理清這個思路之後我們的重點就來了,那個資訊儲存區域對於我們來說至關重要,一般常見的有兩種形式,session和cookies

session和cookies同樣都是針對單獨使用者的變數(或者說是物件好像更合適點),不同的使用者在訪問**的時候 都會擁有各自的session或者cookies,不同使用者之間互不干擾。

他們的不同點是:

1,儲存位置不同

session在伺服器端產生,比較安全,但是如果session較多則會影響效能

cookies在客戶端產生,安全性稍弱

2,生命週期不同

session生命週期 在指定的時間(如20分鐘)到了之後會結束,不到指定的時間,也會隨著瀏覽器程序的結束而結束。

cookies預設情況下也隨著瀏覽器程序結束而結束,但如果手動指定時間,則不受瀏覽器程序結束的影響。 

由於如果使用者資訊使用session儲存的話,使用者資訊往往會丟失而需要重新登入,使用cookies的話則可以長時間有效比較利於使用者體驗,那session的情況我們不討論,下面說說使用cookies儲存使用者資訊的情況。

我們首先建立兩個頁面分別是login.aspx和main.aspx。login.aspx用於獲取並儲存使用者資訊到cookies中,main.aspx則使用者驗證使用者是否有權訪問本頁面,我們在本例中設定,登入使用者有權訪問,匿名(未登入)使用者,拒絕訪問。

首先來看login.aspx 我們先建立兩個按鈕

「獲取登入狀態」按鈕會 把資訊儲存到cookies中,這裡僅儲存uid,然後重定向到main.aspx

「未獲取登入狀態」按鈕 直接重定向到main.aspx 進行匿名訪問

login.aspx.cs 程式**:

1

protected

void page_load(object

sender, eventargs e)26

protected

void button1_click(object

sender, eventargs e)721

protected

void button2_click(object

sender, eventargs e)

22

在main.aspx中進行驗證使用者是否已經登入

1

protected

void page_load(object

sender, eventargs e)25

67private

void

checklogin()813

else

1417}18

1920

///21

///模擬乙個獲取使用者資訊的方法

22///

然而實際操作中需要通過id查詢資料庫來獲取使用者資訊

23///

這裡為了方便演示就直接return固定的值了

24///

25///

26///

27///

28private

string getuserinfo(int uid, string

key)

2938}39

else

4043 }

ok,我們來測試一下,點選獲取登入狀態,實際上相當於用admin,123456這個組合來登入。

好的,登入成功,我們再來測試下匿名登入,點選未獲取登入狀態

事情好像比我們想象的要順利,目前來說我們想要的效果已經都實現了,但是事實上真的是這樣嗎,顯然不是!

我們剛才說過,cookies是在客戶端產生,也就是我們自己的電腦上儲存的

另一方面,main.aspx這個頁面判斷 你是否能夠訪問的依據就是 cookies中的值是多少,如果是1,則認為你當前身份是uid為1的使用者,如果是5,則認為你當前身份是uid為5的使用者。

那麼我們考慮乙個事情,如果把我的cookies中的uid修改掉,比如改成35,是不是可以直接繞過登入頁面,就可以以uid為35的使用者身份登入呢?

事實上確實是這樣,這也就是標題中所說的cookies欺騙。由於cookies是客戶端產生我們可以很容易的修改,因此產生安全隱患。

在address中輸入我們專案的訪問位址,然後連線

然後正常操作一遍,分別點選 獲取登入狀態  和  未獲取登入狀態

發現我們正常操作是正常的判斷,下面重點來了,我們要修改cookies值 點選未獲取登入狀態 一樣可以被授權訪問

登入成功了,那麼我們應該如何避免這樣的問題呢?

正確的做法是,把密碼同時存入cookies(當然實際操作時候需要md5加密儲存,這裡為了方面演示使用明文儲存),然後在main.aspx驗證時候,同時驗證uid和密碼是否匹配即可。

我們來修改一下**:

login頁面

1

protected

void page_load(object

sender, eventargs e)27

protected

void button1_click(object

sender, eventargs e)822

protected

void button2_click(object

sender, eventargs e)

23

main頁面

1

private

void

checklogin()29

else

1013}14

else

1518 }

這樣改動之後,使用者如果再以修改cookies企圖繞過驗證的話,那麼他除了修改uid之外,還必須修改pwd為正確的密碼。

有同學問:那如果他就是把pwd改成正確的密碼了呢?

這位同學...你的密碼都別別人竊取了...那麼再安全的程式**也救不了你....

感謝小夥伴們的熱烈討論,按照 @老牛吃肉 和其他同類觀點的使用者的建議,我嘗試做了另一方案,做下補充。

使用des把uid加密放在cookies中,在驗證階段解密驗證。

ARP欺騙分析

arp資料報分為2大類 1 請求 request a 請求單播 b 請求廣播 2 應答 reply a 應答單播 b 應答廣播 下表為乙太網arp資料報 字段長度 位元組byte 值正常請求單播 正常請求廣播 免費請求 免費arp包都是廣播包 dest mac6 cd cd cd cd cd cd ...

ARP協議分析與攻擊防護(二)

uthor 朋小鋒 手工繫結 雙向繫結 從上節課我們得知,當windows客戶機想要通訊時,需要向閘道器傳送arp廣播請求報文,閘道器收到arp請求後會向客戶機傳送arp單播應答報文,當客戶機收到應答後會在arp快取表中新增一條閘道器的動態arp快取。動態arp快取優先順序 同一ip位址的後者mac...

JS安全防護演算法與逆向分析 JS Hook

js hook原理非常簡單,現在將乙個最簡單的例子,比如有這樣乙個函式 function test a,b 我們可以直接在console裡邊修改這個函式,比如如下這樣 var test test test function a,b 有的 會在hook這裡做個檢測,比如讀者可以在console裡邊輸出...