### csrf的原理与危害
CSRF (Cross Site Request Forgery),中文全称跨站点请求伪造。
以两个例子说明,
案例一:
一个银行站点存在一个csrf漏洞,用户A转账给B用户2000元,执行转账操作后会对银行发送一次请求:http://www.bank.com/money?user=A&num=2000&transfer=B,然后A用户就会把自己的2000元转到B的账户下。在发送这个请求给银行服务器时,服务器首先会验证这个请求是否为一个合法的session,并且用户A确认登陆才可以验证通过。
如果此时有一个恶意用户C想把A用户的钱转到自己的账户下,那么他可以构造 http://www.bank.com/money?user=A&num=2000&transfer=C 这个请求,但是这个请求必须有A用户发出才可以生效,此时恶意用户C可以搭建一个自己的网站,在网站中写入如下代码 ```<img src="http://www.bank.com/money?user=A&num=2000&transfer=C">```,之后诱导A用户访问自己的网站,当A访问这个网站时,这个网站就会把img标签里的URL发给银行服务器,而此时除了这个请求以外,还会把A用户的cookie一起发到服务器,如果此时A用户的浏览器与银行的session没有过期,那么就会在A用户毫不知情的情况下执行转账给C的操作。
案例二:
一个cms系统的管理后台,可以发送一个post请求添加一个管理员,由于没有加token或者验证码限制,恶意攻击者可以在自己的服务器evil.com上建立一个a.html的文件,a.html文件是一个添加管理员账户的表单,上面写入需要添加的账户用户名及密码,当网站管理员打开evil.com/a.html的时候,并且管理员的session没有失效,那么此时a.html就会请求受攻击网站,在管理员毫不知情的情况下添加一个后台账户。
通过以上两个案例可以得出结论,csrf会根据业务功能场景的不用而利用起来也不同,这些请求都是跨域发起的,而且是在受害者的session没有失效通过身份认证的情况下发生的。
使用用户的登陆凭证,让用户自己在不知情的情况下,进行修改数据的操作。
但是查询数据的地方却不需要保护,因为csrf是借助受害者的cookie来进行攻击者需要的恶意操作的,攻击者并不能拿到受害者cookie,对于服务器返回的结果也无法解析查看,攻击者唯一可以做的就是让服务器执行自己的操作命令,或者说改变网站数据,而查询操作即不会改变数据也不会把结果返回给攻击者,所以并不需要保护。