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

　　从日志宝安全团队获悉，近日，某站长在使用日志宝分析日志时发现，一些可疑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值到后台验证页面

　　最后在后台验证页面判断该请求是否合法，检测用户传递过来的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攻击可以依托于网站自身业务对正常用户发起钓鱼、欺诈等其他恶意行为，影响网站自身的正常业务运转，给网站带来极大的负面影响，站长们还需多多关注此类攻击行为。

在线留言