[转]浅谈CSRF攻击方式

简介:

在CSDN中看到对CSRF攻击的原理及防护文章,讲解浅显易懂,特转之:

来源:http://blog.csdn.net/fationyyk/article/details/50833620

 

一.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方式方法很多样,但总的思想都是一致的,就是在客户端页面增加伪随机数。

 <?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).服务端核对令牌:

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

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

 

 

-------------------

资料结语:

1、对于.net WebForm中防御CSRF攻击是较麻烦的,具体的解决方法可以查看:保护ASP.NET 应用免受 CSRF 攻击

2、如果是.net MVC项目,防止CSRF攻击是非常容易的事,因为在Html帮助类有就提供了:<%=Html.AntiForgeryToken() %>,具体可以查看:【MVC整理】4.Asp.net MVC 如何防止CSRF攻击

 

 

>>小广告: 八爪鱼招标网 大家多给意见哦

转载请注明出处[ http://samlin.cnblogs.com/] 
作者赞赏
 


刚做的招标网: 八爪鱼招标网 请大家多意见
标签:  安全

本文转自Sam Lin博客博客园博客,原文链接:http://www.cnblogs.com/samlin/p/5849534.html,如需转载请自行联系原作者
目录
相关文章
|
5月前
|
JavaScript 安全 前端开发
js开发:请解释什么是XSS攻击和CSRF攻击,并说明如何防范这些攻击。
XSS和CSRF是两种常见的Web安全威胁。XSS攻击通过注入恶意脚本盗取用户信息或控制账户,防范措施包括输入验证、内容编码、HTTPOnly Cookie和CSP。CSRF攻击则诱使用户执行未经授权操作,防范手段有CSRF Tokens、双重验证、Referer检查和SameSite Cookie属性。开发者应采取这些防御措施并定期进行安全审计以增强应用安全性。
111 0
|
11月前
|
安全 NoSQL Java
互联网并发与安全系列教程(06) - 常见的Web安全漏洞(CSRF攻击)
互联网并发与安全系列教程(06) - 常见的Web安全漏洞(CSRF攻击)
117 0
|
SQL 安全 前端开发
渗透攻击实例-邪恶的CSRF(社会工程学)
渗透攻击实例-邪恶的CSRF(社会工程学)
|
5月前
|
缓存 安全 JavaScript
前端安全:Vue应用中防范XSS和CSRF攻击
【4月更文挑战第23天】本文探讨了在Vue应用中防范XSS和CSRF攻击的重要性。XSS攻击通过注入恶意脚本威胁用户数据,而CSRF则利用用户身份发起非授权请求。防范措施包括:对输入内容转义、使用CSP、选择安全的库;采用Anti-CSRF令牌、同源策略和POST请求对抗CSRF;并实施代码审查、更新依赖及教育团队成员。通过这些实践,可提升Vue应用的安全性,抵御潜在攻击。
896 0
|
3月前
|
SQL 安全 数据库
Python Web开发者必学:SQL注入、XSS、CSRF攻击与防御实战演练!
【7月更文挑战第26天】在 Python Web 开发中, 安全性至关重要。本文聚焦 SQL 注入、XSS 和 CSRF 这三大安全威胁,提供实战防御策略。SQL 注入可通过参数化查询和 ORM 框架来防范;XSS 则需 HTML 转义用户输入与实施 CSP;CSRF 防御依赖 CSRF 令牌和双重提交 Cookie。掌握这些技巧,能有效加固 Web 应用的安全防线。安全是持续的过程,需贯穿开发始终。
80 1
Python Web开发者必学:SQL注入、XSS、CSRF攻击与防御实战演练!
|
2月前
|
Web App开发 存储 安全
就一次!带你彻底搞懂CSRF攻击与防御
与XSS攻击相比,利用CSRF漏洞发动攻击会比较困难,这也是在网络上看起来CSRF的人气小于XSS的原因之一。下面我们来利用CSRF漏洞发起攻击,并针对攻击进行防御,彻底弄懂CSRF,话不多说,我们直接开冲。
|
3月前
|
运维 安全 Java
什么是 CSRF?如何防止 CSRF 攻击?
CSRF 攻击是一种常见且危险的 Web 安全漏洞,攻击者可以通过伪造用户请求,执行恶意操作,作为程序员,为了防御 CSRF 攻击,常见的策略包括使用 CSRF Token、检查 Referer 或 Origin 头、设置 SameSite Cookie 属性以及双重提交 Cookie。 因为程序员对于 CSRF 攻击可以做的事情还是很有限,所以,承担主要责任的是安全部门或者运维部门,但是作为程序员,我们需要具备这些安全意识,在安全等级比较高的需求中也需要把这些安全因素考虑在内。
|
4月前
|
前端开发 安全 JavaScript
XSS和CSRF攻击概览
【6月更文挑战第27天】**XSS和CSRF攻击概览** - XSS:利用未验证用户输入的Web应用,注入恶意脚本到浏览器,盗取信息或控制用户账户。防御措施包括输入验证、内容编码、HttpOnly Cookie和CSP。 - CSRF:攻击者诱使用户执行非授权操作,利用现有会话。防御涉及CSRF Tokens、双重验证、Referer检查和SameSite Cookie属性。 应用这些策略可提升Web安全,定期审计和测试同样重要。
48 3
|
3月前
|
前端开发 安全 JavaScript
CSRF 攻击是什么?如何防范?
CSRF 攻击是什么?如何防范?
175 0
|
5月前
|
存储 JavaScript 前端开发
Django的CSRF防攻击原理详解
Django的CSRF防攻击原理详解
118 3