首页 > 代码库 > php web开发安全之csrf攻击的简单演示和防范(一)

php web开发安全之csrf攻击的简单演示和防范(一)

csrf攻击,即cross site request forgery跨站(域名)请求伪造,这里的forgery就是伪造的意思。网上有很多关于csrf的介绍,比如一位前辈的文章浅谈CSRF攻击方式,参考这篇文章简单解释下:csrf 攻击能够实现依赖于这样一个简单的事实:我们在用浏览器浏览网页时通常会打开好几个浏览器标签(或窗口),假如我们登录了一个站点A,站点A如果是通过cookie来跟踪用户的会话,那么在用户登录了站点A之后,站点A就会在用户的客户端设置cookie,假如站点A有一个页面siteA-page.php(url资源)被站点B知道了url地址,而这个页面的地址以某种方式被嵌入到了B站点的一个页面siteB-page.php中,如果这时用户在保持A站点会话的同时打开了B站点的siteB-page.php,那么只要siteB-page.php页面可以触发这个url地址(请求A站点的url资源)就实现了csrf攻击。

上面的解释很拗口,下面举个简单的例子来演示下。

1,背景和正常的请求流程

A站点域名为html5.yang.com,它有一个/get-update.php?uid=uid&username=username地址,可以看到这个地址可以通过get方法来传递一些参数,假如这个页面的逻辑是:它通过判断uid是否合法来更新username,这个页面脚本如下:

 

 1 <?php 2 // 这里简便起见, 从data.json中取出数据代替请求数据库 3 $str = file_get_contents(data.json); 4 $data = http://www.mamicode.com/json_decode($str, true); 5  6 // 检查cookie和请求更改的uid, 实际应检查数据库中的用户是否存在 7 empty($_COOKIE[uid]) ||empty($_GET[uid]) || $_GET[uid] != $data[id] ? die(非法用户) : ‘‘; 8 // 检查username参数 9 $data[username] = empty($_GET[username]) ? die(用户名不能为空) : $_GET[username];10 11 // 更新数据12 $data[username] = $_GET[username];13 if(file_put_contents(data.json, json_encode($data))) {14     echo "用户名已更改为{$data[‘username‘]}<br>";15 } else {16     die(更新失败);17 }

 

正常情况下这个页面的链接是放在站点A下面的,比如A站点的csrfdemo.php页面,用户登录站点A以后可以通过点击这个链接来发送请求,比如站点A有一个页面脚本,包含了这个链接:

 1 <?php 2 // 这里用一个data.json文件保存用户数据,模拟数据库中的数据 3 // 先初始化data.json中的数据为{"id":101,"username":"jack"}, 注意这句只让它执行一次, 然后把它注释掉 4 // file_put_contents(‘data.json‘,‘{"id":101,"username":"jack"}‘); 5  6 $data = http://www.mamicode.com/json_decode(file_get_contents(data.json), true); 7  8 // 这里为了简便, 省略了用户身份验证的过程 9 if ($data[username]) {10     // 设置cookie11     setcookie(uid, $data[id], 0);12     echo "登录成功, {$data[‘username‘]}<br>";13 }14 ?>15 16  <a href=http://www.mamicode.com/"http://html5.yang.com/csrfdemo/get-update.php?uid=101&username=json">17     更新用户名为json18  </a>

加载这个页面如下:

技术分享

用点击页面中的链接来到get-update.php页面:

技术分享

上面是正常的请求流程,下面来看B站点是如何实现csrf攻击的。

2,csrf攻击的最简单实现

B站点域名为test.yang.com,它有一个页面csrf.php,只要用户在维持A站点会话的同时打开了这个页面,那么B站点就可以实现csrf攻击。至于为什么会打开......,其实这种情景在我们浏览网页时是很常见的,比如我在写这篇博客时,写着写着感觉对csrf某个地方不懂,然后就百度了,结果百度出来好多结果,假如说有个网站叫csrf百科知识,这个网站对csrf介绍的非常详细、非常权威,那么我很可能会点进去看,但是这个网站其实是个钓鱼网站,它在某个访问频率很高的页面中嵌入了我博客编辑页面的url地址,那么它就可以实现对我博客的csrf攻击。好了,言归正传,下面来看下csrf.php脚本代码:

<?php?><img src=http://www.mamicode.com/"http://html5.yang.com/csrfdemo/get-update.php?uid=101&username=jsonp">

可以看到上面的代码没有php代码,只有一个img标签,img标签的src就是A站点的那个更新用户名的链接,只不过把username改为了jsonp,访问站点B的csrf.php这个页面:

技术分享

下面再来访问下A站点的csrfdemo.php页面:

技术分享

可以看到用户名被修改为了jsonp。

简单分析下:B站点的这个csrf.php利用了html中的img标签,我们都知道img标签有个src属性,属性值指向需要加载的图片地址,当页面载入时,加载图片就相当于向src指向的地址发起http请求,只要把图片的地址修改为某个脚本地址,这样自然就实现了最简单的csrf攻击。如此说来,其实csrf很容易实现,只不过大家都是“正人君子”,谁没事会闲着去做这种“下三滥”的事情。但是害人之心不可有,防人之心不可无。下面看下如何简单防范这种最简单的csrf攻击。

3,简单防范措施

其实防范措施也比较简单,A站点可以在get-update.php脚本中判断请求头的来源,如果来源不是A站点就可以截断请求,下面在get-update.php增加些代码: 

 1 <?php 2 // 检查上一页面是否为当前站点下的页面 3 if (!empty($_SERVER[HTTP_REFERER])) { 4     if (parse_url($_SERVER[HTTP_REFERER], PHP_URL_HOST) != html5.yang.com) { 5         // 可以设置http错误码或者指向一个无害的url地址 6         //header(‘HTTP/1.1 404 not found‘); 7         //header(‘HTTP/1.1 403 forbiden‘); 8         header(Location: http://html5.yang.com/favicon.ico); 9         // 这里需要注意一定要exit(), 否则脚本会接着执行10         exit();11     }12  }13 14 $str = file_get_contents(data.json);15 // 代码省略

但是,这样就万事大吉了吗,如果http请求头被伪造了呢?A站点升级了防御,B站点同时也可以升级攻击,通过curl请求来实现csrf,修改B站点的csrf.php代码如下:

<?php$url = http://html5.yang.com/csrfdemo/get-update.php?uid=101&username=jsonp;$refer = http://html5.yang.com/;// curl方法发起csrf攻击$ch = curl_init();curl_setopt($ch, CURLOPT_URL, $url);
// 设置Referercurl_setopt($ch, CURLOPT_REFERER, $refer);
// 这里需要携带上cookie, 因为A站点get-update.php对cooke进行了判断curl_setopt($ch, CURLOPT_COOKIE, uid=101);curl_exec($ch);curl_close($ch);?><img src=http://www.mamicode.com/"http://html5.yang.com/csrfdemo/get-update.php?uid=101&username=jsonp">

这样同样可以实现csrf攻击的目的。那么就没有比较好的防范方法了吗?

4,小结

下面我们回到问题的开始,站点A通过cookie来跟踪用户会话,在cookie中存放了重要的用户信息uid,get-update.php脚本通过判断用户的cookie正确与否来决定是否更改用户信息,看来靠cookie来跟踪会话并控制业务逻辑是不太安全的,还有最严重的一点:get-update.php通过get请求来修改用户信息,这个是大忌。所以站点A可以接着升级防御:用session来代替cookie来跟踪用户会话信息,将修改用户信息的逻辑重写,只允许用post方法来请求用户信息。站点B同样可以升级攻击:curl可以构造post请求,劫持session等等,不过这些我还没研究过,后续再说吧。

php web开发安全之csrf攻击的简单演示和防范(一)