浅谈csrf攻击以及yii2对其的防范措施

凡是我yii2学习社群的成员都知道,我不止一次给大家说构造表单100%使用yii2的ActiveForm来实现,这除了能和AR更好结合外就是自动生成csrf隐藏域,一个非常安全的举措。

今天北哥就给大家普及下csrf是啥?如果你已经知道了可以直接拉文章到底部点个赞。:smile:

CSRF(Cross-site request forgery跨站请求伪造)是一种对网站的恶意利用,在 2007 年曾被列为互联网 20 大安全隐患之一。

关于CSRF,要从一个故事开始~

老王丢钱事件

这个故事要从程序员老王丢了1万块钱说起,总之是进了小偷,找回无果。丢钱后的老王一直在思考,钱是怎么丢的、为何丢钱、为何是我丢钱~~

后来老王出现了严重的心理问题,他决定报复社会。

老王首先研究了网银系统,他发现转账是通过GET形式

https://bank.abc.com/withdraw?account=liuxiaoer&amount=1000&to=abei

这意思就是说将 liuxiaoer 的1000元钱转给abei,当然当请求到达银行服务器后,程序会验证该请求是否来自合法的session并且该session的用户就是 liuxiaoer 并且已经登录。

老王自己也有一个银行账号 wang2,他尝试登录并且通过浏览器发送请求给银行,代码如下

https://bank.abc.com/withdraw?account=liuxiaoer&amount=1000&to=wang2

失败了~因为当前登录账号是老王自己,发送请求后服务器发现session所属用户wang2和account=liuxiaoer并不是一个人,因此被拒绝。

也就是说这个操作必须是 liuxiaoer 自己才可以,复仇的力量是可怕的,老王通过facebook层层找到了 liuxiaoer 就是快递员老刘的银行账号。

于是一个伟大的计划诞生了,老王的计划是这样的。

1、首先做一个网页,在网页中加入如下代码

src="https://bank.abc.com/withdraw?account=liuxiaoer&amount=1000&to=wang2"

然后通过各种情景让老刘(liuxiaoer)访问了此网页。

2、当老刘(liuxiaoer)访问此网页后,上面的请求会被发送到银行,此刻还会带着老刘(liuxiaoer)自己的浏览器cookie信息,当然这样一般也不会成功,因为银行服务器发现老刘(liuxiaoer)并不在登录状态。

3、老王想了一个招,他在淘宝找了一个灰色商人老李,让他通过种种方法,总之让老刘(liuxiaoer)通过浏览器给老李转了一次款。

4、就在第三步操作的2分钟内,老王成功让老刘(liuxiaoer)再一次访问了自己做的网页,你知道的,此刻老刘(liuxiaoer)在银行的session还没有过期,老王网页给银行服务器发送请求后,验证通过,打款成功。

5、老王收到了款,老刘(liuxiaoer)并不知道这一切,对于银行来说这是一笔在正常不过的转账。

这就是CSRF攻击,浏览器无法拦截。

CSRF攻击特点

基于上面血淋淋的故事,我们总结下CSRF攻击的几个特点。

  • 黑客借助于受害者的cookie等浏览器信息骗取服务器新人,黑客并拿不到cookie等。
  • 由于浏览器同源策略,黑客无法拿到攻击的响应结果,能做的只是发起请求,你是否还记得很多钓鱼网站都模拟了登录框么?
  • CSRF攻击主要是发送修改数据请求。

CSRF防御对象

因此我们要保护的是所有能引起数据变化的客户端请求,比如新建、更新和删除。

CSRF防御方案

基于CSRF攻击特点,在业界目前防御 CSRF 攻击主要有三种策略:

  • 验证 HTTP Referer 字段;
  • 在请求地址中添加 token 并验证;
  • 在 HTTP 头中自定义属性并验证。

HEEP Referer

在http请求的时候,头部有一个叫做Referer的字段,该字段记录本次请求的来源地址。因此服务器端可以通过此字段是否为同一个域名来判断请求是否合法,因为客户自己做的网页发起的请求,其Referer为黑客网站。

这种方法最简单,并且不需要修改业务代码,我们只需要对到达服务器的每个请求做一次拦截分析即可。

但是此方法的缺点也是明显的,因为Referer的值是浏览器的,虽然HTTP协议不允许去修改,但是如果浏览器自身存在漏洞,那么就有可能导致Referer被人工设置,不安全。

比如IE6,就可以通过方法篡改Referer值。

就算是最新的浏览器此方法也不是绝对可用的,这涉及了用户的隐私,很多用户会设置浏览器不提供Referer,因此服务器在得不到Referer的情况下不能贸然的决绝服务,有可能这是一个合法请求。

添加Token

CSRF攻击之所以能成功,是因为黑客完全伪造了一次用户的正常请求(这也是浏览器无法拦截的原因),并且cookie信息就是用户自己的,那么我们如果在请求中放入一些黑客无法去伪造的信息(不存在与cookie中),不就可以抵御了么!

比如在请求前生成一个token放到session中,当请求发生时,将token从session拿出来和请求提交过来的token进行对比,如果相等则认证通过,否则拒绝。token时刻在变化,黑客无法去伪造。

针对于不同类型的请求一般方案是

  • GET 放到url中,比如http://url?csrftoken=xxxx
  • POST 放到表单的隐藏域 <input type=”hidden” name=”csrftoken” value=”xxxx”/>

对于GET请求,这里有一点要说明,在一个网站中请求的url很多,一般情况我们是通过js对dom的所有节点进行遍历,发现a链接就在其href中增加token。

这里存在一个问题,比如黑客将自己网站的链接发到了要攻击页面,则黑客网站链接后面会有一个token,此刻客户可以通过编写自己网站代码得到这个token,然后用这个token立刻构造表单,发起CSRF攻击,因此在js遍历的时候,如果发现不是本站的链接,可以不加token。

在HTTP头部增加属性

这个方法在思路上和上面的token方式一样,只不过将token放到了HTTP头部中,不再参数传递,通过XMLHttpRequest类可以一次性的给所有请求加上csrftoken这个HTTP头属性并设置值。

这种方法适合上面批量添加token不方便的情况,一次性操作,不过局限性也比较大,XMLHttpRequest请求通常用在ajax方法中,并非所有请求都适合。

Yii2

首先要说的是每种CSRF防范措施都有其弊端,无论你的防范多么严密,黑客拥有更多的攻击手段,因此在重要逻辑上(必须写入和删除)必须非常小心,接下来我们把yii2框架在csrf上的部署说一下。

我们以yii2.0.14为解说版本。

在CSRF这块,yii2框架采取了HTTP头部和参数token并行的方式,针对于每个请求,在beforeAction都会做一次判断,如下

// vendor/yiisoft/yii2/web/Controller.php
public function beforeAction($action) {
    
    if (parent::beforeAction($action)) {
        if ($this->enableCsrfValidation && Yii::$app->getErrorHandler()->exception === null && !Yii::$app->getRequest()->validateCsrfToken()) {
            throw new BadRequestHttpException(Yii::t('yii', 'Unable to verify your data submission.'));
        }

        return true;
    }

    return false;
}

如果我们没有设置 enableCsrfValidation 为false,并且没有报错,则会进行csrf验证,核心方法就是

Yii::$app->getRequest()->validateCsrfToken()

该方法存在于 vendor/yiisoft/yii2/web/Request.php 中,我们看一看它。

public function validateCsrfToken($clientSuppliedToken = null) {
	// 省略上面代码
    return $this->validateCsrfTokenInternal($this->getBodyParam($this->csrfParam), $trueToken)
        || $this->validateCsrfTokenInternal($this->getCsrfTokenFromHeader(), $trueToken);
}

validateCsrfToken函数代码我们只需要看最后的返回,getBodyParam或getCsrfTokenFromHeader方法得到的token,只要有一种验证通过,就认为合法。

以上是整体的思路,为了让你看的更清晰,我画一个图并增加一些名词解释。

tu.png

以上是yii2的csrf策略部署,当然我还是推荐你使用 xdebug等调试工具 一步一步看看这个过程。

最后我在把上图的关键函数进行说明

  • generateCsrfToken() 该函数生成token并存到cookie或session中,该值不会随页面刷新而变化,它更多充当钥匙的作用,根绝它生成具体的csrfToken。
  • getCsrfToken() 生成具体的csrfToken,就是你在表单隐藏域中看到的那个值,这个值将来会传到服务器和真实的csrfToken进行对比,验证是否合法。
  • validateCsrfToken() 进行合法性验证,该函数得到一个真实的csrfToken然后和客户端上传来的csrfToken进行对比。

小结

本来想来个很高逼格的小结,想想算了,华丽的词汇不如下一篇靠谱的干货实在,等我下一篇哈。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏FreeBuf

Kali Linux渗透基础知识整理(四):维持访问

*本文原创作者:sysorem 维持访问 在获得了目标系统的访问权之后,攻击者需要进一步维持这一访问权限。使用木马程序、后门程序和rootkit来达到这一目的。...

3238
来自专栏企鹅号快讯

黑客花无涯:Linux 入侵常用命令

请点击此处输入图片描述 写个php一句话后门上去: [jobcruit@wa64-054 rankup_log]$ echo -e "" >rankuplog_...

3096
来自专栏FreeBuf

看我如何在渗透测试过程中发现并利用Serv-U漏洞进行操作系统提权

最近,我在做一个外网渗透测试的过程中,发现了SolarWinds文件共享程序Serv-U的一个漏洞,通过该漏洞我获得了Serv-U的管理权限,并能以系统用户身份...

2526
来自专栏FreeBuf

安全运维之如何找到隐匿于last和w命令中的ssh登录痕迹

*本文原创作者:ForrestX386,本文属FreeBuf原创奖励计划,未经许可禁止转载

1102
来自专栏Python中文社区

记一次惊心的网站TCP队列问题排查经历

作者:刘晓明,互联网公司运维技术负责人,拥有10年的互联网开发和运维经验。一直致力于运维工具的开发和运维专家服务的推进,赋能开发,提高效能。

1604
来自专栏信安之路

渗透测试信息收集工具篇

如果知道目标的域名,你首先要做的就是通过 Whois 数据库查询域名的注册信息,Whois 数据库是提供域名的注册人信息,包括联系方式,管理员名字,管理员邮箱等...

4260
来自专栏散尽浮华

Linux下开源邮件系统Postfix+Extmail+Extman环境部署记录

一、基础知识梳理 MUA (Mail User Agent)  MUA 既是"邮件使用者代理人",因为除非你可以直接利用类似 telnet 之类的软件登入邮件主...

4624
来自专栏IT技术精选文摘

Presto内存调优及原理(基础篇)

Presto是一个开源的分布式SQL查询引擎,适用于交互式分析查询,数据量支持GB到PB字节。Presto支持在线数据查询,包括Hive, Cassandra,...

1535
来自专栏同步博客

会话劫持

  在现实生活中,比如你去市场买菜,在交完钱后你要求先去干一些别的事情,稍候再来拿菜;如果这个时候某个陌生人要求把菜拿走,卖菜的人会把菜给陌生人吗?!当然,这只...

1083
来自专栏区块链

我们不一样的黑客渗透教程第三课,CVE20177269实战测试

很多人想学黑客知识,却不知如何入门,网上的教程也太繁琐,小白看了也头疼,那还是我来写黑客系列入门教程吧,跟着我做,你能黑客入门的。我已经写了两篇了,第1篇在 《...

3356

扫码关注云+社区

领取腾讯云代金券