记某积分商城任意金额支付漏洞分析利用及思考
大部分开发人员在开发时都会有一种思维惯性，传参处处有校验==处处都可信，但这个等式并非恒成立
前言
这个漏洞是在工作中例行渗透测试的时候发现的，虽然前端做了防篡改措施，但这是很经典的没有后端校验导致的任意价格支付。 漏洞已在内部提交并确认修复。
漏洞描述
兑换积分商品时数据包会携带extendKey ，在分析js代码时发现，其值是商品id、数量、商品价格、可用积分这几项的拼接值，再进行加密得到的。本意是使用extendKey实现数据包关键内容二次校验防篡改，但extendKey的加解密方式以及key均写在js代码中，这就使得extendKey的篡改变得可行。在兑换积分商品时经解密发现其值会携带商品价格信息，篡改后实现任意使用任意积分对商品的兑换。
漏洞分析利用
0x01 加解密说明
在js代码中找到extendKey的加密方式，可以看到用的是aes-128-ecb加密，密钥n也明文写在js代码中。
加密流程：先aes-128-ecb再base64编码。 解密流程：先base64解码再aes-128-ecb解密 对extendKey的值做解密验证
解密发现,原始字符串是将商品id和数量使用“|”做了拼接
0x02 利用过程
账户中原始可用的积分
选择一个所需积分大于账户已有积分的商品，点击立即购买，拦截响应数据包
解密extendKey发现是 两个商品id+数量+商品积分价格 的组合字符串
修改字符串中最后一个值及价格为10，并重新生成extendKey
接着修改返回包中tradePointAmount的值为10，并填入篡改后的extendKey值
然后释放响应包前端出现提交订单页面,虽然前端显示的还是29900的价格，这是因为控制前端显示价格值的不是tradePointAmount这个键值
点击提交订单可以看到交易价格已经是10积分，从后续的响应包也可以确认这一点 紧接着释放响应包，确认前端10积分的订单已经生成成功等待支付 最后支付订单
分析总结
这个漏洞就是经典的未对金额进行正确的后端校验，先从开发者的视角分析一下开发者的思路：
- 点击立即购买，请求带上商品id以及数量，向后端获得价格等信息。
- 后端服务查询得到商品价格，返回前端，前端接收并校验为提交订单做准备。
- 提交订单，前端传递“可靠”的价格值去请求订单处理服务，生成了支付订单。
第1步，前端认为应该先向后端询问商品价格，第2步完成时前端开发者视角下认为金额是后端传递给前端的且对金额数量等值做了加密，只要前端进行解密、校验，便认为是“可靠”的，到第3步向支付系统请求生成订单时，后端支付系统开发在对接时得知有个extendKey值可以做校验，也就放心的进行了价格校验。虽然也对价格等关键参数值做了加密、校验，但忽略了AES是对称加密，而js也未作混淆之类的处理，算法密钥以明文的形式暴露给攻击者，篡改extendKey轻而易举。问题就出在支付订单生成服务未在订单生成前在后端向商品价格的数据库查询做二次校验，而只是校验了前端传的值。开发时觉得，传参处处有校验==处处都可信，这是一个思维惯性，但必须要注意避免。
ps:
至于为什么要在第2步就修改金额，是因为前端有个账户积分和商品价格比较的机制，积分不足不会有下一步订单提交生成，如果商品原本价格就低于已有积分，那么直接从第3步修改金额就可以