技术分享07 - CSRF攻击

发表于 更新于 分类于 阅读次数：
本文字数： 3.5k 阅读时长 ≈ 3 分钟
CSRF（Cross-site request forgery，跨站请求伪造）是一种利用网站可信用户的权限去执行未授权的命令的一种恶意攻击。本文较为详细地解释了何为 CSRF，有何危害，如何防范 CSRF 攻击。

CSRF（Cross-site request forgery，中文为跨站请求伪造）是一种利用网站可信用户的权限去执行未授权的命令的一种恶意攻击。通过伪装可信用户的请求来利用信任该用户的网站，这种攻击方式虽然不是很流行，但是却难以防范，其危害也不比其他安全漏洞小。

CSRF也称作one-click attack或者session riding，其简写有时候也会使用XSRF。

什么是CSRF？

简单点说，CSRF攻击就是 攻击者利用受害者的身份，以受害者的名义发送恶意请求。

与XSS（Cross-site scripting，跨站脚本攻击）不同的是，XSS的目的是获取用户的身份信息，攻击者窃取到的是用户的身份（session/cookie），而CSRF则是利用用户当前的身份去做一些未经过授权的操作。

CSRF攻击最早在2001年被发现，由于它的请求是从用户的IP地址发起的，因此在服务器上的web日志中可能无法检测到是否受到了CSRF攻击，正是由于它的这种隐蔽性，很长时间以来都没有被公开的报告出来，直到2007年才真正的被人们所重视。

CSRF有哪些危害

CSRF可以盗用受害者的身份，完成受害者在web浏览器有权限进行的任何操作，想想吧，能做的事情太多了。

  • 以你的名义发送诈骗邮件，消息
  • 用你的账号购买商品
  • 用你的名义完成虚拟货币转账
  • 泄露个人隐私
  • …

产生原理以及利用方式

要完成一个CSRF攻击，必须具备以下几个条件：

  • 受害者已经登录到了目标网站（你的网站）并且没有退出
  • 受害者有意或者无意的访问了攻击者发布的页面或者链接地址

整个步骤大致是这个样子的：

  1. 用户小明在你的网站A上面登录了，A返回了一个session ID（使用cookie存储）
  2. 小明的浏览器保持着在A网站的登录状态，事实上几乎所有的网站都是这样做的，一般至少是用户关闭浏览器之前用户的会话是不会结束的
  3. 攻击者小强给小明发送了一个链接地址，小明打开了这个地址，查看了网页的内容
  4. 小明在打开这个地址的时候，这个页面已经自动的对网站A发送了一个请求，这时候因为A网站没有退出，因此只要请求的地址是A的就会携带A的cookie信息，也就是使用A与小明之间的会话
  5. 这时候A网站肯定是不知道这个请求其实是小强伪造的网页上发送的，而是误以为小明就是要这样操作，这样小强就可以随意的更改小明在A上的信息，以小明的身份在A网站上进行操作

利用方式

利用CSRF攻击，主要包含两种方式，一种是基于GET请求方式的利用，另一种是基于POST请求方式的利用。

GET请求利用

使用GET请求方式的利用是最简单的一种利用方式，其隐患的来源主要是由于在开发系统的时候没有按照HTTP动词的正确使用方式来使用造成的。对于GET请求来说，它所发起的请求应该是只读的，不允许对网站的任何内容进行修改。

但是事实上并不是如此，很多网站在开发的时候，研发人员错误的认为GET/POST的使用区别仅仅是在于发送请求的数据是在Body中还是在请求地址中，以及请求内容的大小不同。对于一些危险的操作比如删除文章，用户授权等允许使用GET方式发送请求，在请求参数中加上文章或者用户的ID，这样就造成了只要请求地址被调用，数据就会产生修改。

现在假设攻击者（用户ID=121）想将自己的身份添加为网站的管理员，他在网站A上面发了一个帖子，里面包含一张图片，其地址为http://a.com/user/grant_super_user/121

<img src="http://a.com/user/grant_super_user/121" />

设想管理员看到这个帖子的时候，这个图片肯定会自动加载显示的。于是在管理员不知情的情况下，一个赋予用户管理员权限的操作已经悄悄的以他的身份执行了。这时候攻击者121就获取到了网站的管理员权限。

POST请求利用

相对于GET方式的利用，POST方式的利用更加复杂一些，难度也大了一些。攻击者需要伪造一个能够自动提交的表单来发送POST请求。

<script>

$(function() {

    $('#CSRF_forCSRFm').trigger('submit');

});

</script>

<form action="http://a.com/user/grant_super_user" id="CSRF_form" method="post">

    <input name="uid" value="121" type="hidden">

</form>

只要想办法实现用户访问的时候自动提交表单就可以了。

防范原理

防范CSRF攻击，其实本质就是要求网站能够识别出哪些请求是非正常用户主动发起的。这就要求我们在请求中嵌入一些额外的授权数据，让网站服务器能够区分出这些未授权的请求，比如说在请求参数中添加一个字段，这个字段的值从登录用户的Cookie或者页面中获取的（这个字段的值必须对每个用户来说是随机的，不能有规律可循）。攻击者伪造请求的时候是无法获取页面中与登录用户有关的一个随机值或者用户当前cookie中的内容的，因此就可以避免这种攻击。

防范技术

Synchronizer token pattern

**令牌同步模式（Synchronizer token pattern，简称STP）**是在用户请求的页面中的所有表单中嵌入一个token，在服务端验证这个token的技术。token可以是任意的内容，但是一定要保证无法被攻击者猜测到或者查询到。攻击者在请求中无法使用正确的token，因此可以判断出未授权的请求。

简单实现STP：

首先在index.php中，创建一个表单，在表单中，我们将session中存储的token放入到隐藏域，这样，表单提交的时候token会随表单一起提交

<?php

    $token = sha1(uniqid(rand(), true));

    $_SESSION['token'] = $token;

?>

<form action="buy.php" method="post">

    <input type="hidden" name="token" value="<?=$token; ?>" />

    ... 表单内容

</form>

在服务端校验请求参数的buy.php中，对表单提交过来的token与session中存储的token进行比对，如果一致说明token是有效的

if ($_POST['token'] != $_SESSION['token']) {

    // TOKEN无效

    throw new \Exception('Token无效，请求为伪造请求');

}

// TOKEN有效，表单内容处理

对于攻击者来说，在伪造请求的时候是无法获取到用户页面中的这个token值的，因此就可以识别出其创建的伪造请求。

对于使用Js作为主要交互技术的网站，将CSRF的token写入到cookie中

Set-Cookie: CSRF-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; expires=Thu, 23-Jul-2015 10:25:33 GMT; Max-Age=31449600; Path=/

然后使用javascript读取token的值，在发送http请求的时候将其作为请求的header

X-CSRF-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql

最后服务器验证请求头中的token是否合法。

验证码

使用验证码可以杜绝CSRF攻击，但是这种方式要求每个请求都输入一个验证码，显然没有哪个网站愿意使用这种粗暴的方式，用户体验太差，用户会疯掉的。