### csrf的原理與危害 CSRF (Cross Site Request Forgery)，中文全稱跨站點請求偽造。 以兩個例子說明， 案例一： 一個銀行站點存在一個csrf漏洞，用戶A轉(zhuǎn)賬給B用戶2000元，執(zhí)行轉(zhuǎn)賬操作后會對銀行發(fā)送一次請求：http://www.bank.com/money?user=A&num=2000&transfer=B，然后A用戶就會把自己的2000元轉(zhuǎn)到B的賬戶下。在發(fā)送這個請求給銀行服務(wù)器時，服務(wù)器首先會驗證這個請求是否為一個合法的session，并且用戶A確認(rèn)登陸才可以驗證通過。 如果此時有一個惡意用戶C想把A用戶的錢轉(zhuǎn)到自己的賬戶下，那么他可以構(gòu)造 http://www.bank.com/money?user=A&num=2000&transfer=C 這個請求，但是這個請求必須有A用戶發(fā)出才可以生效，此時惡意用戶C可以搭建一個自己的網(wǎng)站，在網(wǎng)站中寫入如下代碼 ```<img src="http://www.bank.com/money?user=A&num=2000&transfer=C">```,之后誘導(dǎo)A用戶訪問自己的網(wǎng)站，當(dāng)A訪問這個網(wǎng)站時，這個網(wǎng)站就會把img標(biāo)簽里的URL發(fā)給銀行服務(wù)器，而此時除了這個請求以外，還會把A用戶的cookie一起發(fā)到服務(wù)器，如果此時A用戶的瀏覽器與銀行的session沒有過期，那么就會在A用戶毫不知情的情況下執(zhí)行轉(zhuǎn)賬給C的操作。 案例二： 一個cms系統(tǒng)的管理后臺，可以發(fā)送一個post請求添加一個管理員，由于沒有加token或者驗證碼限制，惡意攻擊者可以在自己的服務(wù)器evil.com上建立一個a.html的文件，a.html文件是一個添加管理員賬戶的表單，上面寫入需要添加的賬戶用戶名及密碼，當(dāng)網(wǎng)站管理員打開evil.com/a.html的時候，并且管理員的session沒有失效，那么此時a.html就會請求受攻擊網(wǎng)站，在管理員毫不知情的情況下添加一個后臺賬戶。 通過以上兩個案例可以得出結(jié)論，csrf會根據(jù)業(yè)務(wù)功能場景的不用而利用起來也不同，這些請求都是跨域發(fā)起的，而且是在受害者的session沒有失效通過身份認(rèn)證的情況下發(fā)生的。 使用用戶的登陸憑證，讓用戶自己在不知情的情況下，進(jìn)行修改數(shù)據(jù)的操作。 但是查詢數(shù)據(jù)的地方卻不需要保護，因為csrf是借助受害者的cookie來進(jìn)行攻擊者需要的惡意操作的，攻擊者并不能拿到受害者cookie，對于服務(wù)器返回的結(jié)果也無法解析查看，攻擊者唯一可以做的就是讓服務(wù)器執(zhí)行自己的操作命令，或者說改變網(wǎng)站數(shù)據(jù)，而查詢操作即不會改變數(shù)據(jù)也不會把結(jié)果返回給攻擊者，所以并不需要保護。