CSRF 跨站请求伪造

CSRF漏洞

CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比XSS更具危险性。
跨站攻击的本质是， 攻击者拿着你的“身份凭证”，冒充你进行的相关攻击行为。

漏洞原理

CSRF攻击攻击原理及过程如下：
1. 用户打开浏览器，访问受信任银行网站，输入用户名和密码请求登录网站；
2.在用户信息通过验证后，银行网站产生Cookie信息并返回给浏览器，此时用户登录网站成功，可以正常发送请求到网站；

3. 用户未退出银行网站之前，在同一浏览器中，打开一个TAB页访问其他网站B

4. 这时候网站B 已被黑客注入诱导信息，加入是一张图片,图片地址指向
     src=”http://bank.example/withdraw?account=bob&amount=1000000&for=黑客
     点击之后转账给黑客这个账户
5. 浏览器在接收到这些攻击性代码请求后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，根据用户的Cookie信息以C的权限处理该请求，导致来自黑客请求恶意代码被执行。

漏洞危害

攻击者通过漏洞盗用你的身份令牌以正常用户的身份发送恶意的请求，例如修改密码、添加用户、转账、购买商品、也可配合XSS打组合拳获取管理员登录凭证等一些敏感操作。

漏洞利用

GET方式CSRF利用

        当一个危险请求是通过GET方式传输的，且其中参数容易被攻击者进行伪造，那么该功能点处就可能存 在CSRF。
例如：修改密码为http://XXXXXX.com/changepwd.php?user=ceshi&newpwd=XXXX&repeatpwd=XXX X&change=change

由于该链接无token保护且无任何防护，此时该链接可被伪造，将构造好的链接如：
http://XXXXXX.co m/changepwd.php?user=admin&newpwd=123456&repeatpwd=123456&change=change
发送给目 标用户点击就会触发CSRF,修改该用户的密码。
我们也可以将该链接生成一个短链接来进一步诱骗用户点 击，短链接生成网上有很多，例如：

我们使用 pikachu靶场 来演示一下GET型CSRF的效果 , 首先我们来到对应的CSRF GET模块,其中存在vince/allen/kobe/grady/kevin/lucy/lili密码都是123456， 我们登录vince用户。 在修改个人信息处抓包发现该处功能点是GET方式传输并在参数中没有任何校验，这就造就了CSRF。

我们将修改个人信息的请求包提取出来http://www.pikachu.com/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=18626545453&add=chain&email=vince%40pikachu.com&submit=submit 例 如当前用户lili正在登录系统进行操作

我们通过上述构造的数据包诱使正在登录系统的lili去点击，当lili点击了攻击者构造好的URL,就会在lili在 知情的情况下，将lili的个人信息修改。 http://www.pikachu.com/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=18626545453&add=chain&email=vince%40pikachu.com&submit=submit 假如将payload发送给受害者之后顺利点击。那么我们就可以成功的修复他的信息了。我们对比可发现修改成功：


HELLOILI欢迎来到个人会员中心退出登录

PIKACHU漏洞练习平台PIKAPIKA

手机:18626545453

CROSS-SITESCRIPTING

CSRF>CSRF(GET

箱:VINCE@PIKACHU.COM

修改个人信息

CSRF(POST)

SQL-INJECT

姓名:LILI

CSRFGET)

往址:CHAIN

性别:BOY

系统介绍

SRFTOKEN

暴力波能

CSRF

RCE

概述

我们通过上述构造的数据包诱使正在登录系统的lili去点击，当lili点击了攻击者构造好的URL,就会在lili在 知情的情况下，将lili的个人信息修改。 http://www.pikachu.com/vul/csrf/csrfget/csrf_get_edit.php?sex=boy&phonenum=18626545453&add=chain&email=vince%40pikachu.com&submit=submit 假如将payload发送给受害者之后顺利点击。那么我们就可以成功的修复他的信息了。我们对比可发现修改成功：

POST方式CSRF利用

当一个危险请求是通过POST方式传输，且其中参数容易被攻击者进行伪造，那么该功能点处就可能造成 CSRF。 我们还是使用pikachu靶场进行演示分析
我们还是登录vince用户，在修改个人信息处抓包发现该处功能点是以POST传递数据并数据包中没有 token进行校验。

由于需要POST传递数据所以我们无法使用URL来伪造请求，我们可通过Burp对生成该请求的CSRF代 码。

如下就是通过Burp生成的该请求CSRF前端代码，我们只需要将该请求放入HTML中让lili用户去点击，也 会达到同样修改lili个人信息的效果。
设置我们想要修改的参数 ： 

 
 
 
   

     
     
     
     
     
     
   

 

点击后：当然这里html 可以做一个隐藏的自动提交处理。

漏洞修复

1、验证 HTTP Referer 字段
根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。

也就是说，服务器会验证客户端的请求来源，如果本网站请求的则响应，否则不响应。但是即使这样，验证 HTTP Referer 字段 这种方式也存在安全隐患
1.对于某些浏览器，比如 IE6 或 FF2，目前已经有一些方法可以篡改 Referer 值
2.用户自己可以设置浏览器使其在发送请求时不再提供 Referer
2、加验证码验证
但这种方式涉及到页面交互，在通常情况下，验证码能很好遏制CSRF攻击。但是出于用户体验考虑，网站不能给所有的操作都加上验证码。因此验证码只能作为一种辅助手段，不能作为主要解决方案。
3、使用 token （Anti CSRF Token）
可以理解是防伪
例子：
1用户访问某个表单页面。
2服务端生成一个Token，放在用户的Session中，或者浏览器的Cookie中。
3在页面表单附带上Token参数。
4用户提交请求后， 服务端验证表单中的Token是否与用户Session（或Cookies）中的Token一致，一致为合法请求，不是则非法请求。

这个Token的值必须是随机的。由于Token的存在，攻击者无法再构造一个带有合法Token的请求实施CSRF攻击。另外使用Token时应注意Token的保密性，尽量把敏感操作由GET改为POST，以form或AJAX形式提交，避免Token泄露。
总结：
通常使用Anti CSRF Token来防御CSRF攻击，同时要注意Token的保密性和随机性。