簡析django原始碼中對csrf的處理

跨站點請求偽造(cross—site request forgery)，具體過程如下：

這利用了web中使用者身份驗證的乙個漏洞：簡單的身份驗證只能保證請求發自某個使用者的瀏覽器，卻不能保證請求本身是使用者自願發出的。

檢驗http headers中的referer，它的內容就是這次http請求的**位址。對於服務端來說，在請求頭部資訊裡我們可以過濾出有害請求位址的黑名單。

新增隨機引數token，來每一次請求到來後，對比token值來驗證是否是來自本伺服器的信任。

在我們在post請求的時候可能會有這樣的錯誤：

這就是我們在setting中設定了csrf中介軟體後，在請求中沒有設定csrf token的問題，導致伺服器開啟了csrf驗證環節嗎，但是發現請求中並沒有token，所以無法對比返回403錯誤。

首先可以注掉這個中介軟體不使用，django就會放棄對csrf的檢驗。但這樣就算是放棄了django原生的csrf安全元件，後果可能會造成跨站偽造，當然如果是測試就注釋掉。

另外，django給出了另一種解決辦法，它提供了csrf_exempt這個裝飾器，在不注釋此中介軟體的情況下，在view外加上這個裝飾器，可以在呼叫csrfmiddleware的process_view中跳過。原始碼如下：

csrf_exempt裝飾器會先給檢視函式註冊乙個csrf_exempt為true的屬性，當處理process_view時，會判斷此值是否為true，是則跳過下面邏輯。

以上我們都在想著這麼去掉這段功能，如果要正常使用它怎麼辦？

如果使用的是django自帶的render頁面模型，我們需要在template中加入csrf_token這個引數，這個引數會根據配置是否存入session。在post請求時，需要加上，這樣中介軟體就拿到前端上傳的token和自己有的進行對比，在驗證是否偽造請求。

最好要在檢視函式前同樣加上@csrf_protect這個裝飾器，表示支援csrf中介軟體的檢查。

如果是前後端分離，也可以借用csrf中介軟體的一套，只不過需要把生成token的邏輯單獨維護乙個api，把原來render的邏輯改到api上，後面我們每次post請求的時候，先拿到token，再新增到請求引數裡面提交，之後驗證的邏輯就和原邏輯一致了。