4.4 CSRF防禦
二次確認
- 在調用某些功能時進行二次驗證,
- 如:刪除用戶時,產生一個提示對話框,提示“確定刪除用戶嗎?”。
- 轉賬操作時,要求用戶輸入二次密碼，設置驗證碼,在進行敏感操作時輸入驗證碼。
- 當二次驗證後,即使用戶打開了 CSRF POC頁面,也不會直接去執行,而需要用戶再次輸
纔可以完成攻擊。 - 這樣，當用戶突然收到提示後,可能會心存懷疑,就不再會乖乖地中招。
Token 認證原理
Token即標誌、記號的意思,在IT領域也叫作令牌。
CSRF攻擊成功的兩個要素:
- 攻擊者可得知URL的所有參數項,並瞭解其含義;
- 誘導用戶訪問構造好的POC。
驗證碼的驗證思路
- 在服務器端生成驗證字符串並保存在 Session中,
- 然後在客戶端使用圖片顯示這段字符串,
- 當用戶輸入驗證碼之後交給服務器處理,
- 如果驗證碼與 Session中的字符串相匹配,
- 就代表驗證碼正確,可以發起請求,反之亦然。
Token的驗證思路
- 當用戶登錄Web應用程序後
- 首先,服務器端會隨機產生一段字符串分配給此用戶,
- 並且存儲在 Session中,
- 當用戶進入某些頁面時,直接傳遞在用戶界面或者 Cookie中。
- 如果在HTML中,那麼爲了用戶體驗更好,一般都會隱藏起來,如
<input type="hidden" name="token" value="6wku2jsdoi7ewOs"/>
- 當用戶進行提交表單操作時,這段 token代碼也會隨之被提交。
- 當服務器端接收到數據時,就會判斷這段“驗證碼”是否與 Session中存儲的字符串一致,
- 如果一致,則認爲是合法的請求
- 如果不一致,則有可能是CSRF攻擊。如圖所示,表單中就存在一個隱藏的 Token
注意:
有時用戶進行一些操作可能不需要提交表單,
比如刪除用戶操作,僅僅發出一個GET請求即可:
- 這樣fom表單中插入 Token就不合適
- 通常會在 Cookie中存儲 Token
- 因爲無論是GET請求還是POST請求,只要向服務器進行請求,那麼一般都會帶入 Cookie,
- 這樣就解決了GET請求傳入 Token值的問題,
Token防禦CSRF步驟
第一步 每當用戶登錄後會隨機生成一段字符串,並且存儲在 Session中。
第二步 在敏感操作中加入隱藏標籤, value即爲 Session中保存的字符串,如
<form action="addUser.action" method="GET"
賬號:< input type="text" name=" username”/><br/>
密碼:< input type=" password" name=" password”/><br/>
確認密碼:< input type=" password" name=" password2”/><br/>
< input type="hidden" name="token" va1ue="3a8d9fxos8v8"/><br/>
<input type="submit" value=”添加">
</form>
注:如果爲GET請求,考慮使用在 Cookie中存儲 Token。
第三步 提交請求後,服務器端取出 Session中的字符串與提交的 Token對比,
如果一致,則認爲是正常請求,否則可能是CSRF攻擊。
第四步 更新 Token值。
注意：
- 當網站同時存在XSS、CSRF漏洞時, Token防禦機制將會失效,因爲攻擊者可以通過 Java Script獲取 Token值。
oken值。
注意：
-
當網站同時存在XSS、CSRF漏洞時, Token防禦機制將會失效,因爲攻擊者可以通過 Java Script獲取 Token值。
-
所以在防範CSRF時,首先需要確定網站是否存在ⅹSS漏洞,如果網站存在XSS漏洞那麼防範CSRF是沒有任何意義的。
摘抄
常言道，君子以厚德載物。
一個人的人品好壞，
決定了他的人生高度。
人品不好的人，
再成功也只是暫時的；
唯有人品端正、有良心、講誠信、
能堅守自己內心的人，
才能真正成就一番事業。
因爲人生到最後，拼的都是人品。