什麼是CSRF跨站點請求僞造(Cross Site Request Forgery)
CSRF攻擊原理
1、用戶瀏覽並登錄信任網站A
2、A驗證通過，在用戶處產生A的cookie
3、用戶在沒有登出A網站的情況下，訪問危險網站B
4、這時候B(危險的)要求訪問A(安全的)，發出一個請求
5、這時候，瀏覽器會攜帶(2)的cookie訪問A
6、雖然A不知道這個請求是來自B發出的還是用戶在瀏覽器發出的，但是，由於請求攜帶了cookie，所以A認爲這是一個正常的請求
CSRF防禦策略
方法一、Token 驗證：（用的最多）
（1）服務器發送給客戶端一個token(注意，這個token是不存在cookie中的)；
（2）客戶端提交的表單中帶着這個token。
（3）如果這個 token 不合法，那麼服務器拒絕這個請求。
在Django中，服務器在頁面返回{% csrf_token %}，每次表單提交都必須攜帶
方法二、隱藏令牌：
把 token 隱藏在 http 的 head頭中。
方法二和方法一有點像，本質上沒有太大區別，只是使用方式上有區別。
方法三、Referer 驗證：
Referer 指的是頁面請求來源。意思是，只接受本站的請求，服務器才做響應；如果不是，就攔截。
根據 HTTP 協議，在 HTTP 頭中有一個字段叫 Referer，它記錄了該 HTTP 請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求來自於同一個網站，比如需要訪問 http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory，用戶必須先登陸 bank.example，然後通過點擊頁面上的按鈕來觸發轉賬事件。這時，該轉帳請求的 Referer 值就會是轉賬按鈕所在的頁面的 URL，通常是以 bank.example 域名開頭的地址。而如果黑客要對銀行網站實施 CSRF 攻擊，他只能在他自己的網站構造請求，當用戶通過黑客的網站發送請求到銀行時，該請求的 Referer 是指向黑客自己的網站。因此，要防禦 CSRF 攻擊，銀行網站只需要對於每一個轉賬請求驗證其 Referer 值，如果是以 bank.example 開頭的域名，則說明該請求是來自銀行網站自己的請求，是合法的。如果 Referer 是其他網站的話，則有可能是黑客的 CSRF 攻擊，拒絕該請求。
這種方法的顯而易見的好處就是簡單易行，網站的普通開發人員不需要操心 CSRF 的漏洞，只需要在最後給所有安全敏感的請求統一增加一個攔截器來檢查 Referer 的值就可以。特別是對於當前現有的系統，不需要改變當前系統的任何已有代碼和邏輯，沒有風險，非常便捷。
然而，這種方法並非萬無一失。Referer 的值是由瀏覽器提供的，雖然 HTTP 協議上有明確的要求，但是每個瀏覽器對於 Referer 的具體實現可能有差別，並不能保證瀏覽器自身沒有安全漏洞。使用驗證 Referer 值的方法，就是把安全性都依賴於第三方（即瀏覽器）來保障，從理論上來講，這樣並不安全。事實上，對於某些瀏覽器，比如 IE6 或 FF2，目前已經有一些方法可以篡改 Referer 值。如果 bank.example 網站支持 IE6 瀏覽器，黑客完全可以把用戶瀏覽器的 Referer 值設爲以 bank.example 域名開頭的地址，這樣就可以通過驗證，從而進行 CSRF 攻擊。
即便是使用最新的瀏覽器，黑客無法篡改 Referer 值，這種方法仍然有問題。因爲 Referer 值會記錄下用戶的訪問來源，有些用戶認爲這樣會侵犯到他們自己的隱私權，特別是有些組織擔心 Referer 值會把組織內網中的某些信息泄露到外網中。因此，用戶自己可以設置瀏覽器使其在發送請求時不再提供 Referer。當他們正常訪問銀行網站時，網站會因爲請求沒有 Referer 值而認爲是 CSRF 攻擊，拒絕合法用戶的訪問。