突破浅层测试桎梏：多维度漏洞挖掘突破与实践探索

扫码加圈子

获内部资料

网络安全领域各种资源，EDUSRC证书站挖掘、红蓝攻防、渗透测试等优质文章，以及工具分享、前沿信息分享、POC、EXP分享。不定期分享各种好玩的项目及好用的工具，欢迎关注。加内部圈子，文末有彩蛋（知识星球优惠卷）。

原文链接：https://forum.butian.net/share/4325

作者：一天要喝八杯水

多维度漏洞挖掘突破与实践探索

在漏洞挖掘领域,刚入门新手常受限于浅层测试模式,他们多止步于基础功能验证,扫描接口时若未发现铭感信息便迅速转换目标,并只关注首次探测到的接口忽略前置接口的检查; 信息泄露单纯明文id鉴权场景以大幅减少唯有探索新的测试手法才能突破瓶颈

本文整合许多优秀师傅分享思路与笔者事件经验,萃取其中精华皆在拓展读者挖掘视角,这些分散的优质思路此前缺乏系统归纳,本文讲其一部分思路优化汇总,期望实现思路价值的叠加效应,若本文对您有帮助欢迎点赞支持,后续将推出更多整合后的漏洞挖掘场景分享,欢迎交流学习 不足之处望指出,转载请标明出处！

前置基础

熟悉各种请求以及状态码,在功能点无从下手时,未授权往往在这种信息中;很多人忽略了这个点,接口测试只测试第一层找到的接口,并不会仔细的去看接口的前置目录是否正确,一味的爆破得到404,并且第一次找到的接口拼接后也是看一眼功能而已,并不会去观察字节大小加载的新信息去尝试二度拼接

请求方法

GET：获取资源。GET请求用于从服务器获取指定的资源。它是最常见的请求方法，通常用于请求和读取服务器上的数据。

POST：提交数据。POST请求用于向服务器提交数据，通常用于创建新的资源或在服务器上执行某些操作。

PUT：更新资源。PUT请求用于向服务器更新指定的资源，通常用于修改或替换现有数据。

DELETE：删除资源。DELETE请求用于从服务器删除指定的资源。

HEAD：获取资源的元数据。HEAD请求与GET请求类似，但它只返回资源的响应头部信息，而不返回实际的资源内容。

OPTIONS：询问服务器可接受的请求方法。OPTIONS请求用于向服务器查询支持的请求方法。

PATCH：部分更新资源。PATCH请求用于对服务器上的资源进行局部更新，只修改指定的字段或属性。

TRACE：追踪请求的路径。TRACE请求用于在客户端和服务器之间进行往返检查，以查看请求在传输过程中是否被修改。

CONNECT：建立代理服务器隧道。CONNECT请求用于与代理服务器建立隧道连接，通常用于通过代理访问SSL加密的资源

状态码

200 OK： 请求成功。服务器已成功处理请求

301 Moved Permanently： 永久重定向。请求的资源已被永久移动到新的位置。

302 Found：临时重定向。请求的资源临时被移动到另一个URL

304 Not Modified：未修改。自从上次请求后，资源没有发生变化，可以使用缓存的版本

400 Bad Request：错误请求。服务器无法理解请求，通常是由于客户端错误 缺少参数

401 Unauthorized：未授权。请求要求用户的身份验证。

403 Forbidden：禁止访问 服务器理解请求但拒绝执行。可能是因为权限问题。

404 Not Found：未找到 服务器上没有找到请求的资源。

405 Method Not Allowed：方法不被允许。请求行中指定的请求方法不能被用于请求相应的资源

408 Request Timeout：请求超时。服务器等待请求时发生了超时。

500 Internal Server Error：内部服务器错误。服务器遇到了阻止其完成请求的意外情况。

501 Not Implemented：未实现。服务器不支持请求的功能，无法完成请求。

502 Bad Gateway：错误网关。作为网关或代理工作的服务器从上游服务器收到了无效的响应。

GET拼接接口没什么好讲的,重点就是POST方法以及状态码为405的情况

处理方法则是修改请求为POST数据下方加入空json体,因为某些时候单独的修改方法但是请求没有JSON格式响应包也不会有数据返回,这样去做拼接会意向不到的惊喜,再通过接口的响应如果缺少什么参数就找什么参数,

POST

Content-Type: application/json

{
}

正确跑出接口后就是根据字节长度找到关键，size字节大肯定加载了新的东西新的JS,再在新的接口基础上再去浏览器带着接口访问,逐步测试.....

403 未授权 权限问题

接口测试及JS信息想进阶一步强烈推荐关注L@2uR1te师傅公众号《HW专项行动小组》,通过JS接口测试挖掘高质量漏洞案例和深层的Java文章相关知识,是不可多得的宝藏公众号,好的文章思路值得被广泛传播。

在访问后台时会在一瞬间加载出后台界面,又重定到登录页面,这里提供两个测试方法,我重点阐述方法2

1. 利用burp卡住进入后台的包不要放过去,然后就是去后台处点击,点击结束后再一个个放包,这样又可以测试未授权,但是效率比较慢,需要对功能逐个点击,2是有时候加载新的接口并没有出现在页面中
2. 卡住登录包,等待一下就会加载后台的JS然后熊猫头探测到接口 拿到这些后台接口就可以直接批量测试测试未授权了,下图是典型的后台页面,卡住后就不会发送重定向数据

如果后台页面并不会一闪而过,开局登录框手动输入账户密码,然后拦截响应改为ture ,如果校验不合格会一瞬间进入后台,然后重定向.如果可行的就可以按第二种方法继续测试未授权, 微信公众号文章学习到的思路

当我们编辑或者出现权限不对等的功能点,比如管理员 编辑者 创作者 查看者,类型不一致 靠数字绝对尝试修改类型参数,通过参数修改代替高权限的身份去操作

type:0// 查看者

type:1// 编辑者

微信案例

URL混淆漏洞是指服务器和解析URL时，由于不同组件或系统的解析规则不一致，攻击者可以利用这种不一致来绕过安全控制或获取敏感信息,对路径进行编码添加后缀的方式从而进行绕过

正常接口无权限

对最后的接口后面添加混淆,利用字典去Fuzz 添加.json绕过,测试鉴权相关的漏洞时，可以尝试url混淆，接口多个位置fuzz 添加资源文件后缀

/api/user ----> 未授权403
/api/user.json/css/png --- 200 ok

资源文件绕过字典,一般遇到403可疑接口我都是利用Onesacn去帮我在接口不同位置拼接测试，在插件中设置好字典,有403接口就发过去跑,利用资源文件进行多个位置拼接

如果出现状态码为200且字节长度很场很大概率又加载出了新东西,我们也就能测试更多地方

资源文件字典

%09
%20
%23
%2e
%2f
/%2e/
//
/..;/
//..;/
/%20
/%09
/%00
/.json
/.css
/.html
/?
/??
/???
/?testparam
/#
/#test
//.
////
/.//./
~
.
;
..;
。
;%09
;%09..
;%09..;
;%2f..
*
.json
../
..;/
?a.css
?a.js
?a.jpg
?a.png
../admin
..%2f
./
.%2f
..%00/
..%0d/
..%5c
&
#
@
?
??
...
.././
/;/
.%2e/
..
..%ff/
%2e%2e%2f
%3f
?.css
?.js
%3f.css
%3f.js
%26
%0a
%0d
%20
%0d%0a
%3b

.

BP插件https://github.com/0x727/BypassPro 也可以处理403接口

vue框架前置有# 注释 数据包是抓不到的,熊猫头找到的这一批接口无法直接在bp通过爆破器拼接,这个时候几个方法可以测试未授权

https://xxxxxxxxxx/rental/#/login/  

1.手动拼接如果出现有效可访问接口就可以在有效接口的基础上再去看熊猫头加载的新接口得到新的接口再拼接未授权,逐此反复

https://xxxxxxxxxx/paypage/#/riskReport?transld=

2.urlfind扫描.注意看字节size大小 ,当字节变化代表加载到了不同的数据不同的JS就可以再用 熊猫头测到新的接口,注定看urlFinde的新的接口信息,然后在新的接口基础上又去看新的泄露接口二次拼接

/rebateBillSettlementList接口出现在BP但是前置的接口/api/gw/rent/rebateBillSettlementList都没有见过,代表可能会以这个前置目录去拼接得到的JS接口,把找到的接口以这个目录为前置去爆破试试,有些时候不一定，都可以尝试;

所以说SRC最好是针对一家去挖掘,熟悉业务这个概念其实很模糊,新手常常疑问为什么要熟悉业务?不都是挖嘛,挖啥不是挖呢,我对于熟悉业务的理解是,理解开发代码的习惯,同一批站点会有很多相似的地方,Web和小程序如果是一套,那么假设一个可以登录注册一个只存在空白页面那么token是否可以替换?a站点普通用户权限b站点有管理员权限,那么接口调换一下呢,举一反三的概念,当然大佬可不惯着你上去就嘎嘎出高危,当我们还无法对漏洞信手拈来的时候能做的就是对每一个数据包做好分析，每一个思路做到记录并实践！久而久之出货只是时间问题

如果经常对一场厂商挖掘可以继续下业务的接口,有时候会能多套系统部署同一个接口 A站点的接口可以给B站点使用,A B站点接口组合一下又会出现新的接口,得到更多的攻击面

越权查询/操作

任何交互处都可能存在越权

查询的还是需要测试XSS或者其他的查看响应包是否有回显这种,使用%测试通配符注入这些

深度挖掘 所有能点的地方全点开看

个人信息交互功能点,BP刷新抓包将决定用户身份参数数据包找出,常规决定用户是谁的方式是找uid,有时候不一定是ID可以是其他的参数,比如修改为别人的号码就可以越权查看,逐个删除Cookie中字段发包,直到响应报错就可以确定删除的字段就是整体鉴权,如果JWT鉴权就可以打一套通用的攻击,其他弱参数鉴权就可以尝试爆破

评论区重灾区

1.  越权删除别人的评论,首先删除我自己的抓包,尝试 替换用户的id  替换评论文字的id

2.  回复模块,我回复别人,  替换用户id   让别人回复别人  

3.  回复评论会出现新的功能点 

4.  CSRF越权回复别人

决定用户参数的ID不是单纯的数字,是由于文字编码得来文字对应编号,所以并不是没有修改ID越权,只是明文ID已经近乎绝迹,取而代之的是未鉴权的编码id、有规律的长id,测试越权最好还是双开对比数据包这样既不会影响到普通用户业务又可以通过不同用户数据包寻找出差异,数据包利用文本对比工具可以很迅速的找出差异,下面的编码汉字只是一种,我想传递的是举一反三的思路

GET /XXX?id=%E4%B8%94%E4%B8%98%E4%B8%96%E4%B8%93 HTTP/1.1
Host: XXX
Accept: /
......
Connection: close

id=%E4%B8%94%E4%B8%98%E4%B8%96%E4%B8%93 解码后: 且丘世专

所以且丘世专对应着我的id也就是4863

核心是普通用户获取到管理员邀请管理员接口然后自己拿来用自己生成 然后自己点击生成再自己成为管理

A 场景

1.B(管理员)生成团队查看者链接,A点击了A成为了团队成员

2. 管理员B为我们测试的账户,拿到它生成团队编辑者(编辑者就是管理员)的接口,去给A使用生成编辑者的接口,用它的功能

3. A使用B功能生成的编辑者链接,再自己去点击,这样它就和B(管理员)一样了

B A均为自己的测试账户,A使用了B的功能接口,类似另类的免费使用付费的东西

管理员B生成查看者链接,A 成为了团队内的,然后A利用B生成编辑者的接口,替换身份为自己的,等于是A生成了编辑者的链接,然后A自己再去点击 A也就成为了管理员,管理员的接口是我们自己的大号,所以我们的小号就通过已知的管理员邀请接口拼接自己成为了管理员

B 场景

普通用户申请权限,利用大号(admin)的数据包和小号的做对比,从而修改普通用户申请权限的数据包为管理员字母也可能是root 我们可以跑字典

role："user"   修改为 role:"admin "

信息泄露接口

有的接口参数有斜杠有的问号 其实效果是一样的

信息泄露往往伴随着JS拼接接口参数,查询信息处置空或者写入% 都代表模糊查询了只要是查询的地方记住删除全部参数以及置空参数或者输入%

GET /api/demo/query= xxxxxx 

GET /api/demo/   # 删除查询参数

GET /api/demo/query=  # 置空

GET /api/demo/query=%  # 模糊查询

特别是针对接口出现id 资源

h5/qrCode.html/?id 

测试方法:

h5/qrCode.html/?id=   置空 
h5/qrCode.html/?id=%  添加值/% 
h5/qrCode.html/?id=null   添加null
h5/qrCode.html/  删除qroCode.html 

Authorization置空响应返回401 修改为1 返回其他信息 这个字段存在尝试修改, 一般和jwt同时出现作为鉴权,修改它应该是和修改为管理员或者是模糊查询%一个意义 所以都可以举一反三

Authorization: Bearer xxxxto

任意功能点

只要是后端没有返回关键的权限字符 如 jwttoken 那么代表可以尝试修改返回包登录，因为后端响应包没有输出信息代表并没有经过后端,在站点的其他业务得到类似的响应一般会是如下,结合业务点,没响应鉴权都可以做到短暂绕过,多出现有限制的场景,邀请码、代理商、管理员提交,绕过出现新的功能点又可以尝试测试了

success: true
code: 200
message: 成功
data: true

用户参数的只是一个ID并没有后端的cookietoken鉴权尝试找到别人的ID,比如站点关注别人查看排行榜,社区评论区、投诉、反馈 等涉及供用户交流的功能都可以带出用户的id

添加list** 删除前置路径**

原本查询个人信息uersd 后续接上list虽然是404未找到但是可以删除前面的路径

正常原路径
/prod-api/system/info/small/userId

修改后的路径
/prod-api/system/info/small/userId/ list

删除前面的接口small最后意思就是信息的列表，可以回显所有人的信息

/prod-api/system/info/list

添加list并斜杠/结束

个人接口的单词修改为list并添加斜杠会 列出全部信息

/api/user/ads/info?a=123456// 只能看到自己家的信息

/api/user/ads/list/?a=123456// 更改参数并斜杠结束 绕过和某些中间件有关

在个人信息接口删除传递的参数值,直接将用户值写到前一层接口,拿到别人的id作为接口请求,那么找到别人的id 就可以尝试替换了,有时候是用户的昵称或者其他值 需要对业务多观察,对比自己的个人信息判断

GET  /api/v1/user/info?id=@saber # 正常写法

GET  /api/v1/user/@saber # 此场景下

个人信息处或者涉及铭感信息,肯定是要查询的,我们点击查询如果响应包为出现了某个数组,但是为空那么存在越权的可能性比较大,意思是查询到了但是是空的,那么可以删除token测试貌,发包就会回显所有的信息

saber:[]

涉及个人信息模块,如果我们正常请求我们自己的 ID 号码这些,如果是ID,属于JSON格式,并且回显也是一条

请求:  

{
   uid:100001
{

 响应: 

{

   xxxxx
   xxxxx
   xxxxx

}

如果此id可以遍历我们手动传入多个ID,并且响应包也会回显出多个用户的信息,那么造成信息泄露

请求: 

{
   uid:100001
{

{
   uid:100002
{

{
   uid:100003
{

响应:

{

   xxxxx
   xxxxx
   xxxxx

}

{

   xxxxx
   xxxxx
   xxxxx

}

{

   xxxxx
   xxxxx
   xxxxx

}

参数置空并改特殊值,然后pagesize改成很大的可能可以看别人的,我发布的另一篇文件利用到了此技巧,造成信息泄露,原理是模糊查询并且前端传入多个字节size

奇安信攻防社区-小程序渗透记录 通过细节挖掘漏洞的艺术

接口的路径为这种的参数值,尝试删除 多尝试可能性能操作就全部操作,因为你也不知道这个点有没有漏洞删除后可能会返回所有用户的接口信息 ID数字无论出现在前或者后我们都应该去测试遍历

GET  api/user/123456

GET  api/123456/user

GET  api/user/  //  删除后发送接口 回显所有用户的userinfo

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

记某src通过越权拿下高危漏洞

如果两个接口返回的内容是一致的,那么一个地方越权另一个地方也可以越权,如果Userid是无法遍历的则想办法找出,利用&符号拼接决定用户ID参数越权其他信息遇到全部个人信息是cookie鉴权可以尝试此方法

文章案例Getuser接口接口会显示出用户铭感信息,但是只有Version是可以修改的,这个参数代表版本或者时间修改也没有作用,修改cookie也没啥用,无法越权

gateway/nuims/nuims?Action=GetUser&Version=2020-06-01

但是通过其他接口得到UserId参数填上其他用户的值可以越权查看其他用户的个人账户敏感信息 &符连接,

/gateway/nuims/nuims?Action=GetUser&Version=2020-06-01& UserId=xxxxxxxxxxxxx

并且文章拓展思路是第二个接口返回值和第一关接口正常的返回值是一样的只会返回自己的信息,所以相同接口返回内容还可以尝试最次拼接, 建议阅读原文思路才能更好的理解这个思路

第二个接口正常返回值也和第一关接口一样,那么第二个接口也可以拼接,可以吃两份钱

/gw/nuims/api/v1/nuims/LcpGetUser

/gw/nuims/api/v1/nuims/LcpGetUser?UserId=xxxxxxxxxxxxx

输入框XSS

文章实例

咨询客服输入框,输入后抓包如果看到 type类型为text,则是会把输入变成普通的文本我们顺势修改为 html但由于是我们主动修改 所以是 self-xss,然后看文章进行存储xss利用

抓取到搜索记录的请求,制造为POC发送给受害者点击,它相当于在当前网站上搜索了一次,那么等受害者点到历史记录的话XSS就会被执行,存储到了受害者的网站中,利用XSS平台直接打cookie,

CSRF+XSS:

如果一个点存在XSS可以弹出Cookie,那么尝试
制作这个请求为CSRF，发生给受害者后它在本地弹窗 我们这里接收到Cookie就完成了攻击,如果是存储的危害更大

文件夹/文件是否可以重命名,重命名意味着又是一个新的输入框 又可以打入XSS,包含但不限于这种场景大白话就是尽可能的找到框,和小众页面输入插入 test">

URL出现参数name=xxxx,我们正常的写我们的值,然后全局搜索内容,每次输入完**F12****观察搜索,**为了避免过滤先输入正常的文字,等找到了带入的地方再办法构造Payload,这样很麻烦但是可以试一试

微信文章

更改请求为mutipart格式可以绕过后端的实体化和绕过

原文始发于微信公众号（神农Sec）：突破浅层测试桎梏：多维度漏洞挖掘突破与实践探索