CSRF攻击案例分析报告

：日志宝网站的宣传性文章，大家可以参考技术内容

近日，某站长在使用日志宝分析日志时发现，一些可疑IP地址会定期对网站第三方接口产生大量访问，影响了网站正常业务的运行。安全团队在与该站长进行沟通后判定这是一次典型的CSRF攻击。
 
针对此次攻击事件，日志宝安全团队发布了《CSRF攻击案例分析报告》：
 
事件背景：
 
1、 站长在使用日志宝进行日常分析时发现，该IP地址在top20统计中的访问量明显高于第2位的IP地址访问量，并产生出大量异常访问
 
2、 该网站第三方接口主要功能是通过网络电话与用户取得联系，很多用户接到投诉，www.xuhantao.com，表示并没有使用过该接口，并且收到了大量的未知来电
 
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: “);
 
$a = file_get_contents(‘’);
 
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攻击可以依托于网站自身业务对正常用户发起钓鱼、欺诈等其他恶意行为，影响网站自身的正常业务运转，给网站带来极大的负面影响，站长们还需多多关注此类攻击行为。

• 没有相关文章