上一篇文章講完了XSS，那麼我們接下來要說的就是CSRF。CSRF也是前端安全需要注意的一個重要的環節。
what
CSRF，跨站請求偽造（Cross Site Request Forgery）
簡單來說，我是A，其他站點比如B，假裝是A做來某件事情。
how
那麼，請求是怎麼偽造的呢？我們來看下面這張圖。
網站A：使用者登入，設定登入資訊到A的cookie
網站B：誘導使用者開啟網站B
網站B：頁面傳送來網站A的某個請求（可攜帶A的cookie），假裝是A操作（比如，刪除一條資料）
網站A：資料被刪除了！！！
why
為什麼呢？其實就是利用了請求的傳送機制。
我們知道cookie是繫結到域名上的，如果網站B請求了網站A的介面，那麼請求是會攜帶網站A的cookie到網站A的伺服器。
網站A收到請求之後，根據攜帶的cookie，就是認為是這條請求是受害者傳送過來的。
當然，我們都知道，受害者其實沒有這個意思。
對cookie機制不瞭解的，可以看下樓主的文章 cookie & session
防範
講到這，我們應該都知道CSRF會讓別人假裝我進行操作，那簡直是太危險了，那麼，我們來看以下要怎麼防範CSRF的發生。
驗證碼
驗證碼，我們知道，CSRF就是在我們不知情的情況下傳送來請求，那麼如果請求需求互動，就可以防範CSRF了。
當然，如果所有請求都要做驗證碼的話，使用者估計不想用我們的系統了，所以使用驗證碼的話還是要謹慎。
referer校驗
看一下掘金的http請求，會發現請求頭會帶有referer欄位，referer欄位是自動攜帶的，表示請求來源。
那麼，我們的介面可以做的處理就是對referer做一個校驗，不允許的源不能進行操作，這樣就可以阻止CSRF的發生啦。
不過referer校驗也可以被繞過，如果使用者發請求的時候，先用抓包工具改了referer引數，那麼我們做的操作就沒有用了。
token校驗
token校驗，應該說是CSRF防範的業界標準了。
token校驗要配合cookie進行處理，登入的時候通過set-cookie，將一個sign儲存在cookie中。
傳送請求的時候，通過sign計算出token，然後再每條請求中攜帶token，伺服器根據token進行校驗，不通過就拒絕。
我們看一下掘金頁面傳送的請求，請求都攜帶了token引數。
注意：由於token校驗是基於cookie的，所以如果網站被XSS的話，token防範也會失效的，這個時候要解決的就是XSS問題了。
time33
上面講到sign可以計算出token，那麼到底怎麼算了，業界經典就是使用time33。time33是一個字串雜湊函式。
function time33(sign) {
let hash = 5381;
for (let i = 0, len = sign.length; i < len; ++i) {
hash += (hash << 5) + sign.charCodeAt(i);
}
return (hash & 0x7fffffff);
}
複製程式碼Q：為什麼叫time33
A：因為一直在乘33
Q：為什麼是5381
A：5381（001 010 100 000 101）據說hash後分佈會更好
寫在最後
CSRF的防範現在已經很完善了，介面做好配置，還是可以很好防範的～