CSRF（Cross Site Request Forgeries）跨網站請求偽造，也叫XSRF，通過偽裝來自受信任使用者的請求來攻擊利用受信任網站。
與對比
- xss:本網站執行了來自其它網站的指令碼
- csrf:其它網站對本網站產生了影響
一、攻擊
利用使用者登入態偽造http請求。
危害：
- 盜取使用者資金（網上銀行，購物）
- 冒充使用者發帖（廣告帖）
- 損壞網站名譽
1、 get攻擊
最簡單的CSRF攻擊：
- 使用者Alice登入訪問某有csrf漏洞的銀行網站http://www.examplebank.com。
- Alice被某些資訊誘導訪問危險網站B。
- 危險網站B上有一個<img>標籤<img src="http://www.examplebank.com/from=Alice&amount=100&to=Bob">
- 這個img標籤的src不指向圖片，而是一個http請求，這個請求讓銀行伺服器從Alice轉100到Bob賬戶上，由於Alice已經登入，瀏覽器發請求時候會帶上cookie騙取伺服器信任得到響應。
- 這樣Alice的錢就被悄悄轉走了。
<a href="http:xxx.com/xxx">點選</a>
<img src="http:xxx.com/xxx">
網路蠕蟲。
涉及敏感操作的請求改為POST請求。
2、post攻擊
危險網站偽造一個隱藏的表單，在onload事件中，觸發表單的提交事件。
為防止跳轉，可以加一個隱藏的iframe，在iframe中處理提交的請求。
二、防範
偽造http請求特點：
- B網站向A網站請求
- 帶A網站Cookies，但是B拿不到cookie，也看不到cookie內容
- 不訪問A網站前端
- referer為B網站
1、禁止第三方網站帶Cookies
same-site屬性:Strict,Lax
header('Set-Cookie: test=12345; SameSite=Lax')
缺點：相容性
2、驗證碼
B 不訪問A網站前端，所以在A前端頁面加入隨機驗證碼來識別請求是不是使用者主動發起的。B網站無法偽造一個完整請求。
node中ccap模組可以生成驗證碼：npm install ccap
優點：簡單粗暴，低成本，可靠。
缺點：使用者不友好。每次都要填，驗證碼輸入錯誤要重填。
3、使用內建隱藏變數
伺服器生成一串不重複的隨機數，用md5編碼後【也可以cookie hash生成】，一份存在session中，一份放在隱藏域中隨請求提交。B不訪問A網站前端所以拿不到token，也沒辦法拿到cookie中的token。
可以存session，也可以存cookie。。
var csrfToken=parseInt(Math.random()*9999999,10);
ctx.cookies.set('csrfToken',csrfToken);
缺點：沒法處理ajax請求。
也可以存在頁面的meta中。【處理ajax請求】
<meta name="csrf_token" content="4374023">
缺點：使用者開啟很多個視窗，只有最後一個頁面能成功提交，前面頁面會出錯，因為cookie中只能存一個tooken。
4、檢查網頁來源
referer是HTTP請求頭，包含請求來源地址。【正確單詞是referrer，但是規範中就是錯的】
伺服器知道正確來源。 驗證referer禁止來自第三方網站的請求。
req.headers.referer拿到。
file本地協議訪問和http協議訪問有點不一樣，不會傳送referer。
if(referer.indexOf('localhost')===-1){
throw new Error('非法請求');
}
檢查post提交時候的來源，來源不正確進行清空資料，返回403提示等錯誤處理。
問題：
B網站後面加上http://127.0.0.1:4200/csrf.html?haha=localhost。就可以匹配成功了。
解決：用正則去匹配。
if(!/^https?:\/\/localhost/.test(referer)){
}
缺點：有些瀏覽器允許使用者指定沒有referer。需要對referer為空時候進行取捨，要不要通過。
Referer值會記錄訪問來源，有些使用者認為侵犯自己隱私權，有些使用者可能會開啟瀏覽器防止跟蹤功能，不提供Referer，導致正常使用者請求被拒絕。
本文作者starof,因知識本身在變化，作者也在不斷學習成長，文章內容也不定時更新，為避免誤導讀者，方便追根溯源，請諸位轉載註明出處：http://www.cnblogs.com/starof/p/9043393.html 有問題歡迎與我討論，共同進步。