*郑重声明：本文所提供信息仅供学习研究或自查使用，切勿用于非法用途，由于传播，利用此文所提供的信息而造成的任何直接或间接的后果和损失，均由使用者本人负责，本文作者不承担任何责任。

0x01 背景

（故事纯属虚构，如有雷同纯属雷同。）

作为一个网络安全一年级学生，平时喜欢养生，某天下班后企微突然弹了个上线前测试任务的通知，看任务描述是供应商开发的工作台小程序，已通过第三方安全测试，再仔细一看是薪资查询系统。

功能非常简单，一个登录口几个查询接口。账号密码输入、查看、退出，提交无漏洞报告，一气呵成。

《危.jpg》

0x02 重开

并非迫于领导淫威，只为不断提升自己，早日实现财富自由，做一个吃喝不愁的five，重新梳理下思路。

开搞

1、敏感信息泄露：无果

2、工具检测：无果

3、登录框

win10系统代理127.1:8080启动，burp启动，打开登录页面，开始渗透。

• 弱口令爆破放弃（图像识别不会）

• 有账号锁定机制、模糊登录提示，该有的都有。

• 无短信登录机制，图形验证码一定次数后出现，未发现绕过。

• 明文传输

先从http登录请求开始分析，username passwd关键参数加了密，这个长度目测RSA加密算法，明文传输都不给？再看一波登录认证流程，前几步看起来用的企微的一套流程，一顿操作后，也没啥思路，最后获取的session看着也不是jwt，看来从登录流程搞不到产出勒。。

4、访问控制

• 越权访问

登陆进来，一顿点点点。

”获取PS数据成功“，这就是关键请求了，但和登录一样，不仅请求加密，响应也加了密，目测这里也是RSA算法。

再看一眼请求参数，猜测action是查询类型，而params是时间等筛选条件？？凭借我屈指可数的肾透经验，这里有点奇怪，action没加密，params却加密了， 这样的做法有点做贼心虚的意思。

如果猜想正确，岂不是可以查老板薪资，要验证猜想（经典的加密越权），需要三步：

第一步：必须得拿到一个params明文。

思路1、企微小程序可在浏览器中打开：如果没配置拒绝用户在浏览器中打开小程序，我就有机会通过前端断点调试的方式拿到params明文格式。

思路2、双向RSA加密公用一对公私钥：响应数据虽然是密文，但页面总是要给用户展示信息的，所以前端必然会有解密操作，那私钥一定会出现在前端。

思路3、硬刚：在混淆的js代码中逆向分析params参数，难度高，且费时费力（我不会）。

第二步：params明文数据中存在用户唯一标识uid，且唯一标识uid存在规律。uid可能是姓名、简单数字或者登录用户名等，这种我就可以猜到老板的uid。

第三步： 服务端仅使用uid而非session字段来进行身份鉴别。这样通过伪造老板的uid进行身份鉴别，就可以拿到工资信息。

思路1：企微小程序可以在浏览器中打开。

选择在浏览器中打开。

直接跳到了企微统一回显页面，GG

思路2：双向RSA加密公用一对公私钥。

右键js 直接搜索关键字setPrivateKey|PrivateKey|setPublicKey|PublicKey等关键字，搜了一圈，只找到了1010行PublicKey，没搜到私钥，整个流程也没看见有密钥之类的接口，柑橘很奇怪，不禁陷入了沉思。。。

这里有个tip，思路1跳转前，浏览器会先加载目标的js等静态资源文件，然后才会进行页面权限校验的跳转。这种情况下用burp代理开启拦截一步步放行，可以把页面卡在跳转前，方便使用Chrome F12分析js代码，但大概率页面不能正常显示。

思路3、在混淆的js代码中逆向分析params参数。

一顿操作猛然虎（逆不动），一看时间两点三十五，狗命要紧。

0x03 峰回路转

躺在床上，留下了没有技术的眼泪，明明近在咫尺，却远在天边，心中满是不甘。

第二天上班 ，准备再挣扎一下，已无退路可言，稳住心态，重新分析流程，接着回想昨天柑橘不对的地方，先不说有没有共用一对公私钥，单是响应密文的解密私钥也愣是没看见。

手没有感情的点着鼠标，眼睛继续关注着burp的历史请求，突然再看见这个“关键查询请求”的时候，感觉密文有点眼熟，再用burp比对昨天Reperter留下的查询请求，那不能说俩params密文毫无关系，只能说一摸一样 (●'◡'●)

RSA加密时用了随机数，密文那不能相同呀。

真相只有一个，这就不是RSA！！难怪一直找不到PrivateKey。再次找到js，输入熟悉的关键字enc.Utf8.parse验证猜想，一口老血吐了出来，这波呀，这波是降维打击，密钥到手。

掏出之前写的python脚本，AES-128-ECB-Pkcs7，用密钥解密params，明文里第一个参数就是uid，这时 我感觉已经稳了。

params=Z0YzJz/VqeJ5EB**************************************b1RQ/NEcGZsOXLw==

响应密文同样用的是AES加密算法。nKnG45TzMzBstdw5P/EAU46EVWhOpkKNA/haj*************************

第三步验证就比较简单了，只需篡改成老板的uid--> 生成伪造密文 --> 最后发送伪造的密文，观察到响应密文和之前不一样。

解密密文，高危漏洞到手 ψ(｀∇´)ψ

4、访问控制

• 未授权访问：最后用burp -> Authz撸一遍未授权，无果，结束。

测完结束，重写报告提交给开发团队修复，修复建议：身份鉴别应使用session，不要用uid、不要用uid、不要用uid。

开心之余又有些担心，准备着喝完茶去送外卖了。

然后...

0x04 总结

整体来说运气不错，如果真是RSA的话第一步就是知识盲区了，后面验证越权第二三步也没有障碍，回顾一下这个越权漏洞的发现过程：

1、被迫重开。

2、登录发现使用了RSA加密算法，潜意识判断内部用的也是RSA，寻找params明文未果，不甘心的睡觉。

3、再挣扎一下，回顾疑点，最终发现内部关键字段用的其实是AES算法，从而实现降维打击。

4、二三步畅通无阻，js中发现AES密钥 --> 解出params明文 --> 篡改uid伪造身份 --> 发送伪造密文通过身份鉴别 --> 解密服务端响应的密文 --> 最终拿到数据。

经验可以给我们敏锐的“直觉”，但也会带来 “思维惯性”，也是这次最大的阻力，值得反思一下。关注下这类被加密隐藏的越权问题，或许会有惊喜，最后祝你们多多挖洞。