csrf，跨站請求偽造（cross site request forgery）
簡單來說，我是a，其他站點比如b，假裝是a做來某件事情。
那麼，請求是怎麼偽造的呢？我們來看下面這張圖。
為什麼呢？其實就是利用了請求的傳送機制。
我們知道cookie是繫結到網域名稱上的，如果**b請求了**a的介面，那麼請求是會攜帶**a的cookie到**a的伺服器。
**a收到請求之後，根據攜帶的cookie，就是認為是這條請求是受害者傳送過來的。
當然，我們都知道，受害者其實沒有這個意思。
對cookie機制不了解的，可以看下樓主的文章 cookie & session
講到這，我們應該都知道csrf會讓別人假裝我進行操作，那簡直是太危險了，那麼，我們來看以下要怎麼防範csrf的發生。
驗證碼，我們知道，csrf就是在我們不知情的情況下發送來請求，那麼如果請求需求互動，就可以防範csrf了。
當然，如果所有請求都要做驗證碼的話，使用者估計不想用我們的系統了，所以使用驗證碼的話還是要謹慎。
看一下掘金的http請求，會發現請求頭會帶有referer欄位，referer欄位是自動攜帶的，表示請求**。
那麼，我們的介面可以做的處理就是對referer做乙個校驗，不允許的源不能進行操作，這樣就可以阻止csrf的發生啦。
不過referer校驗也可以被繞過，如果使用者發請求的時候，先用抓包工具改了referer引數，那麼我們做的操作就沒有用了。
token校驗，應該說是csrf防範的業界標準了。
token校驗要配合cookie進行處理，登入的時候通過set-cookie，將乙個sign儲存在cookie中。
傳送請求的時候，通過sign計算出token，然後再每條請求中攜帶token，伺服器根據token進行校驗，不通過就拒絕。
我們看一下掘金頁面傳送的請求，請求都攜帶了token引數。
time33
上面講到sign可以計算出token，那麼到底怎麼算了，業界經典就是使用time33。time33是乙個字串雜湊函式。
function
time33(sign)
return (hash & 0x7fffffff);
}複製**
a：因為一直在乘33
q：為什麼是5381
a：5381（001 010 100 000 101）據說hash後分布會更好
csrf的防範現在已經很完善了，介面做好配置，還是可以很好防範的～
前端安全CSRF
安全類 csrf csrf 跨站請求偽造，英文 cross site request forgery forgery 攻擊原理 從上圖可以看出，要完成一次csrf攻擊，受害者必須依次完成兩個步驟 1.登入受信任 a，並在本地生成cookie。2.在不退出a的情況下，訪問危險 b。看到這裡，你也許會說...
前端安全之CSRF攻擊
csrf,即 cross site request forgery 中文名為跨站請求偽造。是一種挾持使用者在當前已登入的web應用程式上執行非本意的操作的一種攻擊方式。csrf攻擊的本質在於利用使用者的身份，執行非本意的操作。根據csrf的全名，可以得出的結論是 csrf的請求是跨域且偽造的。偽造指...
前端安全之CSRF攻擊
csrf,即 cross site request forgery 中文名為跨站請求偽造。是一種挾持使用者在當前已登入的web應用程式上執行非本意的操作的一種攻擊方式。csrf攻擊的本質在於利用使用者的身份，執行非本意的操作。根據csrf的全名，可以得出的結論是 csrf的請求是跨域且偽造的。偽造指...