浅谈 CSRF 攻击方式 | 珊瑚贝

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 攻击，受害者必须依次完成两个步骤：

　　1. 登录受信任网站 A，并在本地生成 Cookie。 2. 在不登出 A 的情况下，访问危险网站 B。

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

　　1. 你不能保证你登录了一个网站后，不再打开一个 tab 页面并访问另外的网站。 2. 你不能保证你关闭浏览器了后，你本地的 Cookie 立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录 / 结束会话了……） 3. 上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。

上面大概地讲了一下 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 中的以 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 种最为严重，因为触发条件很简单，一个就可以了，而第 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 中受影响。

原文链接

在网上发现这篇文章说得很明了，转载啦，非常感谢原作者的辛苦付出。原文出处

来源：https://cuiqingcai.com/2076.html

CSRF 是什么？

CSRF 可以做什么？

CSRF 漏洞现状

CSRF 的原理

示例 1：

示例 2：

示例 3：

CSRF 的防御

1. 服务端进行 CSRF 防御

2. 验证码

原文链接

猜你喜欢

　　示例 2：

　　示例 3：

　　1. 服务端进行 CSRF 防御