描述:
跨站點偽裝請求 (csrf) 漏洞會在以下情況下發生:
1. web 應用程式使用會話 cookie。
2. 應用程式未驗證請求是否經過使用者同意便處理 http 請求。
nonce 是隨訊息一起傳送的加密隨機值,可防止 replay 攻擊。如果該請求未包含證明其**的 nonce,則處理該請求的**將易受到 csrf 攻擊(除非它並未更改應用程式的狀態)。這意味著使用會話 cookie 的 web 應用程式必須採取特殊的預防措施,確保攻擊者無法誘騙使用者提交偽請求。假設有乙個 web 應用程式,它允許管理員通過提交此表單來建立新帳戶:
攻擊者可能會使用以下內容來建立乙個**:
如果 example.com **的管理員在**上具有活動會話時訪問了此惡意頁面,則她會在毫不知情的情況下為攻擊者建立乙個帳戶。這就是 csrf 攻擊。正是由於該應用程式無法確定請求的**,才有可能受到 csrf 攻擊。任何請求都有可能是使用者選定的合法操作,也有可能是攻擊者設定的偽操作。攻擊者無法檢視偽請求生成的網頁,因此,這種攻擊技術僅適用於篡改應用程式狀態的請求。
大多數 web 瀏覽器會隨每次請求傳送乙個名為 referer 的 http 標頭檔案。referer 標頭檔案應該包含參考頁面的 url,但攻擊者可以偽造,因此無法利用 referer 標頭檔案確定請求的**。
如果應用程式通過 url 傳遞會話識別符號(而不是 cookie),則不會出現 csrf 問題,因為攻擊者無法訪問會話識別符號,也無法在偽請求中包含會話識別符號。
解決方案
requestbuilder rb = new requestbuilder(requestbuilder.post, "/new_user");
body = addtopost(body, new_username);
body = addtopost(body, new_passwd);
body = addtopost(body, request_id);
rb.sendrequest(body, new newaccountcallback(callback));
這樣,後端邏輯可先驗證請求識別符號,然後再處理其他表單資料。如果可能,每個伺服器請求的請求識別符號都應該是唯一的,而不是在特定會話的各個請求之間共享。對於會話識別符號而言,攻擊者越難猜出請求識別符號,則越難成功進行 csrf 攻擊。標記不應能夠輕鬆猜出,它應以保護會話標記相同的方法得到保護,例如使用 sslv3。
其他緩解技術還包括:
框架保護:大多數現代化的 web 應用框架都嵌入了 csrf 保護,它們將自動包含並驗證 csrf 標記。
使用質詢-響應控制:強制客戶響應由伺服器傳送的質詢是應對 csrf 的強有力防禦方法。可以用於此目的的一些質詢如下:captcha、密碼重新身份認證和一次性標記。
再次提交會話 cookie:除了實際的會話 id cookie 外,將會話 id cookie 作為隱藏表單值傳送是預防 csrf 攻擊的有效防護方法。伺服器在處理其餘表單資料之前,會先檢查這些值,以確保它們完全相同。如果攻擊者代表使用者提交表單,他將無法根據同源策略修改會話 id cookie 值。
限制會話的有效期:當通過 csrf 攻擊訪問受保護的資源時,只有當作為攻擊一部分傳送的會話 id 在伺服器上仍然有效時,攻擊才會生效。限制會話的有效期將降低攻擊成功的可能性。
這裡所描述的技術可以使用 xss 攻擊破解。有效的 csrf 緩解包括 xss 緩解技術。
WEB漏洞 CSRF及SSRF漏洞
cross site request forgery 簡稱為 csrf 在csrf的攻擊場景中攻擊者會偽造乙個請求 這個請求一般是乙個鏈結 然後欺騙目標使用者進行點選,使用者一旦點選了這個請求,整個攻擊就完成了。所以csrf攻擊也成為 one click 攻擊。很多人搞不清楚csrf的概念,甚至有時...
web安全 CSRF(防禦篇)
csrf防禦之驗證碼 目前,驗證碼被認為是對抗csrf攻擊最簡單有效的防禦措施。用到驗證碼就是在請求過程中強制使用者與應用進行互動,但是乙個站點 乙個好的產品要考慮到使用者的體驗,顯然如果在所有的操作上都加入驗證碼對使用者來說就很不友好。因此驗證碼只能是一種防禦csrf攻擊的輔助手段,並不能成為主要...
Web安全之CSRF攻擊
csrf是什麼?csrf cross site request forgery 中文是跨站點請求偽造。csrf攻擊者在使用者已經登入目標 之後,誘使使用者訪問乙個攻擊頁面,利用目標 對使用者的信任,以使用者身份在攻擊頁面對目標 發起偽造使用者操作的請求,達到攻擊目的。舉個例子 簡單版 假如有個加關注...