CSRF攻击案例分析报告:全方位分析网站安全

http://www.itjxue.com  2015-07-19 16:22  来源:未知  点击次数: 

从日志宝安全团队获悉,近日,某站长在使用日志宝分析日志时发现,一些可疑IP地址会定期对网站第三方接口产生大量访问,影响了网站正常业务的运行。日志宝安全团队在与该站长进行沟通后判定这是一次典型的CSRF攻击。

针对此次攻击事件,日志宝安全团队发布了《日志宝-CSRF攻击案例分析报告》:

事件背景:

1、 站长在使用日志宝进行日常分析时发现,该IP地址在top20统计中的访问量明显高于第2位的IP地址访问量,并产生出大量异常访问

2、 该网站第三方接口主要功能是通过网络电话与用户取得联系,很多用户接到投诉,表示并没有使用过该接口,并且收到了大量的未知来电

3、 在日志宝安全分析报告中发现大量敏感URL访问,并且访问源头与该ip地址吻合

针对以上问题,通过使用日志宝对网站日志进行安全分析后发现,日志文件中存在大量类似以下访问请求:

x.x.x.x - - [25/Aug/2012:00:18:05 +0800] "GET /manage/call.php?u=1234&sms=13812345678 HTTP/1.1" 200 3284

随后联系用户获得了该脚本的源代码,发现该脚本文件存在3处编程安全问题:

1、 该脚本文件没有对用户登录信息做权限验证,外界用户可无需登录直接访问该接口

2、 该脚本文件采用$_REQUEST获取参数,没有区分GET和POST两种方式,导致可以直接在URL中构造表单参数

3、 该脚本文件没有对用户身份做确认,结合XSS漏洞可以以任意用户身份发起访问请求,通过第三方网络电话接口给任意用户拨打骚扰电话,形成一次CSRF攻击。

针对这些问题,日志宝安全团队帮助用户提出了代码层面的修复方案:

1、 增加权限控制,在使用接口时必须验证用户是否为本站已登录用户。

2、 针对表单变量采用$_POST方式获取,禁止使用$_REQUEST获取表单变量。

3、 防御CSRF攻击(3种方法):

3.1 添加验证码,此方法会额外增加一次用户交互行为,在网站用户体验上会打折扣,影响接口的使用转化率。

3.2 判断接口访问来源(HTTP Referer),此方法通过判断网页的Referer来检测用户是否是通过正常调用访问该接口,但是由于Referer可以在客户端伪造,故并不能很好的防止CSRF攻击。

伪造Referer的代码如下:

<?php

header("Referer: www.rizhibao.com");

$a = file_get_contents('http://www.secrule.com');

echo $a;

?>

通过抓包可以看到referer已经被篡改:

3.3 添加一次性会话令牌(token),此方法不会增加额外的用户交互行为,并且能够有效的防止CSRF攻击。代码实现原理如下:

首先创建一个一次性的随机token值,并将token值存放在session中

$decsrf = md5(mt_rand(0,mt_getrandmax()).'this_a_very_strong_key');

$_SESSION['decsrf'] = $decsrf;

其次在前台POST表单中添加隐藏input元素,自动提交token值到后台验证页面

<input type="hidden" name="decsrf" value="<?=$descrf?>">

最后在后台验证页面判断该请求是否合法,检测用户传递过来的token值是否和seesion中保存的token值一致

if(empty($_POST['decsrf']) || $_POST['decsrf']!= $_SESSION['decsrf']){

$this->errmsg .= "<li>数据异常!</li>";

exit;

}else{

unset($_POST['decsrf']);//销毁一次性token令牌

正常处理逻辑

}

4、 增加时间限制,限制该接口的访问请求时间间隔,比如30秒内只能访问一次该接口,防止接口调用过于频繁消耗服务器资源。

日志宝已经协助用户成功处理了此次安全攻击事件。通过此次安全攻击事件可以看出,CSRF攻击的目标是网站的用户而不是网站服务器本身,虽然不同于SQL注入攻击可以直接获取网站的敏感数据,但是通过CSRF攻击可以依托于网站自身业务对正常用户发起钓鱼、欺诈等其他恶意行为,影响网站自身的正常业务运转,给网站带来极大的负面影响,站长们还需多多关注此类攻击行为。

注明:本安全报告来自日志宝,官方网站www.rizhibao.com。

(责任编辑:IT教学网)

更多