CSRF简单介绍

最新推荐文章于 2024-06-28 14:25:58 发布

fw0124

最新推荐文章于 2024-06-28 14:25:58 发布

阅读量1.1k

点赞数

分类专栏：网络安全文章标签： csrf

网络安全专栏收录该内容

1 篇文章 0 订阅

订阅专栏

0x00 简要介绍

CSRF（Cross-site request forgery）跨站请求伪造，由于目标站无token/referer限制，导致攻击者可以用户的身份完成操作达到各种目的。

举个例子来说吧(受害者的网址是a.cn，攻击者的网址是b.cn)攻击者想要在某个网站(网站是某个开源CMS)添加上另一个管理员，但是这个网站并没有XSS漏洞。怎么办呢？这时攻击者发现了这个开源CMS后台添加管理员时并没有加入验证码或则token，只需要输入要添加的管理员账号和密码点击确定就可以添加管理员账户了。这时和我一样聪明的攻击者在自己的服务器上建立了一个html文件(假设地址是b.cn/index.html)。然后就给网站管理员发邮件等等，诱使管理员打开b.cn/index.html。当管理员打开后（这时管理员正在网站后台，或管理员的session并没有失效的话），就可以神不知鬼不觉的在网站后台添加了一个管理员账户。

根据HTTP请求方式，CSRF利用方式可分为两种。

0x01 GET类型的CSRF

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

在访问含有这个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(常用于路由器):

<img src=http://admin:admin@192.168.1.1></img>

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

乌云相关案例：
http://www.wooyun.org/bugs/wooyun-2013-026825 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中

Spring MVC中对于CSRF攻击的防御

在Spring MVC应用中实施CSRF防御，一般会采用 EYAL LUPU (http://blog.eyallupu.com/2012/04/csrf-defense-in-spring-mvc-31.html)的方案，该方案的基本思路是在生成表单时在其中插入一个随机数作为签名，在表单提交后对其中的签名进行验证，根据验证的结果区分该表单是否是经由应用签署的合法表单。如果签名不正确或不存在签名，则说明请求可能已被劫持。

EYAL LUPU方案的巧妙之处在于，通过使用HandlerInterceptorAdapter和Spring3.1中新引入的ReuqestDataValueProcessor这一对组合，使得签名和验证的过程无缝地集成到现有应用中。Controller或Model层的对象可以仍然只关心自己的业务逻辑，完全不必考虑CSRF过程的存在；唯一的限制是在View层，必须使用Spring的<form>标签来渲染表单。

转载：

1）http://drops.wooyun.org/papers/155
2) http://www.freebuf.com/articles/web/55965.html
3) http://www.cnblogs.com/javawebsoa/archive/2013/05/19/3087634.html