CSRF简单介绍及利用方法-跨站请求伪造

0x00 简要介绍



CSRF(Cross-site request forgery)跨站请求伪造,由于目标站无token/referer限制,导致攻击者可以用户的身份完成操作达到各种目的。根据HTTP请求方式,CSRF利用方式可分为两种。

0x01 GET类型的CSRF



这种类型的CSRF一般是由于程序员安全意识不强造成的。GET类型的CSRF利用非常简单,只需要一个HTTP请求,所以,一般会这样利用:

<img src=http://wooyun.org/csrf.php?xx=11 />

如下图,在访问含有这个img的页面后,成功向http://wooyun.org/csrf.php?xx=11发出了一次HTTP请求。所以,如果将该网址替换为存在GET型CSRF的地址,就能完成攻击了。

乌云相关案例:

http://wooyun.org/bugs/wooyun-2010-023783

http://wooyun.org/bugs/wooyun-2010-027258 (还未公开)

0x02 POST类型的CSRF



这种类型的CSRF危害没有GET型的大,利用起来通常使用的是一个自动提交的表单,如:

<form action=http://wooyun.org/csrf.php method=POST>
<input type="text" name="xx" value="11" />
</form>
<script> document.forms[0].submit(); </script>

访问该页面后,表单会自动提交,相当于模拟用户完成了一次POST操作。

乌云相关案例:

http://wooyun.org/bugs/wooyun-2010-026622

http://wooyun.org/bugs/wooyun-2010-022895

0x03 其他猥琐流CSRF



过基础认证的CSRF(常用于路由器):

POC:

<img src=http://admin:[email protected]
/* <![CDATA[ */!function(){try{var t="currentScript"in document?document.currentScript:function(){for(var t=document.getElementsByTagName("script"),e=t.length;e--;)if(t[e].getAttribute("cf-hash"))return t[e]}();if(t&&t.previousSibling){var e,r,n,i,c=t.previousSibling,a=c.getAttribute("data-cfemail");if(a){for(e="",r=parseInt(a.substr(0,2),16),n=2;a.length-n;n+=2)i=parseInt(a.substr(n,2),16)^r,e+=String.fromCharCode(i);e=document.createTextNode(e),c.parentNode.replaceChild(e,c)}}}catch(u){}}();/* ]]> */ />

加载该图片后,路由器会给用户一个合法的SESSION,就可以进行下一步操作了。

乌云相关案例:

WooYun: TP-LINK路由器CSRF,可干许多事(影响使用默认密码或简单密码用户)

0x04 如何修复



针对CSRF的防范,有以下几点要注意:

关键操作只接受POST请求

验证码

CSRF攻击的过程,往往是在用户不知情的情况下构造网络请求。所以如果使用验证码,那么每次操作都需要用户进行互动,从而简单有效的防御了CSRF攻击。

但是如果你在一个网站作出任何举动都要输入验证码会严重影响用户体验,所以验证码一般只出现在特殊操作里面,或者在注册时候使用

检测refer

常见的互联网页面与页面之间是存在联系的,比如你在www.baidu.com应该是找不到通往www.google.com的链接的,再比如你在论坛留言,那么不管你留言后重定向到哪里去了,之前的那个网址一定会包含留言的输入框,这个之前的网址就会保留在新页面头文件的Referer中

通过检查Referer的值,我们就可以判断这个请求是合法的还是非法的,但是问题出在服务器不是任何时候都能接受到Referer的值,所以Refere Check 一般用于监控CSRF攻击的发生,而不用来抵御攻击。

Token

目前主流的做法是使用Token抵御CSRF攻击。下面通过分析CSRF 攻击来理解为什么Token能够有效

CSRF攻击要成功的条件在于攻击者能够预测所有的参数从而构造出合法的请求。所以根据不可预测性原则,我们可以对参数进行加密从而防止CSRF攻击。

另一个更通用的做法是保持原有参数不变,另外添加一个参数Token,其值是随机的。这样攻击者因为不知道Token而无法构造出合法的请求进行攻击。

Token 使用原则

Token要足够随机————只有这样才算不可预测
Token是一次性的,即每次请求成功后要更新Token————这样可以增加攻击难度,增加预测难度
Token要注意保密性————敏感操作使用post,防止Token出现在URL中

0x05 测试CSRF中注意的问题



如果同域下存在xss的话,除了验证码,其他的方式都无法防御这个问题。

有个程序后端可能是用REQUEST方式接受的,而程序默认是POST请求,其实改成GET方式请求也可以发送过去,存在很严重的隐患。

当只采用refer防御时,可以把请求中的修改成如下试试能否绕过:

原始refer:http://test.com/index.php

测试几种方式(以下方式可以通过的话即可能存在问题):

http://test.com.attack.com/index.php
http://attack.com/test.com/index.php
[空]

refer为空构造的方法:

由于浏览器特性,跨协议请求时不带refer(Geckos内核除外),比如https跳到http,如果https环境不好搭建的话,ftp其实也是可以的:)

<iframe src="data:text/html,<script src=http://www.baidu.com></script>"> //IE不支持

利用 xxx.src=‘javascript:"HTML代码的方式"‘; 可以去掉refer,IE8要带。
<iframe id="aa" src=""></iframe>
<script>
document.getElementById("aa").src=‘javascript:"<html><body>wooyun.org<scr‘+‘ipt>eval(你想使用的代码)</scr‘+‘ipt></body></html>"‘;
</script>

http://www.ibm.com/developerworks/cn/web/1102_niugang_csrf/
时间: 09-10

CSRF简单介绍及利用方法-跨站请求伪造的相关文章

跨站请求伪造CSRF(Cross-site request forgery)

CSRF(Cross-site request forgery)跨站请求伪造,也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用 一般被攻击步骤: 1.登录受信任网站A,并在本地生成Cookie. 2.在不登出A的情况下,访问危险网站B. 所以没事的时候不要乱点链接不是随便说着玩的. 常见场景分析: 假设你有一个这样的Action,因为已经加了[Authorize(Roles = "Admins")]标记

Web安全测试之跨站请求伪造(CSRF)篇

跨站请求伪造(即CSRF)被Web安全界称为诸多漏洞中“沉睡的巨人”,其威胁程度由此“美誉”便可见一斑.本文将简单介绍该漏洞,并详细说明造成这种漏洞的原因所在,以及针对该漏洞的黑盒测试与灰盒子测试具体方法和示例,最后提提了一些防范该攻击的建议,希望本文对读者的安全测试能够有所启发. 一.CSRF概述 我们首先来了解一下什么是跨站请求伪造(CSRF)?跨站请求伪造是一种挟制终端用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法.攻击者只要借助少许的社会工程诡计,例如通过电子邮件或者是聊天

Web安全相关(二):跨站请求伪造(CSRF/XSRF)

简介 CSRF(Cross-site request forgery跨站请求伪造,也被称为"One Click Attack"或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用.尽管听起来像跨站脚本(XSS),但它与XSS非常不同,并且攻击方式几乎相左.XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站.与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更

自动化运维Python系列之Django CSRF跨站请求伪造、中间件

CSRF CSRF,跨站请求伪造是一种挟持用户在当前已登陆的web站点应用程序上执行非本意的操作攻击方法,简单地说,是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作(如发邮件,发消息,甚至财产操作如转账和购买商品). Django的CSRF中间件验证就可以有效地杜绝此类恶意攻击,原理就是Django在内部会对通过验证请求的客户端再做一次加密验证,该加密方式只有Django自己知道,客户端即使携带session反解密CSRF不成功也会拒绝访问:这是Django生

CSRF跨站请求伪造

CSRF(Cross-site request forgery跨站请求伪造,也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用.尽管听起来像跨站脚本(XSS),但它与XSS非常不同,并且攻击方式几乎相左.XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站.与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性. ht

深入解析跨站请求伪造漏洞:实例讲解

本文的上篇中,我们着重介绍了跨站请求伪造的原理,并指出现有的安全模型并不能真正防御这种攻击.在下篇中,我们将向读者介绍在一些大型站点上发现的几个严重的CSRF漏洞,攻击者利用这些漏洞不仅能够采集用户的电子邮件地址,侵犯用户隐私并操控用户帐户.如果金融站点出现了跨站请求伪造漏洞的话,这些漏洞甚至允许攻击者从用户的银行帐户中划走资金.为了全面的防御CSRF攻击,建议对服务器端进行改造.此外,本文还会介绍服务器端解决方案应具备的特征,如果缺乏这些特性,就会导致CSRF保护措施不必要地妨碍典型的web浏

跨站请求伪造

1. 什么是跨站请求伪造(CSRF)  CSRF(Cross-site request forgery跨站请求伪造,也被称为"One Click Attack"或者Session Riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用.尽管听起来像跨站脚本(XSS),但它与XSS非常不同,并且攻击方式几乎相左.XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站.与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少

深入解析跨站请求伪造漏洞:原理剖析

当存心不良的Web站点导致用户的浏览器在可信的站点上进行非意愿的活动时,我们就说发生了跨站请求伪造(CSRF)攻击.这些攻击被誉为基于Web的漏洞中的“沉睡的巨人”,因为互联网上的许多站点对此毫无防备,同时还因为这类攻击一直为web开发和安全社区所忽视. 一.概述 当存心不良的Web站点导致用户的浏览器在可信的站点上进行非意愿的活动时,我们就说发生了跨站请求伪造(CSRF)攻击.跨站请求伪造攻击亦称跨站引用伪造(XSRF),会话叠置和混淆代理人攻击.我们之所以使用术语CSRF,是因为它是描述这类

跨站请求伪造(防护)

跨站请求伪造(防护) 任何Web应用所面临的一个主要安全漏洞是跨站请求伪造,通常被简写为CSRF或XSRF,发音为"sea surf".这个漏洞利用了浏览器的一个允许恶意攻击者在受害者网站注入脚本使未授权请求代表一个已登录用户的安全漏洞. 为了防范伪造POST请求,我们会要求每个请求包括一个参数值作为令牌来匹配存储在cookie中的对应值.我们的应用将通过一个cookie头和一个隐藏的HTML表单元素向页面提供令牌.当一个合法页面的表单被提交时,它将包括表单值和已存储的cookie.如