CSRF漏洞

CSRF漏洞原理：

     CSRF是跨站请求伪造，不攻击网站服务器，而是冒充用户在站内的正常操做。一般因为服务端没有对请求头作严格过滤引发的。CSRF会形成密码重置，用户伪造等问题，可能引起严重后果。

    咱们知道，绝大多数网站是经过cookie等方式辨识用户身份，再予以受权的。因此要伪造用户的正常操做，最好的方法是经过XSS或连接欺骗等途径，让用户在本机（即拥有身份cookie的浏览器端）发起用户所不知道的请求。CSRF攻击会令用户在不知情的状况下攻击本身已经登陆的系统。

 

 

       CSRF攻击的目的是滥用基本的Web功能。若是该网站可使服务器上的状态变化，如改变受害者的电子邮件地址或密码，或购买的东西，强迫受害人检索数据等等。CSRF攻击会修改目标状态。在这一过程当中，受害者会代替攻击者执行这些攻击，攻击者中不会收到响应，受害者会代替攻击者执行这些攻击。

　　在跨站点请求伪造（CSRF）攻击中，攻击者经由用户的浏览器注入网络请求来破坏用户与网站的会话的完整性。浏览器的安全策略容许网站将HTTP请求发送到任何网络地址。此策略容许控制浏览器呈现的内容的攻击者使用此用户控制下的其余资源。

　　须要对页面参数作修改时，可使用burpsuite生成的csrf poc，从而进行poc测试，测试完成以后必定要验证，浏览器执行了咱们生成的poc测试，令数据产生变化。

　　csrf能够和XSS联系在一块儿，XSS获取cookie，CSRF伪造跨站请求完成指令。

 

漏洞利用重点：

　　一、CSRF的攻击创建在浏览器与web服务器的会话中

　　二、欺骗用户访问URL

 

攻击场景：

CSRF攻击（GET）：

　　这种类型的CSRF通常因为程序员的安全意识不强形成的。GET类型的CSRF利用很是简单，只须要一个HTTP请求，因此，通常会这样利用：<img src=http://test.com/csrf?xx=11 />

　　在访问含有这个img的页面后，成功向http://test.com/csrf?xx=11 发出了一次HTTP请求。

　　假如微博存在CSRF漏洞，有一个GET请求让别人点击后关注我，这时能够作一些诱惑性的博客。

　　假如想让每一个用户都帮助本身转发微博，制造一次蠕虫攻击，找到转播文章的页面与关注个人页面，写一个POC，用<iframe>标签来加载URL，加载两条URL，这时当用户点击会关注而且自动转发。

 CSRF攻击（POST）：构造form表单，利用javascript提交。

 

读取型CSRF：

什么是读取型CSRF，以下的漏洞能够概括进读取型CSRF，由于这些漏洞的利用手法都跟CSRF是同样的：

• JSONP劫持
• Flash跨域劫持
• CORS跨域资源读取

...等等，还有一些Sliverlight跨域这些。

 

浏览器Cookie机制：

cookie的两种表现形式：一种是本地Cookie，又称持久性Cookie；

　　　　　　　　　　   一种是临时Cookie，又称Session Cookie；

 

检测CSRF漏洞：

　　一、手工检测如：http://www.test.com/test?id=1 经过此id能够删除指定的用户。能够编写一个POC get方式。

　　二、半自动检测：工具CSRFTester，另外burpsuite scanner模块也支持检测CSRF漏洞。

　　三、全自动检测：主要是插件。

 

预防跨站请求伪造：

　　其实如今有关CSRF漏洞防御已是比较成熟了，其主要防御的思路就是须要在进行后台数据修改操做的过程当中，添加对当前用户身份的有效验证措施，而不能仅限于cookie的识别。

　　（1）来源校验

　　使用http请求头中的referer来源，对客户端源身份校验，此方法早期使用较多，可是仍然容易被绕过，因此这里并不建议使用。

　　（2）用户token校验

　　添加基于当前用户身份的有效tokens随机验证机制，即在向后端提交数据操做请求时，添加基于当前用户的随机token校验值，此种校验方法当前使用比较多；（xss和csrf漏洞同时存在时token校验生效）

　　（3）当前用户密码验证

　　在修改关键信息时，要当前用户输入其自身的密码，以验证当前用户身份的真伪，防止未受权的恶意操做；

　　（4）添加验证机制

　　在请求数据提交前，需填写验证码信息提交，以增长对用户来源的有效验证，防止恶意未受权的操做产生。

 

绕过防护的经验：

　　相信你们在不少时候抓包一看有token或者删除referer从新发包报错了就会以为这里不会有csrf漏洞了，可实际状况可不必定。还有一种常见状况就是使用验证码，目前识别验证码的方法都没法直接利用到绕过CSRF防护上来，因此不考虑用户体验的话，验证码是防护CSRF攻击最有效的方法。

状况A：

　　无token无referer验证这种状况如今比较少了，通常出如今一些新上线的业务。通常测试时都是用firefox的live Http Headers插件先抓取一个正常请求的数据包，若是没token的话，先去掉referer字段再从新提交看返回值。若是没报错的话，那就能够直接写一个表单（POST型）或者构造个连接（GET型）从新测试了，通常都会成功；但有些经过ajax提交的是行不通的，由于ajax没法跨域。

状况B：

　　无token有referer验证这种状况比较常见，也许咱们抓包发现无token正庆幸时，删除referer从新提交一看发现报错了，难道就这样放弃了吗？

　　（1）能够试试空的referer：即删除header中的referer的值，若是服务器只是验证了是否存在referer没验证referer值的话，从新提交会发现一个CSRF漏洞又被发现了，由于全部跨域协议传递的请求都不会送referer的

　　（2)能够试试修改referer的值:若是原referer值为Referer：t.qq.com/xxxx话，咱们能够试试修改成Referer:t.qq.com.baidu.com/xxx。若是服务器只是验证了referer是否存在qq.com或者t.qq.com等关键词的话，针对前一种状况，咱们能够再腾讯某子站点（http://xx.qq.com)发个帖子将图片地址修改成咱们构造的csrf连接或者写好CSRF表单后将地址发布在微博上等待其它用户点击，针对后一种状况咱们能够创建个t.qq.com.yourdomain.com的域名存放CSRF表单来绕过REFERER检测。