PHP开发中csrf攻击的简单演示和防范

<?php
// 这里简便起见, 从data.json中取出数据代替请求数据库
$str = file_get_contents('data.json');
$data = json_decode($str, true);

// 检查cookie和请求更改的uid, 实际应检查数据库中的用户是否存在
empty($_COOKIE['uid']) ||empty($_GET['uid']) || $_GET['uid'] != $data['id'] ? die('非法用户') : '';
// 检查username参数
$data['username'] = empty($_GET['username']) ? die('用户名不能为空') : $_GET['username'];

// 更新数据
$data['username'] = $_GET['username'];
if(file_put_contents('data.json', json_encode($data))) {
  echo "用户名已更改为{$data['username']}
";
} else {
  die('更新失败');
}

<?php
// 这里用一个data.json文件保存用户数据,模拟数据库中的数据
// 先初始化data.json中的数据为{"id":101,"username":"jack"}, 注意这句只让它执行一次, 然后把它注释掉
// file_put_contents('data.json','{"id":101,"username":"jack"}');

$data = json_decode(file_get_contents('data.json'), true);

// 这里为了简便, 省略了用户身份验证的过程
if ($data['username']) {
  // 设置cookie
  setcookie('uid', $data['id'], 0);
  echo "登录成功, {$data['username']}
";
}
?>

 
  更新用户名为json
 

<?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增加些代码： 

<?php
// 检查上一页面是否为当前站点下的页面
if (!empty($_SERVER['HTTP_REFERER'])) {
  if (parse_url($_SERVER['HTTP_REFERER'], PHP_URL_HOST) != 'html5.yang.com') {
    // 可以设置http错误码或者指向一个无害的url地址
    //header('HTTP/1.1 404 not found');
    //header('HTTP/1.1 403 forbiden');
    header('Location: http://html5.yang.com/favicon.ico');
    // 这里需要注意一定要exit(), 否则脚本会接着执行
    exit();
  }
 }

$str = file_get_contents('data.json');
// 代码省略


但是，这样就万事大吉了吗，如果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);
// 设置Referer
curl_setopt($ch, CURLOPT_REFERER, $refer);
// 这里需要携带上cookie, 因为A站点get-update.php对cooke进行了判断
curl_setopt($ch, CURLOPT_COOKIE, 'uid=101');
curl_exec($ch);
curl_close($ch);
?>


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