API接口测试中的隐藏宝藏

案例一：

应该是由于我们没有token导致的，如果有token就好了，看看js里面会不会有遗留的token之类的。

推测这应该是他们的开发者文档 这样一来 我们只要有用户名密码 请求一下 应该就会有token了，继续从先前的JS文件中找信息。

发现用户名密码 admin----123456这样我们只要去请求获取token的方法就可以获取到token了。

获取token：

用postman 去请求这个地址

响应头中有我们想要的东西 token

利用token

验证身份

用ID获取用户信息

案例2：

对这个ip进行的一系列扫描没有任何结果返回。

那对这样的登录口，就需要再回头查看前端代码来寻找突破点。

F12查看前端代码，从这里发现了他是直接引用的系统官网下的favicon.ico。

接下来跟进到这个系统的官网，并且同时在fofa去查找与目标相同的系统。

思考后续

能收集到的信息不多，在这种前提下，能想到的思路有哪些?

1.查找该系统的历史漏洞，是否有存在CNVD、CVE等。

2.从官网的文档中查找默认账户默认口令，然后以默认口令登录系统。

3.从官网的文档中收集API列表，然后查找未经过严格鉴权的未授权访问漏洞。

4.是否能从官网直接下载源代码，对源代码进行白盒测试。

5.从类似站点入手，挖掘可能存在的漏洞，再回到目标站点进行测试。

站点有API使用手册，所以顺着思路去查看是否存在未授权访问漏洞，但是从手册中发现开发小哥的安全意识非常的好！采用了很好的鉴权手法，所以手册中没有可利用的授权访问漏洞，不过他这个API手册并不齐全。

去站点B入手

在这里相比目标系统，多了一个注册功能。所以可以登录后台扩大攻击面。

在B后台对基础漏洞进行了测试，无果。

此时我有注意到，我的burp里面出现了一些官网API手册中并没有提到的API路径。(原因可能是API手册是早期的版本下所使用的，是官网未及时更新)

在后台翻阅所有功能点，并且收集url路径大概2237条加上自己收集的API字典（个人整理的Fuzz_API字典可在内部星球获取）对文本去重并提取出路径字典进行Fuzz测试。

对于站点A，不存在的路径返回404报错，但是存在的路径则会提示到JSON报错，利用这一点可以进行判断一个API是否存在。

再回到站点A

通过对上面取得字典的验证，查找到一部分存在的API

接下来就是带上请求参数访问接口，前面说到，这个系统的鉴权比较好，不过其中还是有几个接口可以通过直接删除鉴权的t参数绕过权限校验。

三个API的功能如下

/xxxx/a/get_A参数值为    c_type=&u_id=&t=&t_id=&ts=        可以遍历u_id值和t_id/xxxx/a/get_B参数值为    s=&c_id=&t=&ts=                   可以遍历s值比较重要的是最后一个接口/xxxx/b/get_C 参数值为    tu_id=&u_id=&t=&t_id=&ts=这里可以通过接口A和接口B获取的遍历出来的u_id和s(发现s与t_id是同一个变量值)，配合遍历来利用最后一个接口获取指定后端用户的详细信息

  最后总结，通过一次偶然的机会发现了开发商暴露的API文档，这一发现很大程度上得益于运气与细致的观察。开发商不仅未对文档加以保护，还将用户名和密码（admin:123456）直接硬编码在前台JS文件中，有时候运气也很重要。喜欢的师傅可以点赞转发支持一下谢谢！