前端安全 - CSRF

上一篇文章講完了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的防範如今已經很完善了，接口作好配置，仍是能夠很好防範的～