SRC实战：改个返回包就严重了？

最新推荐文章于 2024-11-07 09:14:33 发布

微雨绵绵

最新推荐文章于 2024-11-07 09:14:33 发布

阅读量415

点赞数 4

文章标签：前端 java javascript 系统安全 web安全网络安全计算机网络

本文链接：https://blog.csdn.net/qq_34851291/article/details/140735173

版权

生活就像自行车，要想保持平衡，必须不断前进。—— 爱因斯坦

周一仿佛就是那个提醒你“不能停”的日子，哪怕你的心灵还没准备好继续前进。

0x00

经过长达一天的周末过后，又要开始上班啦。大周一的，还是老样子，来点技术向的文章，给大家伙提提神咯~
好久没有更新 SRC 实战系列了，刚好前段时间遇到个比较有意思的洞，和大家分享一下吧。

除去信息收集的时间，这个漏洞大概花了1个多小时，最后是给的是严重。

警告：文章较长，全文无图。如果对漏洞挖掘或者技术类不感兴趣的朋友看到这里就可以了，不要再继续往下滑动折磨自己了。

说明：主要讲思路和过程。因为截图涉及到大量的敏感数据，这篇文章又是在仅有一个周日写的，不想花时间去打码了。我只想休息~~~~

0x01

遇到的这个站点是一个主站的管理后台，拿到这个站点的时候，简单地看了一下，没有注册功能，也没有找回密码，就一个简单的登录，然后还带有滑动验证。 所以登录相关的功能都可以直接放弃了，没有短信轰炸，不能爆破，怎么办？

如果有看过我之前文章的朋友们应该知道，这种站进不进得去再说，首先我肯定是要来一波未授权测试的，解析 JS 拿到所有的接口路径，直接扔到 BP 里面跑一波。

具体怎么获取接口路径，不管是熊猫头还是 BP 插件都可以，看个人习惯。

在跑了一遍接口之后，发现有部分接口确实有可能存在未授权！为什么这么觉得呢？因为部分接口跑出来的HTTP 响应码是 400 或 500。那下一步应该做什么？没错，去 JS 代码里面找对应接口的参数咯，这样才能正常调用。

0x02

上面流程都挺正常的，但是我万万没想到的是，这个站的参数加密和代码混淆做得太好了，真不是给人看的！

首先是加密，所有参数全部使用了RSA + AES的方式进行加密，不仅如此，还对参数进行了复杂的签名验证。

其次是代码混淆，我可以说从没见过混淆得如此杂乱的代码！要找一个调用链的难度太大了。

我尝试了大概半小时，宣布放弃，我正式承认是个 JS 小弱鸡。

0x03

本来我已经准备放弃这个站点了，登录又登录不进不去，接口参数也处理不了，那还能怎么办？

等一下，登录不进去？那我如果可以伪装成登录进去了呢？是不是就可以不用考虑参数加密这部分了？因为按正常流程的话，这部分行为网站自己会完成的啊。

这时候我决定进行最后一次尝试，如果这个思路还不行的话，就只能放弃这个站点了。

0x04

首先还是得去翻 JS（我要吐了），需要找到网站是怎么处理登录成功的请求的，这样我们才能知道在修改登录响应包时，需要返回什么样的数据，我一般会通过以下几种方式去找：

1. 直接通过登录接口搜索，查看登录成功的接口回调是怎么处理的。但是如果代码混淆很厉害，可能找不到。
2. 全局查询设置 LocalStorage 的地方，现在的很多网站，一般在登录成功后，会把部分用户信息，比如 ID 之类的，放到浏览器本地存储，也就是 LocalStorage 中，所以可以尝试直接全局查询设置本地存储的方法。
1. 搜索常见用户属性，因为代码再怎么混淆都可以，但是响应的对象属性是不会变的。一般登录响应都会返回用户信息，比如：userId、accountId、role、user_type等，通过这些属性去搜索。

很幸运，我在查询 localStorage 的设置方法时找到了对应的登录响应结构，其它不多说，主要有两个核心的属性，一个是 user_id，另一个是 role_type。很明显，一个是用户的 ID，另一个是角色类型，很可能决定前端展示哪些功能的。

role_type的类型是整数类型，很好处理，一般来说就是 0、1、2、3 这种，多试几次就行了。但是user_id就不好搞了，我去哪里找一个合法的用户 ID 呢？而且它还是一个字符串类型， fuzz 不太现实。

虽然嘴里说着不太现实，这里我还是尝试简单的 fuzz 了一下各种长度的整型，发现果然不行。

0x05

在卡了一段时间后，我决定换一个思路。既然 fuzz 不出来，那我可以去找网站自己泄露的，因为 ID 一般不属于敏感信息，很有可能会通过各种接口暴露出来。我决定去这个管理后台对应的前端主站点寻找。

一般来说，既然管理后台，那肯定有对应的普通用户的入口或者网站。

在找到对应的网站后，怎么来找管理员的 ID 呢？我的话，首先要找的就是各种公告、通知，因为这些一般都是由管理员发布的。干过开发的都知道，一般这种文章类型，肯定会有一个创建人 / 发布人 / 修改人之类的字段，里面存的就是对应用户的 ID，这种非敏感字段，很可能会在获取文章信息的时候，一并返回。

果不其然，在 BP 中查看获取公告列表的返回包时，里面包含了一个创建人 ID 的字段，很长的一个字符串。在拿到了这个用户 ID，我们的最后一块拼图就集齐啦。