前端安全CSRF

安全類：csrf

csrf：跨站請求偽造，英文：cross-site request forgery forgery

攻擊原理：

從上圖可以看出，要完成一次csrf攻擊，受害者必須依次完成兩個步驟：

1.登入受信任**a，並在本地生成cookie。

2.在不退出a的情況下，訪問危險**b。

看到這裡，你也許會說：「如果我不滿足以上兩個條件中的乙個，我就不會受到csrf的攻擊」。是的，確實如此，但你不能保證以下情況不會發生：

1.你不能保證你登入了乙個**後，不再開啟乙個tab頁面並訪問另外的**。

2.你不能保證你關閉瀏覽器了後，你本地的cookie立刻過期，你上次的會話已經結束。（事實上，關閉瀏覽器不能結束乙個會話，但大多數人都會錯誤的認為關閉瀏覽器就等於退出登入/結束會話了…）

3.上圖中所謂的攻擊**，可能是乙個存在其他漏洞的可信任的經常被人訪問的**。

csrf攻擊的本質原因

csrf攻擊是源於web的隱式身份驗證機制！web的身份驗證機制雖然可以保證乙個請求是來自於某個使用者的瀏覽器，但卻無法保證該請求是使用者批准傳送的。csrf攻擊的一般是由服務端解決。

csrf工具的防禦手段

盡量使用post，限制get

get介面太容易被拿來做csrf攻擊，看第乙個示例就知道，只要構造乙個img標籤，而img標籤又是不能過濾的資料。介面最好限制為post使用，get則無效，降低攻擊風險。

當然post並不是萬無一失，攻擊者只要構造乙個form就可以，但需要在第三方頁面做，這樣就增加暴露的可能性。

加驗證碼

驗證碼，強制使用者必須與應用進行互動，才能完成最終請求。在通常情況下，驗證碼能很好遏制csrf攻擊。但是出於使用者體驗考慮，**不能給所有的操作都加上驗證碼。因此驗證碼只能作為一種輔助手段，不能作為主要解決方案。

referer 驗證

referer check在web最常見的應用就是「防止盜鏈」。同理，referer check也可以被用於檢查請求是否來自合法的「源」（referer值是否是指定頁面，或者**的域），如果都不是，那麼就極可能是csrf攻擊。

但是因為伺服器並不是什麼時候都能取到referer，所以也無法作為csrf防禦的主要手段。但是用referer check來監控csrf攻擊的發生，倒是一種可行的方法。

anti csrf token

現在業界對csrf的防禦，一致的做法是使用乙個token（anti csrf token）。

例子：使用者訪問某個表單頁面。

服務端生成乙個token，放在使用者的session中，或者瀏覽器的cookie中。

在頁面表單附帶上token引數。

使用者提交請求後，服務端驗證表單中的token是否與使用者session（或cookies）中的token一致，一致為合法請求，不是則非法請求。

這個token的值必須是隨機的，不可**的。由於token的存在，攻擊者無法再構造乙個帶有合法token的請求實施csrf攻擊。另外使用token時應注意token的保密性，盡量把敏感操作由get改為post，以form或ajax形式提交，避免token洩露。

注意：csrf的token僅僅用於對抗csrf攻擊。當**同時存在xss漏洞時候，那這個方案也是空談。所以xss帶來的問題，應該使用xss的防禦方案予以解決。