csrf防禦之驗證碼
目前，驗證碼被認為是對抗csrf攻擊最簡單有效的防禦措施。用到驗證碼就是在請求過程中強制使用者與應用進行互動，但是乙個站點、乙個好的產品要考慮到使用者的體驗，顯然如果在所有的操作上都加入驗證碼對使用者來說就很不友好。因此驗證碼只能是一種防禦csrf攻擊的輔助手段，並不能成為主要解決方案。
csrf攻擊之referer check
乙個站點的頁面與頁面之間有一定的邏輯關係，referer check用於檢查請求是否來自合法的「源」，所以多用於防止盜鏈。也就是說檢查referer值就可以知道請求是否是該站點的域，從而判斷是否為csrf攻擊。但是，很多使用者出於隱私保護考慮，限制了referer的傳送，伺服器就無法收到referer。referer check還是無法成為防止csrf攻擊的主要手段，但可以通過它來對csrf攻擊進行監控。
csrf的本質
在探索防禦csrf攻擊道路上，要想找到一條可行的方法，那麼必須先要認清csrf的本質。csrf為什麼能夠攻擊成功呢？？其本質原因是因為攻擊者能夠猜到重要操作的所有引數，攻擊者首先要成功**url上的所有引數與引數值才能構造乙個偽造請求。既然這樣的話，那麼可否試試：把引數加密或者使用隨機數？？這樣攻擊者就無法猜中引數值。同時這也符合「不可**性原則」。
下面我們簡單的來看看乙個例項：在乙個url上簡單的刪除操作請求http://host/path/delete?username=abc&item=123456，這樣的情況容易被攻擊者猜到，如果對引數進行加密:http://host/path/delete?username=md5(salt+abc)&item=123456，這樣攻擊者很難得到salt值也就很難實現攻擊。雖然這樣做可防禦csrf攻擊，同時也存在問題：加密後的url非常難讀，會給資料分析工作帶來很大的困擾，因為資料分析工作常常用到的是明文。因此，我們需要一種更通用的方法來防禦csrf，那就是anti csrf token。
csrf防禦之token
講之前先看上面的例子，我們保持原來的引數不變，新增乙個token值，這個token值是隨機的、不可**的:http://host/path/delete?username=abc&item=123456&token=[random(seed)]。token值為使用者和伺服器所有，這個值可以放在使用者的session中，或者瀏覽器的cookie中。有token值時，使用者提交請求，伺服器只需要驗證表單中的token與使用者session（或cookie）中的token值是否一致即可。由於攻擊者無法再構造出乙個完整的url，那麼csrf攻擊就無法實施。有了token並不是就可以高枕無憂了，例如攻擊者可以通過xss或者一些跨站漏洞竊取token值。因此乙個好的安全防禦體系是相輔相成，缺一不可的。
token使用的一些原則
1，token值要足夠隨機且不可**
2，在使用者有效週期內，token消耗前使用同乙個token，若消耗掉token則應重新生成乙個token值，如果有多個頁面共存的場景，應該考慮生成多個有效的token值
3，token應該注意保密性，不應該出現在url中，防止通過referer方式洩露，因此token值應盡量放在表單中，且把敏感操作get改為post，以表單形式提交。
Web安全之CSRF攻擊的防禦措施
cross site request forgery，中文是 跨站點請求偽造。csrf攻擊者在使用者已經登入目標 之後，誘使使用者訪問乙個攻擊頁面，利用目標 對使用者的信任，以使用者身份在攻擊頁面對目標 發起偽造使用者操作的請求，達到攻擊目的。舉個例子 簡單版 假如有個加關注的get介面，blogu...
web安全 CSRF漏洞
描述 跨站點偽裝請求 csrf 漏洞會在以下情況下發生 1.web 應用程式使用會話 cookie。2.應用程式未驗證請求是否經過使用者同意便處理 http 請求。nonce 是隨訊息一起傳送的加密隨機值，可防止 replay 攻擊。如果該請求未包含證明其 的 nonce，則處理該請求的 將易受到 ...
web安全學習 web安全防禦
影響web安全的主要因素就是使用者輸入的不可控，這篇文章就從乙個巨集觀的角度來分析一下如何去保證乙個應用程式的安全。為了保證web安全，首先就是要分析應用程式中那些方面容易遭受到攻擊，然後根據分析結果在制定具體的安全方案。web應用程式的基本安全問題 所有使用者的輸入都是不可信的 致使應用程式實施大...