跨站请求伪造(CSRF)

概念

CSRF,全称为Cross-Site Request Forgery,跨站请求伪造,是一种网络攻击方式,它可以在用户毫不知情的情况下,以用户的名义伪造请求发送给被攻击站点,从而在未授权的情况下进行权限保护内的操作。

具体来讲,可以这样理解CSRF。攻击者借用用户的名义,向某一服务器发送恶意请求,对服务器来讲,这一请求是完全合法的,但攻击者确完成了一个恶意操作,比如以用户的名义发送邮件,盗取账号,购买商品等等。

原理

CSRF攻击原理比较简单,例如Web A为存在CSRF漏洞的网站,Web B为攻击者构建的恶意网站,User C为Web A网站的合法用户。

用户C打开浏览器,访问受信任网站A,输入用户名和密码请求登录网站A; 

  

在用户信息通过验证后,网站A产生Cookie信息并返回给浏览器,此时用户登录网站A成功,可以正常发送请求到网站A;并且,此后从用户浏览器发送请求给网站A时都会默认带上用户的Cookie信息; 

  

用户未退出网站A之前,在同一浏览器中,打开一个TAB页访问网站B; 

  

网站B接收到用户请求后,返回一些攻击性代码,并发出一个请求要求访问第三方站点A; 

   

浏览器在接收到这些攻击性代码后,根据网站B的请求,在用户不知情的情况下携带Cookie信息,向网站A发出请求。网站A并不知道该请求其实是由B发起的,所以会根据用户C的Cookie信息以C的权限处理该请求,导致来自网站B的恶意代码被执行。

简单来说,CSRF必须经过两个步骤:

1、用户访问可信任站点A,并产生了相关的cookie;

2、用户在访问A站点时没有退出,同时访问了危险站点B。 

疑问:为什么网站A不能退出呢?

解决方法

服务器端表单hash认证

在所有的表单里面随机生成一个hash,server在表单处理时去验证这个hash值是否正确,这样工作量比较大。

验证http Referer字段

根据HTTP协议,HTTP头中的字段Referer记录了HTTP请求的来源地址。在通常情况下,访问一个安全受限页面的请求必须来自于同一个网站。比如某银行的转账是通过用户访问http://bank.test/test?page=10&userID=101&money=10000页面完成,用户必须先登录bank.test,然后通过点击页面上的按钮来触发转账事件。当用户提交请求时,该转账请求的Referer值就会是转账按钮所在页面的URL(本例中,通常是以bank. test域名开头的地址)。而如果攻击者要对银行网站实施CSRF攻击,他只能在自己的网站构造请求,当用户通过攻击者的网站发送请求到银行时,该请求的Referer是指向攻击者的网站。因此,要防御CSRF攻击,银行网站只需要对于每一个转账请求验证其Referer值,如果是以bank. test开头的域名,则说明该请求是来自银行网站自己的请求,是合法的。如果Referer是其他网站的话,就有可能是CSRF攻击,则拒绝该请求。

在HTTP头中自定义属性并验证

自定义属性的方法也是使用token并进行验证,和前一种方法不同的是,这里并不是把token以参数的形式置于HTTP请求之中,而是把它放到HTTP头中自定义的属性里。通过XMLHttpRequest这个类,可以一次性给所有该类请求加上csrftoken这个HTTP头属性,并把token值放入其中。这样解决了前一种方法在请求中加入token的不便,同时,通过这个类请求的地址不会被记录到浏览器的地址栏,也不用担心token会通过Referer(是指从哪里来,例如从http://www.baidu.com/页面点击过来的)泄露到其他网站。