芯查查开发板组装游戏公测送Pico,Pico不算多贵,毕竟是公测,找漏洞还是主要任务。
问题
兑换ID累加而非随机
元件兑换码是15位数字,例如529772844564186
,看着很安全对吧?
但是他的APP分享链接是这样的:
https://app-h5.xcc.com/mobile/friend/puzzle/give?redeemId=13
看到后面那个redeemId
没有,那个是累加的,而非随机。
也就是说,可以通过穷举redeemId
来达到将所有人分享的元件兑换掉。
这个漏洞太明显了,开发肯定偷懒了,而且估计没有内测直接公测,不然应该早发现了。
想起以前写的短链接网站,mysql主键一加、自增一开,长链接往里面一丢返回个自增的id,直接用自增id作短链接,不知道芯查查这个redeemId
的原理是不是这样。
每人每天兑换次数无上限
这个本身问题不大,正常情况下一个分享一个兑换没什么问题,最多就是有些无聊的人会AB两个账户互相分享刷服务器资源。
但是结合上面的漏洞,一个人就可以兑换光所有兑换码,两者结合算是一个严重的漏洞了
抽奖随机程度不足问题
基本上连抽抽中的都是前一个元件,随机性差。
看着抽中这堆按键陷入沉思。
助力不方便问题
在微信中助力,打开后需要转跳到浏览器,转跳到浏览器后还要再转跳到APP,十分麻烦。
题外话
助力链接id也是累加的,不过这个没影响,就是感觉改成userid
应该方便。
https://app-h5.xcc.com/mobile/friend/puzzle/get?helpId=666
解决
陌生人刷元件问题
方法一
将redeemId
生成方式由累加改为随机生成,结合大小写字母和数字或者多位纯数字。
方法二
限制每人每天兑换次数上限,这个只能是临时方法。
因为即使限制每人每日兑换上限,依旧可以兑换陌生人分享的元件,当用户量起来后依旧是个问题。
只适合在使用方法一改代码期间临时用。
随机性问题
改进随机算法。
助力不方便问题
方法一
直接像淘宝拼多多那样在聊天框分享字符串,复制后打开APP自动识别。
方法二
基本操作同方法一,但把复制助力字符串的方法改成赠送元件的那样,打开网址后复制。
好处
- 能展示活动信息,估计这也是设计
redeemId
而不是直接使用redeemCode
的原因。 - 直接对
helpId
处理后展示就好,改起来方便
半夜帮别人找BUG,自愿加班了属于是,还没工资。
不知道能不能奖我块RPI Zero 2W [滑稽]。
2022-04-13 更新
昨天的问题情况
刷元件问题
刷元件问题解决,如下为现在的链接:
https://app-h5.xcc.com/mobile/friend/puzzle/give?redeemId=647293849
相比于原来的累加,现在使用了9位随机数作为redeemId
,通过遍历获取redeemCode
的漏洞解决了。
9位数有约10亿个号,目前公测有842名参与活动的用户,即使第二期增加100倍也足够用了。
助力不方便问题
目前没改,毕竟只是影响体验不是漏洞,不急。
今天的新问题
助力、点赞界面设计问题
活动图如下:
例如好友助力的计算方式:
拉1人 - 2次
拉3人 - 3次
拉5人 - 5次
拉6人 - 7次
拉9人 - 10次
以5人为一个循环,以此重复。
但是图中并未标明,加上文字说明“累计助力值可增加对应次数”以及图片中的“1人、3人、5人”,很容易让用户误以为每人活动期间只能让人帮忙助力5次。
新问题解决方法
助力、点赞界面设计问题
拿点赞举例,可以在前面加一个上一次循环的个数,下面的1次、2次改为+1次、+2次:
但上面的方法有个缺点,一是如果多人点赞达到了三位数,有可能放不下或者不美观。
如果把上面的次数也改成+感觉就好多了,而且左边还有足够空间放上一循环点赞数: