csrf token顆粒度選擇：每一個request更新一次VS每一個session更新一次

1、csrf簡介

什麼是csrf

csrf：Cross-site request forgery 跨網站請求僞造
當你登陸某網站後，你的瀏覽器其餘受感染的網站發起了操做你網站的請求，這時候你的cookie會被攜帶到服務器上，服務器沒法識別訪問者是否正確，從而接收受感染網站的請求（詳情參考該連接http://www.cnblogs.com/hyddd/...）

如何防護：

讓非讀取請求（非GET，HEAD等http方法）攜帶一個特別的字段，每次請求的時候帶上它，對它進行驗證，若是正確，則繼續其餘操做。
這個驗證能夠有多種方式，好比如下兩個例子：

• 生成一個隨機字符串，放在瀏覽器cookie裏，而後post上來的表單或者http header中攜帶上該字段，服務驗證是否相同。

• 是對sessionid進行運算生成字符串，服務器也進行運算，若是相同則信任請求。其原理都是以僞造請求沒法讀取，修改http請求報文爲基礎。

2、csrf token使用

form表單

非讀取請求大可能是進行數據操做。常見的數據操做是提交表單，爲了安全，Django和Flask提供了csrf token進行保護。只須要在template中引入{{csrf_token}}便可

ajax提交

若是須要使用ajax提交，方法也很簡單。Django爲例，只要讀取cookie，在http請求頭中添加自定義字段X-CSRFToken便可實現csrf驗證。

3、顆粒度選擇

細心的你可能發現，使用ajax提交後csrf token沒有更新。
Django，Flask的Form表單默認每次請求後更新csrf token，也就是說每一個request更新一次request，使用起來無壓力，很方便。然而使用的ajax提交的方式實際上是每一個session更新一次。那二者有和不一樣，有沒有安全問題呢？
答案是不必每一個請求都更新一次csrf token的，它不會帶來任何安全上的提高，有些時候還會帶來沒必要要的麻煩。好比你在瀏覽器的標籤頁中同時打開你的webapp，此時當一個標籤頁作提交操做後，會更新cookie中的csrf_token，會讓另外一個標籤頁的提交失敗。所以，咱們只須要每一個session維護一個csrf token就夠了。

那麼，爲何Django它們還要這麼費勁呢？其實並非什麼狀況下都不須要更新session。當發生重要變化的時候，好比登陸，則必須更新csrf_token。

舉個例子：攻擊者將本身的session id和csrf token注入被入侵者的瀏覽器時，若不更新csrf token。那麼當被入侵者登錄時，攻擊者就擁有了被入侵者的帳號控制權限。

最新思考：若是csrf_token只在某些頁面更新，那麼要分散更多精力去在乎哪些頁面須要csrf_token。好比一個頁面不須要登陸，同時須要post數據，當用戶第一次訪問該網站時就來到該界面，那麼頁面必定須要csrf_token才能post操做。因此，我的建議仍是每次更新，這樣子省心

http://security.stackexchange...