前言
Xray一直是我的心头爱，为了更好的与这些优秀的安全工具打交道，于是我也尝试对其进行一些工作上的记录,提供一些目前仍然无法扫出的通用问题
对于Web侧扫描，应用层的核心过程是Http发包行为，这一部分会直接影响到漏扫的效率，很多的开源漏扫设计中都是通过主动扫描，做大规模爬虫后采取接口，硬怼poc包进行测试，实际在日常任务或者SRC中除了捡漏，用处并不是很大。列举一个常见场景，登陆后进行上传文件操作，反爬虫策略会大大限制这些主动扫描的行为。Xray支持主动与被动扫描，本地开放一个代理端口后便可以开始点哪打哪的操作
日常扫描
这一次扫描的资产数量不多，所以我直接放出结果吧，在我筛选去重后扫出来690条结果，大概翻了翻，比较常见的内置插件admin/default,baseline/sensitive/server-error等，Poc-yaml并不多
dirscan
dirscan应该是插件最多的一个配置选项，之前做src扫描，经常出来一些看不懂的插件…..
导致dirscan结果过多主要是admin/default，sourcemap/default插件，这一个问题是很多企业都采用单点登录也就是SSO，在没有认证的情况下，访问主域下的任意子域都会进行多次302跳转至SSO认证页面。所以xray在访问的时候只要是带有默认登录特征的页面都会直接返回admin/default，其余比如tomcat登陆页或者wordpress登录页则不一样，但是在扫描中我们更想要关注一下未接入单点登录的域名，所以这一部分的优化可以通过脚本实现。
admin/default优化
特征判断:对admin/default的结果进行重新发包，将关键字，或者返回包长度length，亦或者是对30x多次跳转次数做一个阙值。这里我访问一个登陆页后经历了3次302跳转才进入到到SSO认证
页面规则可以这样写，也可以直接果断点，requests直接设置allow_redirects=False
”SSO统一认证字符特征“ in response.text or response.length == “sso页面固定返回包长度” or response.status == 302
最后打上标签，获得未接入SSO的域名即可，这一部分登陆页是可以继续二次扫描爆破的
但是后面发现官方在Http的配置中更新了一条配置，或者在这里设置条转阙值也可以
sourcemap/default是js.map泄露，实际价值不是很大，dirscan/directory/default是目录遍历，sensitive/crossdomain也价值不大。
有一个可以注意的点，/temp/default,Mac下的文件夹会生成一个隐藏文件.DS_Store,这个文件会展示目录结构，可能会有点风险
exp工具：https://github.com/lijiejie/ds_store_exp
量大是因为Xray没有做对应去重工作，比如 http://和https://,https://url/admin和https://url/admin/,都会被分开上报。
xss
reflect，误报率低，扫了一堆反射xss，貌似大多src都不会接受这个，所以我也是直接对这个模块打上N标签
baseline
主要是sensitive/server-error出现一些error页面，翻了大概五十条左右看，暂时没有发现有实际利用的价值，所以也对这个插件打上标签N，有小伙伴发现有不同之处的请艾特我
brute-force
模块brute-force/from-brute.误报小王子，每次都会有那么几个，但是不敢关，没准哪次就出来了呢
Poc_yaml
资产量不够，无法统计实际效率，这里的poc扫描都是正常漏洞，后面找个机会汇集一下
未能扫描到的补充点
各类oss对象存储服务
基础参考：https://cloudsec.huoxian.cn/docs/articles
产品简介（以阿里云oss为例）：https://www.alibabacloud.com/help/zh/object-storage-service/latest/what-is-oss，简单理解成放数据的仓库就可以了。endpoint会以oss-cn-地区.aliyuncs.com结尾
创建完成后直接访问，显示不属于我，并且无法列出对应存储对象，但是允许访问bucket下的具体文件
但是在实际开发中，为了方便各个开发的使用，会将bucket权限放开，也就是在授权策略处进行更改
再次访问bucket桶后发现，已经可以直接列出对应key了，并且操作权限足够大，所以我们可以尝试往上增加文件,同样的，这里就会存在一个任意文件读取，上传，甚至是直接替换各类引用数据。
实际测试中更多的策略是在自定义中，我测试发现的大部分oss都是在ua，referer中作出对应的限制，绕过限制的小手法就是将测试目标的各类子域名在referer中进行不断爆破。
最后在补充一个测试点，报送给src后修复后，仍然可以通过搜索引擎的网页快照，数据缓存进行批量访问，一鱼三吃了属于是。
而这一部分如何实现也是一个问题，如果对大量的前端页面进行扫描的话，资源消耗会上个等级，在github翻到一个现成检测工具
https://github.com/UzJu/Cloud-Bucket-Leak-Detection-Tools,但是这只能作为自查脚本，需要配置AK/SK后才能实现
所以我尝试用Go写一个
TypeScript前端插件
这里案例不够，不知道能不能通用，我先记一下很久之前的测试项，一个grafana应用，在console处访问setting.datasource.*后，会出现当前使用的插件的一些敏感信息。但是挂着xray没有反馈出来。我猜是因为超过了单个最大的响应请求，默认2M
涉及到的插件大多是不被关注的前端插件，即插即用的那种，GitHub可以探索一下
文件上传
场景1:大量垃圾数据进行文件上传操作,只要越过waf检测时间就可以上传webshell，这一部分Xray只做了常规探测，如果能把这个加入就好了
场景2:如果能对应不同waf发不同的包，比如社区版的某些WAF会默认静态文件安全，尝试利用解析特性配合上传，再有一些WAF默认开启最长检测时间，那可就太棒了。
主动更换请求方式
这个再记一下，现在的案例还是不够
最后
反馈给了长亭的师傅，希望社区越来越好！
