前言

HackingClub是由民间网络安全爱好者自发建立的一个安全交流社区，我一直很欣赏这个社区，它通过线上微信社群+线下沙龙会议的形式构建起一个高质量、高活跃度的交流平台，也确确实实在为这个行业发展奉献自己的力量，无论是线上还是线下的分享都有许多可圈可点的地方，在加上前段时间推出的微信社群，结合微信小程序+积分制管理，从某一程度上来说可以说是圈内社群构建的一种创新方式，至少很多想构建社群的人没有想到这么多，这种方式可以很好的规避微信群“死”了的问题，大大的增加用户与社区的粘性，值得点赞。

题外话说了那么多，我参与进HackingClub微信社群，尝试学习其运营手法以及与其他更多人交流，当然，我也是一名安全从业者，从业习惯让我对HackingClub的微信小程序下了手。

注：该漏洞已经修复，在征得官方同意下发布，本文仅供思路参考。

漏洞

这个漏洞的前置条件其实很多，首先你需要融入社群，你才会了解到这个小程序，才会了解到近期小程序上线了一个抽奖的活动：

并且，你还需要积极的去参与到积分制度之中，不然你都无法满足抽奖的基本条件：

接着，你仍然需要一定的运气成分，不然你无法抽中实质性奖品（积分兑换的物品）：

当你满足所有条件之后，开启你手中的屠龙刀“BurpSuite”全局代理抓小程序的请求包，兑换商品的请求包中，你会发现skuId参数，如果你了解电商相关的系统，skuId实际意义上就是某一个商品的某一个配置的编码，所以在这里你也可以理解为它就是商品的编码：

POST /XXX HTTP/2Host: xxx
{"receiveAddressId":"地址ID","skuId":"商品ID","qty":"1","activityWinId":"活动中奖ID","couponHistoryId":"","deliveryWay":1}

其他的参数，实际上根据单词的拆分翻译很容易理解它的意思，这里就不过多解释了，我们这里可以尝试修改商品ID为其他商品的ID看看是否可以平行越权0积分兑换其他的商品，例如iPhone13的skuId为1431169046078791682，实际测试之后发现是可以的，那么这里我们已经获得了一个高危漏洞：

但是，问题来了，大家眼中这个漏洞应该是已经结束了，不过出于严谨思考，国内SRC有可能会对漏洞进行降级，这是因为其一系列的前置条件过多，于是我尝试重放修改后的请求，发现只能兑换一次，之后就出现了礼品已兑换，不让我再兑换了，做过开发的都知道，这一定是后端的某个逻辑校验了某个值，再根据现有的请求参数就能定位到activityWinId，也就是活动中奖ID，这里如果存在越权是否就可以重复兑换了？或者说这里会不会存在校验不严谨的情况？由于该ID的长度过大，越权显然不可取，除非你可以获取到别人的ID，所以只能尝试删除该ID的值发送，果然，漏洞成功升级，这里我们不需要活动中奖ID依然可以兑换：

原文始发于微信公众号（凌驭空间）：经典案例 | 逻辑漏洞之零积分兑换iPhone