您的位置：首页 > 其它

浅谈CSRF攻击方式

2017-09-06 10:20 399 查看

重要申明：感谢原文作者——hyddd，想看原文请戳这里！我转载了原文，修改了一些原文行文不通畅之处，望请勿怪。挂在自己的博客下面一方面是为了收藏好文，方便自己温顾而知新；另一方面也希望更多人看到这文章。PS：原文撰写于 2009-04-09 22:44。

一、CSRF 是什么？

　　CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。

二、CSRF 可以做什么？

　　你这可以这么理解 CSRF 攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF 能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账……主要造成的问题包括：个人隐私泄露以及财产安全。

三、CSRF 漏洞现状

　　CSRF 这种攻击方式在 2000 年已经被国外的安全人员提出。但在国内，直到 06 年才开始被关注。08 年，国内外的多个大型社区和交互网站分别爆出 CSRF 漏洞，如：NYTimes.com（纽约时报）、Metafilter（一个大型的 BLOG 网站）、YouTube 和百度 HI……而现在，互联网上的许多站点仍对此毫无防备，以至于网络安全业界称 CSRF 为“沉睡的巨人”。

四、CSRF 的原理

下图简单阐述了 CSRF 攻击的思想：

从上图可以看出，要完成一次 CSRF 攻击，受害者必须依次完成两个步骤：

登录受信任网站 A，并在本地生成 Cookie ；

在不登出 A 的情况下，访问危险网站 B 。

看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到 CSRF 的攻击”。是的，确实如此，但你不能保证以下情况不会发生：

你不能保证你登录了一个网站后，不再打开一个 tab 页面并访问另外的网站。

你不能保证你关闭浏览器了后，你本地的 Cookie 立刻过期，你上次的会话已经结束（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了……）。

上图中所谓的攻击网站，也可能是一个存在其他漏洞的可信任的经常被人访问的网站。

上面大概地讲了一下 CSRF 攻击的思想，下面我将用几个例子详细说说具体的 CSRF 攻击，这里我以一个银行转账的操作作为例子（仅仅是例子，真实的银行网站没这么傻 :> ）：

示例1：

银行网站 A，它以 GET 请求来完成银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000

危险网站 B，它里面有一段 HTML 的代码如下：

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

首先，你登录了银行网站 A ，然后访问危险网站 B ，噢，这时你会发现你的银行账户少了 1000 块……

为什么会这样呢？原因是银行网站 A 违反了 HTTP 规范，使用 GET 请求更新资源。在访问危险网站 B 的之前，你已经登录了银行网站 A ，而 B 中的

<img>

以 GET 的方式请求第三方资源（这里的第三方就是指银行网站了，原本这是一个合法的请求，但这里被不法分子利用了），所以你的浏览器会带上你的银行网站 A 的 Cookie 发出 GET 请求，去获取资源 http://www.mybank.com/Transfer.php?toBankId=11&money=1000 。结果银行网站服务器收到请求后，认为这是一个更新资源操作（转账操作），所以就立刻进行转账操作……

示例2：

为了杜绝上面的问题，银行决定改用 POST 请求完成转账操作。

银行网站 A 的 WEB 表单如下：　　

<form action="Transfer.php" method="POST">
<p>ToBankId: <input type="text" name="toBankId" /></p>
<p>Money: <input type="text" name="money" /></p>
<p><input type="submit" value="Transfer" /></p>
</form>

后台处理页面 Transfer.php 如下：

<?php
session_start();
if (isset($_REQUEST['toBankId'] &&　isset($_REQUEST['money'])){
buy_stocks($_REQUEST['toBankId'],　$_REQUEST['money']);
}
?>

危险网站 B ，仍然只是包含那句 HTML 代码：

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

　　

和示例 1 中的操作一样，你首先登录了银行网站 A ，然后访问危险网站 B ，结果……和示例 1 一样，你再次没了 1000 块～T_T。这次事故的原因是：银行后台使用了

$_REQUEST

去获取请求的数据，而

$_REQUEST

既可以获取 GET 请求的数据，也可以获取 POST 请求的数据，这就造成了在后台处理程序无法区分这到底是 GET 请求的数据，还是 POST 请求的数据。在 PHP 中，可以使用

$_GET

和

$_POST

分别获取 GET 请求和 POST 请求的数据。在 JAVA 中，用于获取请求数据的 request ，一样存在不能区分 GET 请求数据和 POST 数据的问题。

示例3：

经过前面 2 个惨痛的教训，银行决定把获取请求数据的方法也改了，改用

$_POST

，只获取 POST 请求的数据，后台处理页面 Transfer.php 代码如下：

<?php
session_start();
if (isset($_POST['toBankId'] &&　isset($_POST['money'])){
buy_stocks($_POST['toBankId'],　$_POST['money']);
}
?>

然而，危险网站 B 与时俱进，它改了一下代码：

<html>
<head>
<script type="text/javascript">
function steal(){
iframe = document.frames["steal"];
iframe.document.Submit("transfer");
}
</script>
</head>
<body onload="steal()">
<iframe name="steal" display="none">
<form method="POST" name="transfer"　action="http://www.myBank.com/Transfer.php">
<input type="hidden" name="toBankId" value="11">
<input type="hidden" name="money" value="1000">
</form>
</iframe>
</body>
</html>

如果用户仍是继续上面的操作，很不幸，结果将会是再次不见 1000 块……因为这里危险网站 B 暗地里发送了 POST 请求到银行!

总结一下上面 3 个例子，CSRF 主要的攻击模式基本上是以上的 3 种。其中以第 1,2 种最为严重，因为触发条件很简单，一个

<img>

就可以了，而第 3 种比较麻烦，需要使用 JavaScript ，所以使用的机会会比前面的少很多，但无论是哪种情况，只要触发了 CSRF 攻击，后果都有可能很严重。

理解上面的 3 种攻击模式，其实可以看出，CSRF 攻击是源于 WEB 的隐式身份验证机制！WEB 的身份验证机制，虽然可以保证一个请求是来自于某个用户的浏览器，但却无法保证该请求是用户批准发送的！

五、CSRF 的防御

　　我总结了一下看到的资料，CSRF 的防御可以从服务端和客户端两方面着手，防御效果是从服务端着手效果比较好，现在一般的 CSRF 防御也都在服务端进行。

1、服务端进行 CSRF 防御

服务端的防御 CSRF 的方式有很多，但总的思想都是一致的，就是在客户端页面增加伪随机数。

1. Cookie Hashing (所有表单都包含同一个伪随机值)：

这可能是最简单的解决方案了，因为攻击者不能获得第三方的 Cookie(理论上) ，所以表单中的数据也就构造失败了:

<?php
// 构造加密的 Cookie 信息
$value = “DefenseSCRF”;
setcookie(”cookie”, $value, time()+3600);
?>

在表单里增加 Hash 值，以认证这确实是用户发送的请求。

<?php
$hash = md5($_COOKIE['cookie']);
?>
<form method=”POST” action=”transfer.php”>
<input type=”text” name=”toBankId”>
<input type=”text” name=”money”>
<input type=”hidden” name=”hash” value=”<?=$hash;?>”>
<input type=”submit” name=”submit” value=”Submit”>
</form>

然后在服务器端进行 Hash 值验证：

<?php
if(isset($_POST['check'])) {
$hash = md5($_COOKIE['cookie']);
if($_POST['check'] == $hash) {
doJob();
} else {
//...
}
} else {
//...
}
?>

这个方法个人觉得已经可以杜绝 99% 的 CSRF 攻击了，那还有 1% 呢……由于用户的 Cookie 很容易由于网站的 XSS 漏洞而被盗取，这就是另外的 1% 了。一般的攻击者看到需要算 Hash 值，基本都会放弃了，某些除外。所以如果需要 100% 的杜绝，这个不是最好的方法。

2. 验证码

这个方案的思路是：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串。这个方案可以完全解决 CSRF ，但个人觉得在易用性方面似乎不是太好。另外，听闻验证码图片的使用涉及了一个被称为 MHTML 的 Bug ，可能在某些版本的 IE 中会受影响。

3. One-Time Tokens (不同的表单包含一个不同的伪随机值)

在实现 One-Time Tokens 时，需要注意一点：就是“并行会话的兼容”。如果用户在一个站点上，同时打开两个不同的表单，CSRF 保护措施不应该影响到它对任何表单的提交。这是因为如果每次表单被装入时，站点都会生成一个伪随机值来覆盖以前的伪随机值，这时用户就只能成功地提交它最后打开的表单。因为所有其他的表单都含有非法的伪随机值。故而，必须小心实现以确保 CSRF 保护措施不会影响选项卡式的浏览器或者利用多个浏览器窗口浏览一个站点的情况。

以下我的实现:

1. 先是令牌生成函数（ gen_token() ）：

<?php
function gen_token() {
//这里我是贪方便，实际上单使用Rand()得出的随机数作为令牌，也是不安全的。
//这个可以参考我写的Findbugs笔记中的《Random object created and used only once》
$token = md5(uniqid(rand(), true));
return $token;
}
?>

2. 然后是 Session 令牌生成函数（ gen_stoken() ）：

<?php
function gen_stoken() {
$pToken = "";
if($_SESSION[STOKEN_NAME]  == $pToken){
//没有值，赋新值
$_SESSION[STOKEN_NAME] = gen_token();
} else {
//继续使用旧的值
}
}
?>

3. WEB 表单生成隐藏输入域的函数：

<?php
function gen_input() {
gen_stoken();
echo “<input type=\”hidden\” name=\”" . FTOKEN_NAME . “\” value=\”" . $_SESSION[STOKEN_NAME] . “\”> “;
}
?>

4. WEB 表单结构：

<?php
session_start();
include(”functions.php”);
?>

<form method=”POST” action=”transfer.php”>
<input type=”text” name=”toBankId”>
<input type=”text” name=”money”>
<? gen_input(); ?>
<input type=”submit” name=”submit” value=”Submit”>
</form>

5. 服务端核对令牌：

这个很简单，这里就不再啰嗦了。

上面这个其实不完全符合“并行会话的兼容”的规则，大家可以在此基础上修改。

其实还有很多想写，无奈精力有限，暂且打住，日后补充，如果错漏，请指出:>

PS：今天下午写这篇文档的时候 FF 崩溃了一次，写了一半文章的全没了，郁闷好久T_T……

转载请说明出处——hyddd，谢谢~

六、参考文献

Preventing CSRF

Security Corner: Cross-Site Request Forgeries

《深入解析跨站请求伪造漏洞：原理剖析》

《Web安全测试之跨站请求伪造（CSRF）》

《深入解析跨站请求伪造漏洞：实例讲解》

百度百科——CSRF

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签： csrf csrf原理 csrf防御服务端开发验证码

相关文章推荐

新的分享

章节导航