子弹短信的拉新漏洞，我花了一个小时写了个并发脚本就测出来了。估值几十亿的明星产品，底层安全设计跟纸糊的一样。我不关心它能不能干掉微信，我只关心它的风控到底有多烂，现在看来，烂透了。
短信验证码接口是这类产品的命门。我抓了它的注册流程包，发现发送验证码的请求参数极其简单，手机号明文传输，连个时间戳签名都没有。更离谱的是，它的频率限制形同虚设。我写了个简单的多线程脚本，用十个虚拟手机号段轮流去撞那个接口，脚本逻辑就三块：构造请求头模拟正常浏览器、随机生成国内手机号、用threading开五个线程并发发送POST请求。结果呢？接口响应速度极快，几乎没延迟，每个请求都成功返回了“验证码已发送”。这意味着什么？意味着黑产可以用低成本的短信轰炸平台，轻易地对任意手机号进行SMS Bombing，或者用接码平台海量注册账号，把它的拉新补贴薅到渣都不剩。
这根本不是技术难题，是产品经理和研发在极速上线压力下的集体失职。防羊毛党的基础风控策略至少要包括：同一IP单位时间请求次数限制、同一手机号获取验证码的冷却时间、请求参数签名防篡改、图形验证码或滑块验证在频繁请求后的触发机制。子弹短信这几条几乎都没做扎实，或者说，在爆发增长期主动选择了降低安全门槛来换取注册转化率。这种策略在互联网蛮荒期也许能跑通，但在2018年，黑产工具链已经高度工业化的情况下，就是自杀。
我那个脚本跑完一轮只用了不到五分钟。看着控制台里刷刷刷的“200 OK”日志，心里没有一点技术验证的快感，只有一种荒诞的鄙夷。多少创业公司死在补贴被黑产撸光的故事里，但轮到自己做产品时，还是抱着侥幸心理，把本该夯实的底层架构押注在“黑产没那么快发现”的赌桌上。这不是技术问题，是商业逻辑的短视。
拉新补贴是烧钱，但防刷机制是省钱，更是保命。连我这种野路子产品经理用业余时间写的黑盒安全测试脚本都能轻易捅穿的防线，在真正的黑产大军面前连一分钟都撑不住。等数据异常、补贴预算瞬间蒸发的时候，再回头补窟窿就晚了。这次测试给我自己敲的警钟比给别人的更响：未来我做任何带补贴和用户激励的模块，第一页PRD就必须把风控逻辑和异常监控方案写死，宁可让正常用户多一步操作，也绝不给黑产留一道后门。增长不能靠裸奔。
