SRC案例-从逆向JS加密到获取几十万用户权限

token加密发现

1. 打开站点，进行注册登录操作的时候需要上传身份信息等资料

2. 抓包，发现该接口可能是通过两个ID值来返回对应的用户个人信息的，那就修改ID试试越权呗

3. 修改userid提示未登录

4. 那就尝试修改dealerId，提示token异常

怎么办呢，难道就放弃了？其实还可以看看能否JS逆向出”token是怎么得到的”这个流程，这里没有sign数据包校验，那么是可以篡改数据包的，如果JS逆向出了token，就可以伪造token！越权也就有可能成功了

逆向token加密流程

首先看到token又是数字字母的长度又是32位的，第一反应是md5加密，ok开始JS逆向token

1. 全局搜索token

但是搜出来很多怎么办？可以给每个疑似token加密点处，都下一个断，只要触发了加密流程，就会停在真正的token加密点处

2. 然后断在了一个headers.token处，headers的token等于后面的参数，多半就是这里了

3. 不确定的话，可以利用控制台进行调试输出结果，发现果然是我们要找加密方法

4. 然后进行函数跟进，发现了使用了AES.ECB加密

5. 最终得到的加密方式是：data数据->AES.ECB加密hex->md5加密

结果成功匹配上，说明加密正确

伪造加密数据越权

1. 修改dealerId在进行data数据->AES.ECB加密hex->md5加密的流程

通过遍历ID，再根据逆向出的加密流程，以ID为data加密得到token，成功越权获取到几十万用户身份信息

2. 发现还有APP，再去尝试一下看能不能进一步突破

3. 直接登录刚刚注册的账号进行抓包

4. 推测会不会是就刚刚相同加密方式呢？AES是对称加密，于是使用得到的要素是可以被解密的

5. 果真还是刚刚的加密，再次试试越权

6. data数据包里面有2个参数是我们未知的分别是data、token

7. 还是复用之前的加密流程，data也尝试AES解密

8. 就是用户ID，而且加密方式跟Web如出一辙，直接把data数据再进行md5加密，得到了token，那尝试把cookie删除请求看看

一样返回结果了，那岂不是说明身份就是userid

9. 这个时候在想如何再进一步突破呢，每个接口都要去加解密岂不是很麻烦

10. userid肯定是登录成功然后获取到，那修改数据包中的userid后面所有的接口都会用这个userid，那岂不是就等于任意用户登录的效果了嘛

11. 找到登录成功的返回包把userid遍历替换，再进行aes加密，得到我们伪造的合法的登录成功的响应，且包含了用户凭证

12. 登录的时候账号密码随便输入点击登录再利用burp的功能修改返回包为我们伪造的数据包

13. 直接进去来了，代表可以控制几十万商户