前言
免责声明：本文仅供安全学习研究，所有测试均在授权环境或自建靶场中进行。严禁用于非法用途，否则后果自负。
某水卡系统漏洞实战
此次实战是针对混合开发APP的渗透测试，通过抓包提取APP内嵌的H5页面，对其API接口进行安全测试。
常见混合开发框架：
Cordova
- 技术栈：WebView + H5
- 代表应用：早期银行APP、政务APP
- 特点：最早的混合开发方案，插件生态丰富
Ionic
- 技术栈：Angular/React/Vue + WebView
- 代表应用：企业OA、CRM系统
- 特点：UI组件丰富，适合企业应用
原生WebView
- 技术栈：原生壳 + H5页面
- 代表应用：各种物业/水电缴费APP
- 特点：开发成本低，更新灵活，最常见
为什么选择混合开发APP？因为原生APP需要逆向、Hook等技术门槛较高，而混合APP内嵌H5页面，只需抓包分析即可发现漏洞，是APP渗透的最佳入门目标。这次实战目标就是从app提取的h5页面进行挖掘（更偏向Web渗透）
混合APP容易测试的原因点如下：
-
业务逻辑在H5中，可直接抓包
-
前端JS代码可查看，签名算法可逆向
-
提取H5链接后可在浏览器中测试
如何判断APP类型
最简单的方法就是看请求包
举个栗子(比如接口里面带有h5关键词的)：
GET https://h5.***/app/index.html
亦或者解包apk去搜索WebView相关代码or查看assets目录是否有H5文件
话不多说，直接开始实战！本次实战基于真实场景搭建的模拟靶场进行演示。
正文
由于充值后会立即重定向，浏览器F12抓不到完整请求，这里用Reqable抓包。
直接将amount改为 -50，充值成功！这是典型的负数金额漏洞——后端未校验金额正负，导致 balance + (-50) 使余额反减。既然充值接口没有校验金额正负，那么转账接口大概率也存在同样的问题
转账功能在前端是进行了校验的，跟充值一样，转账后会立即重定向，浏览器F12抓不到完整请求，继续使用Reqable抓包
转账也是一样，存在相同的逻辑漏洞
虽然页面展示的我转账至A-102是-50，但是我的余额没扣反加，余额从349.48变成了399.48。原理很简单：
我的余额 = 100 - (-50) = 150 ← 不减反加
对方余额 = 200 + (-50) = 150 ← 被扣钱了
emmm，思考ing...既然是水电卡系统，那么充值也只是资金入口，真正的业务核心在缴费环节。继续沿着业务流程测试电费缴纳模块，看看是否存在类似的漏洞。
进入到缴费页面，发现只有两个接口
还是跟之前一样测试是否能修改成负值进行充电勒
充电的接口与充值、转账接口不同，电费缴纳接口增加了安全防护——请求中包含 sign 签名参数：直接修改 amount 为 -100 后发送，返回"签名验证失败"。这是一种常见的防篡改机制，后端会根据参数重新计算签名并与请求中的 sign 比对。要绕过签名校验，需要逆向分析签名算法。由于这是混合APP，签名逻辑在前端JS中实现，我们可以直接分析。
直接全局搜索sign参数，触发充值事件，断点断住了，明文就是amount加上meter_no和时间戳放到generateSign函数进行了加密。
进入到generateSign函数进行分析
function generateSign(params) {
// 1. 获取所有参数名，过滤掉sign本身，然后按字母顺序排序
// → ["amount", "meter_no", "timestamp"]
const sortedKeys = Object.keys(params).filter(k => k !== 'sign').sort();
// 2. 将参数按 key=value 格式拼接，用 & 连接
let signStr = sortedKeys.map(k => `${k}=${params[k]}`).join('&');
// 3. 在末尾追加密钥（这就是签名的关键！密钥硬编码在前端）
signStr += '&key=WaterCard@2024#SecretKey';
// 4. 对拼接后的字符串进行MD5哈希，得到签名
return md5(signStr);
}
签名算法总结：
sign = MD5(参数按字母排序拼接 + &key=密钥)
加密算法分析完之后，进行py模拟发包
跟之前充值，转账的后端逻辑一样的，但是这次危害更大，因为不仅吸了钱还加了电费
负数度数 → 负数费用 → 扣负数 = 加钱
电表读数直接加负数 → 读数倒退
结尾：
本文仅供安全学习研究使用，请勿用于非法用途。
