看了那么多漏洞挖掘文章为什么还是挖不到漏洞？其实大多数的漏洞挖掘文章可能只能算漏洞复现文章。在这种web环境下，我觉得难的不是怎么测一个漏洞点，而是怎么找一个漏洞点。本文从挖洞过程的思路出发，完整讲述如何从0到1拿一个高危信息泄露。
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
下面那个点不动，于是点击我的车辆，进入下一个页面，都点击了一下（正常测试思路肯定是尽量往高权限靠，但这里我才进入这个小程序，得先把内部结构搞清楚。）
对一个资产进行测试，第一步就是把所有能点的地方点了，将前端功能交互点转化为接口，转化为具体的数据包，再去一个个分析数据包。同时作为一名挖洞的白帽子，要永远保持对参数和参数值的敏感！
对小程序挖洞注意sessionkey的泄露，sessionkey可能会在登录时直接在请求包携带，所以对刚进入小程序那个数据包一定要抓住。或者是在返回包时携带，也可能是以加密的形式藏在token中。
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
几个页面都看了下，功能点基本一样。
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
这种页面比较难搞，因为你上传的东西是马上会有审核，有专人来看，所以测试文件上传不太好，简单分析后暂时跳过。
小程序功能大致搞清：就是一个可以让不同的用户提交材料，进行审核的地方。
在基础知识扎实的情况下，功能点多少决定攻击面大小。
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
在复制域名时习惯看了看数据包，也就是对url路径特征进行分析，发现了一个特殊的?s=接口，猜测此处为与后端交互功能点，目前看不出这种结构有什么规律，貌似直接FUZZ是不行的。
挖洞要记住一点：对现成接口的寻找利用的优先级大于FUZZ。
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
此处猜测先前没登录框，可能是微信进行了自动登录，那么在先前第一个小程序页面就可以测试越权，而且此处或许可以直接拿微信凭证进行登录。（剧透：第一个小程序页面的0513f其实是我的身份编号，后面会用到，但我在挖洞时是完全没注意到这点的，后面回来查看“犯罪现场”时才发现）
但我并没有立刻去测越权，或者利用凭证登录，个人习惯，在发现可能存在漏洞时我可能会先进行记录，然后继续靠感觉进一步摸索，等某种感觉来了，再去测那些可能存在漏洞的点。（这期间其实可以对系统更加熟悉，获取更多信息，这样更方便测试）
在登录框路径改为/api/，页面出现空白，再在api中间胡乱添加字母，依旧空白，于是知晓：只要是路径错误便展现空白页面。
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
如果是在路径/admin/后添加任何目录，页面便会直接跳转到原登录页面。猜测/admin/路径后可能都做了鉴权，或者/admin/为基础路径。
鉴权这个问题挖洞会经常遇到，所以建议自己去做好总结，尤其是对于主流Nday未授权漏洞的总结。
1：改请求方法
POST--PUT GET--OPTION等等
2：大小写替换绕过
/api/home/admin--/api/home/ADMIN
3：路径穿越：
/api/home/user---403
/api/MYPATH/../home/user---200
/api/home/..;/home/user---200 （这个主要用于shrio鉴权，或者采用了springboot鉴权）
4：通配符替换字符:
/api/user/6---403
/api/user/*---200
这个登录页面其实是有开发商的，（我没截出来）这里就也可以考虑搜索该开发商的历史漏洞。
是一种思路，但我当时没这么干（而且后面我搜开发商也没搜出来啥）。
这里为什么不先对登录框进行目录扫描？其实在正常测试时，你也可以先将路径扫描开着，毕竟这很需要时间，同时再干其他的测试。我自己更偏向于先看路径特征，再自己用字典对特定部分进行扫描，一上来直接路径扫描肯定是可以的（没必要递归扫描，太慢了，可以扫出来再自己判断是否需要对某个路径进一步探索）。
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
部分出现空白页面，说明为错误路径，（前面做路径分析的好处）虽然是提取出来的js，但这种js提取工具只是基于一定规则去匹配提取，并不一定能用，而且搜得也不全面，你也可以尝试根据页面特征自己修改匹配规则。
或者自己进行关键字搜索，去找现成接口的优先级要大于FUZZ，盲目FUZZ，既消耗时间，又会因为没成功打击信心。
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
尝试后完成参数拼接，（参数怎么拼得试，GET,POST传参都有可能）显示未授权：所有接口都有严格鉴权。
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
如果遇到缺少参数而无类似上述的提示，可以尝试传入垃圾参数，根据回包FUZZ参数。
这里有几种思路，要么找微信凭证，要么直接测权限绕过，要么根据service接口特征进行FUZZ，或者对登录框进行爆破。
发现该页面由webpack打包，那么它的前端页面得代码就会暴露出来，可以考虑将前端代码下载到本地测试，或者自己搜关键字（admin，passwd，ak，sk，github等等）不过第一种方法太过麻烦，我一般被迫无奈才会干，所以选择第二种。
这里我又从另一种思路出发。首先这是使用的别人的产品，也就是别人公司生产的，那么就极有可能会有测试版本，（出洞甚至可能通杀，这种我在挖CNVD时遇见过）于是我将子域名改为test访问，显示连接失败。
这时我再在前端关键词搜索test直接找到如下信息：（JSfinder没提取出来）
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
证明确实有测试页面，只是主域名与本页面域名不一致。
访问测试页面，出现如下页面：
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
这个是证书的问题，可以用bp抓包，让流量走bp的证书，来实现访问：
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
此时我的思路变为了先打测试页面，找出漏洞后再用漏洞来测原来的页面。
继续一顿基础操作无果......包括利用“某某管理系统”搜索历史漏洞无果（github找到个历史漏洞但没利用成功）。
（“某某管理系统”这个关键字在小程序转web那个登录框是没有的）
但是我通过google语法搜索关键字“某某管理系统”找到了它的一个api文档。
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
怎么办？要不要深入分析js文件，或者做特定字典尝试爆破？或者又再次将目标转移到这个页面来测试，先把api文档搞出来看看？？？
我盯着这个页面看了会后，直接把文档路径复制到最开始，也就是小程序转web页面那个登录框处，ctrl+v，访问。
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
这里经过我多次尝试，找到了一个未授权接口，结合先前的接口特征进行拼接访问，得到敏感信息：（其实好多时候我拿到的api文档一般都不能直接用，需要通过观察api文档的路径规则后再自己FUZZ接口，FUZZ参数，这次也只有一个接口可直接用）
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
（部分图片）
通过点击页面链接可看到：姓名，电话号码，学号，身份证号，家庭住址等等，妥妥敏感信息泄露。
但此时还有一个问题，为什么我访问这个接口，它会特定显示这一个人的信息？？？
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
很明显没成功。观察返回页面，oss,aliyun这是使用了阿里云存储桶的，看来我前面没测文件上传是正确的选择。
如果想要对这种来测试，那就要接触到云存储的漏洞利用了。（这里涉及的几种漏洞我没有尝试成功）
这个学校的防护其实挺好的，包括我找的所有sql注入测试点都是被魔术引号处理了的。而且那个api文档，包括那个未授权接口在原本登录页面是找不到任何信息的（后来我用dirsearch也没扫出这个api文档）。
继续测试。为什么会固定返回那一个人的信息？能不能通过这个未授权接口尝试遍历其他用户信息？
分析数据包，试着修改那个未授权接口与cookie等，都没有效果。于是猜测后端可能存在一个接口接受前端的某个参数，根据参数值进行用户信息返回，如果不传这个参数，不会报错，而是返回一个默认的用户信息。
（这种设计挺安全的，还好没直接把用户信息一下全部调出来，不然我可能就要跟它的数据库一起寄了）
后来我将GET请求改POST请求，在body处构造json数据格式，开始FUZZ。
成功FUZZ出后端接收的那个参数（其它不正确参数都返回原来默认用户的信息）：
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
根据参数特征进行规则爆破，字典总量达到26万，爆破成功率较高，泄露信息量近万条。（证明漏洞存在即可，别真跑数据去了！）
最后到对应平台提交漏洞（评级高危），并提出修复建议。
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
![挖洞从思路出发：登录框实战]( "挖洞从思路出发：登录框实战")
原文始发于微信公众号（红队蓝军）：挖洞从思路出发：登录框实战
评论