芯查查开发板组装游戏公测存在的一些问题和解决

芯查查开发板组装游戏公测送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自动识别。

方法二

基本操作同方法一，但把复制助力字符串的方法改成赠送元件的那样，打开网址后复制。

好处

1. 能展示活动信息，估计这也是设计redeemId而不是直接使用redeemCode的原因。
2. 直接对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次：

但上面的方法有个缺点，一是如果多人点赞达到了三位数，有可能放不下或者不美观。 如果把上面的次数也改成+感觉就好多了，而且左边还有足够空间放上一循环点赞数：