首先需要明確，CSRF指的是Cross Site Request Forgery，而很多時候會有人把CSRF與XSRF混淆，這里說明一下，XSRF是XSS & CSRF的合寫，也就是借助XSS（Cross Site Scripts）漏洞，結(jié)合CSRF利用。正文會詳細(xì)解釋。
在此聲明，如果文章里有說的不對的，請各位看官耐心指教，勿噴。
一、CSRF的本質(zhì)及原因
應(yīng)用的重要操作頁面的所有參數(shù)都可預(yù)測。 即URL請求易被攻擊者偽造，且利用cookies等登錄狀態(tài)，以達(dá)到無需獲取用戶權(quán)限，就可以偽造用戶請求，對用戶數(shù)據(jù)進(jìn)行操作的目的。（在用戶不知情的情況下，利用用戶身份，提交用戶請求。）
二、如何測試CSRF
對于目標(biāo)站點(diǎn)，對一個操作進(jìn)行猜測，構(gòu)造一個對應(yīng)用有修改操作（信息修改，帖子刪除等）的請求URL（比如放在img的src里面），然后放在非此站點(diǎn)的站點(diǎn)下，然后在自己登錄了此站點(diǎn)后（保證有了登陸態(tài)），訪問放置偽造請求的站點(diǎn)，回到此站點(diǎn)，觀察對應(yīng)用的修改操作是否完成。如果完成，則證明有CSRF漏洞。
三、如何利用CSRF
實(shí)際上，CSRF攻擊，指的是利用用戶的登錄態(tài)，偽造一個用戶不知情的請求，在用戶不知情的情況下，達(dá)到請求發(fā)起成功的效果。即：利用了網(wǎng)站應(yīng)用對請求發(fā)起合法性的檢查，本質(zhì)上是無需獲取用戶權(quán)限，就可以模擬用戶進(jìn)行操作。
主要原因是，一般的網(wǎng)站應(yīng)用對http請求的驗(yàn)證是，session和cookie機(jī)制，因?yàn)閏ookies會默認(rèn)隨著請求一起發(fā)送，所以一旦用戶登錄了某個站點(diǎn)，隨后只要cookie不過期，或者瀏覽器不關(guān)閉，那么再次的請求都會攜帶著發(fā)送cookies驗(yàn)證信息。當(dāng)用戶在瀏覽器中點(diǎn)擊了黑客偽造的鏈接時，同樣的cookies會隨著這個請求被發(fā)送到后臺，后臺驗(yàn)證身份：即cookies正確，則執(zhí)行請求操作，從而，完成了一次CSRF攻擊。
四、寫POC驗(yàn)證頁面是否有CSRF
這里需要注意的是，CSRF的存在前提是應(yīng)用的修改操作對用戶的身份有驗(yàn)證，如果不存在驗(yàn)證也就不存在CSRF了。當(dāng)然，現(xiàn)在的網(wǎng)站應(yīng)用應(yīng)該都對重要操作有身份驗(yàn)證即權(quán)限要求。而被測網(wǎng)址一般情況下也是直接訪問修改操作頁面就會提示沒有權(quán)限或者直接跳轉(zhuǎn)到登錄頁面，所以一般需要先登錄進(jìn)去，才能進(jìn)一步進(jìn)行漏洞驗(yàn)證。
而且需要注意的是，可能修改操作頁面有許多form，必須要考慮這樣的情況。
當(dāng)對某個form進(jìn)行檢測時，需要判斷此form里是否有類似“token”的字樣，form提交的action（沒有action屬性，則action提交到自身頁面）有沒有類似“修改”的字樣。
還應(yīng)判斷，該form是否為登錄注冊的form，這樣的form，里面也無需token，但是不存在CSRF漏洞。
總之，CSRF漏洞的發(fā)起需要滿足3個條件：
1. 請求操作需要有身份驗(yàn)證
2. form表單除了cookie驗(yàn)證沒有其他驗(yàn)證
3. 非注冊，登錄等操作，即修改信息的（注意這里的"修改"）
五、如何防御CSRF
一、從開發(fā)者的角度來說，一個應(yīng)用如何避免CSRF，應(yīng)該有以下做法：
- 首先，盡量對修改應(yīng)用的請求用post方式，也就是用form，這樣黑客在瀏覽器的URL里就看不到具體參數(shù)，想要獲取也必須抓包，增加了攻擊難度。
- 其次，在多用form的前提下：利用Token，這是個附加的身份驗(yàn)證信息，一般會在form里的存在形式是: 一個input框，類型是hidden，比如：
<input type="hidden" value="513e45fd8d2sd" name="_tb_token">
這里的token值是從后端返回的，由后臺生成，返回前臺，一個安全策略是每一個請求的token都不一樣， 每次請求都會發(fā)送token值，后臺收到請求，不僅會比較cookies，還會比較token值，如果token值與后臺(Session或者客戶端cookie中)token值不相符，而且token值也沒有過期，則證明此請求合法；這時，如果還有黑客想要攻擊此應(yīng)用，偽造請求，但他不能知道form里的token值，偽造的請求里沒有此token，則請求不會得到正常響應(yīng)，請求的操作也不會被執(zhí)行。
當(dāng)然，如果token放在cookie中，而不是服務(wù)端的session中，則會有一個問題，如果頁面存在XSS漏洞，那么攻擊者完全可以利用XSS將用戶客戶端的cookie截取后，讀取其中的token，然后利用CSRF攻擊。這種方式被稱為XSRF，以和CSRF區(qū)分。
這里需要明白：csrf_token應(yīng)該作為一個秘密，只能被服務(wù)器和用戶知曉，第三者不能知曉。實(shí)際應(yīng)用中，Token可以放在用戶的Session，或者瀏覽器的Cookie中。
防御修復(fù)總結(jié)：
1. 重要操作用post，不要用get
2. 給form添加token令牌，數(shù)值隨機(jī)且隱秘
3. 服務(wù)端驗(yàn)證HTTP Referer字段，即判斷是否是從信任的域名過來的請求
六、session與cookie
1. Cookie：（2種）
- (1) Session Cookie(臨時cookie): 沒有設(shè)定過期時間，瀏覽器關(guān)閉，cookie失效
- (2)Third Party Cookie(本地(第三方)Cookie): cookie存儲在本地硬盤中，設(shè)置了Expire Time（過期時間），過期時間到，才過期
2. Session：
- 存放地：服務(wù)端：一般在內(nèi)存中，還可能是文件，或者DB(數(shù)據(jù)庫)
- 應(yīng)用：當(dāng)用戶第一次發(fā)起請求后，服務(wù)器在服務(wù)端記錄一個相應(yīng)的客戶端身份信息，其中重要的一項(xiàng)是SessionID，標(biāo)志了客戶端用戶信息。Token也可以生成后一份放在服務(wù)端，另一份放在修改的form里的token值里。(或者生成后，一個發(fā)送到客戶端的cookie中，另一個放在form里)
2016.11.9 下午 上海
