网站安全分析：CSRF攻击案例分析报告

站长之家（chinaz.com）8月28日消息：站长之家从日志宝安全团队获悉，近日，某站长在使用日志宝分析日志时发现，一些可疑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。