网络安全-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攻击是源于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(http://www.cnblogs.com/hyddd/)]