CSRF(Cross-site request forgery跨站請求僞造，也被稱成爲“one click attack”或者session riding，通常縮寫爲CSRF或者XSRF，是一種對網站的惡意利用。
1 CSRF原理介紹
一、CSRF×××原理
CSRF×××原理比較簡單，如圖1所示。其中Web A爲存在CSRF漏洞的網站，Web B爲×××者構建的惡意網站，User C爲Web A網站的合法用戶。
1、瀏覽並登陸網站A
2、驗證成功，生成cookie
5、訪問A，並執行B的惡意代碼user C-------瀏覽器--------------------------------------webA
3、訪問惡意網站B
4、B要求訪問Auser C-------瀏覽器--------------------------------------webB
圖1 CSRF原理- 用戶C打開瀏覽器，訪問受信任網站A，輸入用戶名和密碼請求登錄網站A;
2.在用戶信息通過驗證後，網站A產生Cookie信息並返回給瀏覽器，此時用戶登錄網站A成功，可以正常發送請求到網站A; - 用戶未退出網站A之前，在同一瀏覽器中，打開一個TAB頁訪問網站B;
- 網站B接收到用戶請求後，返回一些×××性代碼，併發出一個請求要求訪問第三方站點A;
- 瀏覽器在接收到這些×××性代碼後，根據網站B的請求，在用戶不知情的情況下攜帶Cookie信息，向網站A發出請求。網站A並不知道該請求其實是由B發起的，所以會根據用戶C的Cookie信息以C的權限處理該請求，導致來自網站B的惡意代碼被執行。
2 CSRF漏洞防禦
CSRF漏洞防禦主要可以從三個層面進行，即服務端的防禦、用戶端的防禦和安全設備的防禦。
2.1 服務端的防禦
2.1.1 驗證HTTP Referer字段
根據HTTP協議，在HTTP頭中有一個字段叫Referer，它記錄了該HTTP請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求必須來自於同一個網站。比如某銀行的轉賬是通過用戶訪問http://bank.test/test?page=10&userID=101&money=10000頁面完成，用戶必須先登錄bank.test，然後通過點擊頁面上的按鈕來觸發轉賬事件。當用戶提交請求時，該轉賬請求的Referer值就會是轉賬按鈕所在頁面的URL(本例中，通常是以bank. test域名開頭的地址)。而如果×××者要對銀行網站實施CSRF×××，他只能在自己的網站構造請求，當用戶通過×××者的網站發送請求到銀行時，該請求的Referer是指向×××者的網站。因此，要防禦CSRF×××，銀行網站只需要對於每一個轉賬請求驗證其Referer值，如果是以bank. test開頭的域名，則說明該請求是來自銀行網站自己的請求，是合法的。如果Referer是其他網站的話，就有可能是CSRF×××，則拒絕該請求。
2.1.2 在請求地址中添加token並驗證
CSRF×××之所以能夠成功，是因爲×××者可以僞造用戶的請求，該請求中所有的用戶驗證信息都存在於Cookie中，因此×××者可以在不知道這些驗證信息的情況下直接利用用戶自己的Cookie來通過安全驗證。由此可知，抵禦CSRF×××的關鍵在於：在請求中放入×××者所不能僞造的信息，並且該信息不存在於Cookie之中。鑑於此，系統開發者可以在HTTP請求中以參數的形式加入一個隨機產生的token，並在服務器端建立一個攔截器來驗證這個token，如果請求中沒有token或者token內容不正確，則認爲可能是CSRF×××而拒絕該請求。
2.1.3 在HTTP頭中自定義屬性並驗證
自定義屬性的方法也是使用token並進行驗證，和前一種方法不同的是，這裏並不是把token以參數的形式置於HTTP請求之中，而是把它放到HTTP頭中自定義的屬性裏。通過XMLHttpRequest這個類，可以一次性給所有該類請求加上csrftoken這個HTTP頭屬性，並把token值放入其中。這樣解決了前一種方法在請求中加入token的不便，同時，通過這個類請求的地址不會被記錄到瀏覽器的地址欄，也不用擔心token會通過Referer泄露到其他網站。
3 其他防禦方法
- CSRF×××是有條件的，當用戶訪問惡意鏈接時，認證的cookie仍然有效，所以當用戶關閉頁面時要及時清除認證cookie，對支持TAB模式(新標籤打開網頁)的瀏覽器尤爲重要。
- 儘量少用或不要用request()類變量，獲取參數指定request.form()還是request. querystring ()，這樣有利於阻止CSRF漏洞×××，此方法只不能完全防禦CSRF×××，只是一定程度上增加了×××的難度。