本文**：對於跨站偽造請求（csrf）的理解和總結
csrf攻擊
csrf攻擊是什麼
csrf是跨站請求偽造的縮寫，也被稱為xsrf， 是一種挾制使用者在當前已登入的web應用程式上執行非本意的操作的攻擊方法。
跟跨**指令碼（xss）相比，xss利用的是使用者對指定**的信任，csrf利用的是**對使用者網頁瀏覽器的信任。
因為csrf攻擊利用的是衝著瀏覽器分不清發起請求是不是真正的使用者本人。，也就是說，簡單的身份驗證只能保證請求發自某個使用者的瀏覽器，卻不能保證請求本身是使用者自願發出的。
csrf攻擊基本原理使用者alice登入和訪問某銀行**a，保留cookie。
alice被某些資訊誘導訪問危險**b。
危險**b上有乙個
標籤：
這個標籤的src不指向一張，而是乙個http請求，這個請求向銀行要求將alice的1000元轉給badman，由於alice的瀏覽器上有cookie，這樣瀏覽器發出的這個請求就能得到響應執行。
這樣alice的錢就被偷了。
危險**可以偽造乙個表單並隱藏，並在自己**的onload事件中，觸發這個表單的提交事件，就可以改get攻擊為post攻擊
csrf攻擊的物件與防範思路
我們要防範它，先要知道它的目標，然後設法保護這些目標。
我們要明白，僅僅靠發起csrf攻擊的話，黑客只能借助受害者的cookie騙取伺服器的信任，但是黑客並不能憑藉拿到cookie，也看不到cookie的內容。另外，對於伺服器返回的結果，由於瀏覽器同源策略的限制，黑客也無法進行解析。
這就告訴我們，我們要保護的物件是那些可以直接產生資料改變的服務，而對於讀取資料的服務，則不需要進行csrf的保護。
而保護的關鍵，是在請求中放入黑客所不能偽造的資訊。
防範手段這個方法的確可以防範一些csrf攻擊，但是對於高階攻擊就無能為力了——post請求一樣可以偽造。
所以這個方法不夠安全。只能提高攻擊的門檻。
使用者操作限制——驗證碼機制
方法：新增驗證碼來識別是不是使用者主動去發起這個請求，由於一定強度的驗證碼機器無法識別，因此危險**不能偽造乙個完整的請求。
優點：簡單粗暴，低成本，可靠，能防範99.99%的攻擊者。
缺點：對使用者不友好。
請求**限制——驗證 http referer 字段
方法：在http請求頭中有乙個欄位叫referer，它記錄了請求的**位址。 伺服器需要做的是驗證這個**位址是否合法，如果是來自一些不受信任的**，則拒絕響應。
優點：零成本，簡單易實現。
缺點：由於這個方法嚴重依賴瀏覽器自身，因此安全性全看瀏覽器。
相容性不好：每個瀏覽器對於referer的具體實現可能有差別。
並不一定可靠：在一些古老的垃圾瀏覽器中，referer可以被篡改。
對使用者不友好：referer值會記錄下使用者的訪問**，有些使用者認為這樣會侵犯到他們自己的隱私權。因此有些使用者可能會開啟瀏覽器防止跟蹤功能，不提供referer，從而導致正常使用者請求被拒絕。
額外驗證機制——token的使用
方法：使用token來代替驗證碼驗證。由於黑客並不能拿到和看到cookie裡的內容，所以無法偽造乙個完整的請求。基本思路如下：
伺服器隨機產生token（比如把cookiehash化生成），存在session中，放在cookie中或者以ajax的形式交給前端。
前端發請求的時候，解析cookie中的token，放到請求url裡或者請求頭中。
伺服器驗證token，由於黑客無法得到或者偽造token，所以能防範csrf
更進一步的加強手段（不需要session）：
伺服器隨機產生token，然後以token為金鑰雜湊生成一段密文
把token和密文都隨cookie交給前端
前端發起請求時把密文和token都交給後端
後端對token和密文進行正向雜湊驗證，看token能不能生成同樣的密文
這樣即使黑客拿到了token也無法拿到密文。
優點：安全性：極大地提高了破解成本（當然還是有辦法破解），但是99%的攻擊者看到雜湊的時候就已經望而生畏了。
易用性：非常容易實現。
友好性：對使用者來說十分友好。
缺點：效能擔憂：需要hash計算，增加效能上的成本
cookie臃腫：更加依賴網路的情況
並不絕對安全：一些論壇之類支援使用者自己發表內容，由於系統也會在這個位址後面加上token，這樣黑客可以在自己的**上得到這個token，並馬上就可以發動csrf攻擊。（進一步加強法可以防範，或者驗證鏈結是否是鏈到自己本站的，是就在後面新增token，如果是通向外網則不加）
其他攻擊方式如xss攻擊能拿到cookie和token，當然這不在本文的討論範圍之內。
對於post請求，難以將token附在請求中。（可以通過框架和庫解決）
曲線救國——在http頭中自定義屬性並驗證
優點：這樣解決了上種方法在請求中加入 token 的不便
通過 xmlhttprequest 請求的位址不會被記錄到瀏覽器的位址列，安全性較高
缺點：侷限性非常大：xmlhttprequest請求通常用於ajax，並非所有的請求都適合用這個類來發起，而且通過該類請求得到的頁面不能被瀏覽器所記錄下，造成不便。
對於舊**，要把所有請求都改為xmlhttprequest請求，這樣幾乎是要重寫整個**，這代價無疑是不能接受的。
因為csrf攻擊利用的是衝著瀏覽器分不清發起請求是不是真正的使用者本人，所以防範的關鍵在於在請求中放入黑客所不能偽造的資訊。從而防止黑客偽造乙個完整的請求欺騙伺服器。
跨站請求偽造 CSRF
跨站請求偽造 csrf 顧名思義就是在其他非法 呼叫了正常 的介面，攻擊的方法是在頁面中包含惡意 或者鏈結，攻擊者認為被攻擊的使用者有權訪問另乙個 如果使用者在那個 的會話沒有過期，攻擊者就能執行未經授權的操作。大多數 rails 程式都使用 cookie 儲存會話，可能只把會話 id 儲存在 co...
CSRF跨站請求偽造
前面說到xss跨站指令碼攻擊，現在來個複雜度更高一點的csrf跨站請求偽造 首先說一下rsrf的幾個要點 1.rsrf是通過各種方法 站內發布鏈結，qq郵箱發布鏈結等 讓登入使用者觸發請求，在使用者不覺察的過程中對使用者資料進行篡改，進而實現攻擊 2.通過xss可以獲取到使用者的session id...
CSRF 跨站請求偽造
csrf cross site request forgery 中文是跨站請求偽造。csrf攻擊者在使用者已經登入目標 之後，誘使使用者訪問乙個攻擊頁面，利用目標 對使用者的信任，以使用者身份在攻擊頁面對目標 發起偽造使用者操作的請求，達到攻擊目的。舉個列子 假如a站為受信任的銀行 其中有個銀行轉賬...