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