零基础学黑客领资料
搜公众号：白帽子左一
（故事纯属虚构，如有雷同纯属雷同。）
作为一个网络安全一年级学生，平时喜欢养生，某天下班后企微突然弹了个上线前测试任务的通知，看任务描述是供应商开发的工作台小程序，已通过第三方安全测试，再仔细一看是薪资查询系统。
功能非常简单，一个登录口几个查询接口。账号密码输入、查看、退出，提交无漏洞报告，一气呵成。
《危.jpg》
重开
并非迫于领导淫威，只为不断提升自己，早日实现财富自由，做一个吃喝不愁的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参数。
一顿操作猛然虎（逆不动），一看时间两点三十五，狗命要紧。
躺在床上，留下了没有技术的眼泪，明明近在咫尺，却远在天边，心中满是不甘。
第二天上班 ，准备再挣扎一下，已无退路可言，稳住心态，重新分析流程，接着回想昨天柑橘不对的地方，先不说有没有共用一对公私钥，单是响应密文的解密私钥也愣是没看见。
手没有感情的点着鼠标，眼睛继续关注着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、访问控制
测完结束，重写报告提交给开发团队修复，修复建议：身份鉴别应使用session，不要用uid、不要用uid、不要用uid。
开心之余又有些担心，准备着喝完茶去送外卖了。
然后...
整体来说运气不错，如果真是RSA的话第一步就是知识盲区了，后面验证越权第二三步也没有障碍，回顾一下这个越权漏洞的发现过程：
1、被迫重开。
2、登录发现使用了RSA加密算法，潜意识判断内部用的也是RSA，寻找params明文未果，不甘心的睡觉。
3、再挣扎一下，回顾疑点，最终发现内部关键字段用的其实是AES算法，从而实现降维打击。
4、二三步畅通无阻，js中发现AES密钥 --> 解出params明文 --> 篡改uid伪造身份 --> 发送伪造密文通过身份鉴别 --> 解密服务端响应的密文 --> 最终拿到数据。
经验可以给我们敏锐的“直觉”，但也会带来 “思维惯性”，也是这次最大的阻力，值得反思一下。关注下这类被加密隐藏的越权问题，或许会有惊喜，最后祝你们多多挖洞
关注微信
