听说拼多多因漏洞被薅了200亿？

看到一个大新闻：拼多多在20日凌晨出现漏洞，用户可以领100元无门槛优惠券。一夜之间，被黑产、羊毛党和闻讯而来的吃瓜群众薅了个底朝天，直到第二天上午9点才将优惠券下架。网上传言这一波损失超过200亿，但拼多多官方很快回应：漏洞确有此事，但损失没这么多，不到千万，已报警，正在追回。

拼多多本来就是家争议颇大的公司，这次事件更是引发舆论热议。据说，这个优惠券本不能正常访问，而是有做黑产（利用互联网不正当牟利）的人挖到了一个漏洞，使得能从某个二维码入口领取到这个券，并把这个券散发出去。你别以为这是想劫富济贫，他们只是想拉足够的炮灰垫背，同时自己迅速将这个券兑换成话费、Q币等，以此获利。这事情从法律角度来说算得上“不当得利”，就算涉事账面金额真的有200亿，大部分也是可以追回的。所以，没吃到瓜的群众别懊悔，反倒是真占了便宜的，得考虑考虑了。

话说回来，可能有人要问了，怎么黑产就能弄出一个不存在的优惠券？我不了解具体漏洞细节，但从目前的信息来看，这个券在系统里肯定确实存在，有可能是内部测试或者某些特定条件下可以领。然而估计程序上并没有做更多的领取条件限制，只是隐藏了访问这个券的公开入口。就好比是有人在银行的某个保险柜里放了一笔钱，但没有上锁，觉得别人不知道这里藏了钱就没事。后来有人发现了，就把保险柜的位置告诉了所有人，那么每个人都可以过来拿钱。

讲道理，我没上锁也不代表你就能随便拿。但从一个开发者的角度来看，不做必要的权限验证、规则判断，以及特殊情况下的异常处理，仅仅通过隐藏公开入口来限制领取，这是极为低级的失误。让人忍不住想吐槽：拼多多那么有钱，招来的程序员咋这么不专业？而且为什么凌晨爆发的问题，到上午9点才封上，下架个优惠券也这么难吗？

不过吐槽归吐槽，不可否认的是，软件的 bug、缺陷、漏洞，这是永远不可能杜绝的。被人们看到的漏洞往往很低级，但考虑到软件产品的复杂度，以及开发进度、需求变更等客观情况，漏洞也并不是想象中那么容易避免。就在半个月前，知名民宿平台 Airbnb 就爆出过类似的大 bug：当你支付房费的时候，如果切换货币，价格并没有跟着变。你可以拿2000越南盾支付原价2000欧元的民宿。在计算机史上，类似的问题数不胜数，举几个知名例子：

• 1994年，英特尔的奔腾CPU芯片被曝出缺陷：会在精度要求很高的数学计算上出现问题，比如 (4195835/3145727)*3145727-4195835 这样的结果计算出来不为 0。最后英特尔为此付出 4 亿多美元更换芯片。就在大约一年前，英特尔的另一个芯片漏洞也波及了市面上绝大多数的电脑、手机和云服务器，这个我去年有文章科普过：关于这波IntelCPU漏洞，我见过最形象易懂的解释
• 1999年，美国航天局的火星极地登陆器在着陆时失联。后经调查认定，故障原因很可能是一个决定关闭推进器的数据位设置逻辑有误。
• 1991年海湾战争中，美国的爱国者导弹防御系统失效，未能成功拦截导弹致28名美军士兵被炸死。原因经分析后，是因为系统时钟数据精度不够，存在微小误差，长时间运行后误差积累放大，在拦截过程中可能引起数百米的偏差。
• 千年虫问题：上世纪早期的软件开发者为了节省空间，使用两位数记录年份。然而到2000年时，一些软件仍在使用，使得99年之后变成00年，引发异常。有人估计全球为此花费的相关费用有数亿美元。

由此看来，程序员还真是一个高危职业，一不小心就可能造成巨大损失。如果你没有生产过严重的 bug，可能是你运气真的好，但更可能是你代码写得还不够多。对此我自己也是不少血泪教训。那面对难以避免的 bug，开发者应该怎么办呢？我的建议：

1、重视软件测试

正因为漏洞的普遍存在，以及可能带来的潜在损失，所以软件测试是即为必要的。除了需要有专门的测试人员把关，每个合格的开发者也应该是一个合格的测试者，正如有句话说的：一个优秀的程序员就是那种即使是过单行道都要往两边看的人（Doug Linder）。对于自己写出的代码，你自己是最了解的人。在开发早期就做好单元测试，可以大大提升程序的稳定性，降低后期测试的成本。当你写的每个函数都通过单元测试，成为一个功能模块时，再进行集成测试；最后对整个完成的产品进行系统测试。

企业更是应当重视软件测试的必要性，如果只追求功能快速迭代，拼命赶进度，最后有可能得不偿失。因为 bug 或操作失误导致企业破产的例子也不鲜见。

测试的方式一般分为黑盒测试和白盒测试。上面说的开发者自测一般是白盒测试，即你对代码的实现逻辑是已知的。白盒测试在选取测试用例时，讲究对代码逻辑的覆盖，即你选用的测试数据要能保证让每一行代码每一个条件都被执行到，尤其是一些边界条件。而黑盒测试是指不考虑代码逻辑，仅关注程序的功能和输入输出。软件发布测试版让用户使用，就属于一种黑盒测试。在黑盒测试时，讲究对等价类的覆盖，通俗地讲就是覆盖到所有可能发生的情况，包括正常的和不正常的，同样要注意边界。

我们码上行动有个期中项目，就是对教程中“猜数字”游戏的扩展，增加多次游戏的功能。看似简单的功能，实现起来不难，但几乎大部分同学提交的代码都会存在一定的缺陷。这就是由于编程新手缺乏测试的意识和方法，一般只会按照自己的设想输入，发现结果对了就认为大功告成。其实不然，你得考虑用户如果猜的数字超过范围怎么办？输入了小数怎么办？输入空白怎么办？输入了字符怎么办？……

那测试做到什么程度才到位？我觉得知乎上有人分享的一个笑话很到位：

一个测试工程师走进一家酒吧，要了一杯啤酒 一个测试工程师走进一家酒吧，要了一杯咖啡 一个测试工程师走进一家酒吧，要了0.7杯啤酒 一个测试工程师走进一家酒吧，要了-1杯啤酒 一个测试工程师走进一家酒吧，要了2^32杯啤酒 一个测试工程师走进一家酒吧，要了一杯洗脚水 一个测试工程师走进一家酒吧，要了一杯蜥蜴 一个测试工程师走进一家酒吧，要了一份asdfQwer@24dg!&*(@ 一个测试工程师走进一家酒吧，什么也没要 一个测试工程师走进一家酒吧，又走出去又从窗户进来又从后门出去从下水道钻进来 一个测试工程师走进一家酒吧，又走出去又进来又出去又进来又出去，最后在外面把老板打了一顿 一个测试工程师走进一 一个测试工程师走进一家酒吧，要了一杯烫烫烫的锟斤拷 一个测试工程师走进一家酒吧，要了NaN杯Null 1T测试工程师冲进一家酒吧，要了500T啤酒咖啡洗脚水野猫狼牙棒奶茶 1T测试工程师把酒吧拆了 一个测试工程师化装成老板走进一家酒吧，要了500杯啤酒并且不付钱 一万个测试工程师在酒吧门外呼啸而过 一个测试工程师走进一家酒吧，要了一杯啤酒';DROP TABLE 酒吧 测试工程师们满意地离开了酒吧。然后一名顾客点了一份炒饭，酒吧炸了

via 知乎 @今日飞雪 https://www.zhihu.com/question/20034686/answer/52063718

更多关于测试的知识，欢迎大家找本《软件测试》相关书籍看一看，这个真的很有必要。

2、相信墨菲定律

墨菲定律：如果你担心某种情况发生，那么它就更有可能发生。

测试做得再好，也只能是减小 bug 的概率。作为一个开发者，你还是要认清现实，做好最坏的打算。

• 如果你要上线新功能，那很可能导致宕机
• 如果你要更新数据库，那很可能会丢失数据
• 如果你没有检查备份，那很可能它就恢复不了
• 如果你搞一个促销活动，那很可能会被羊毛党撸死
• 如果系统出现了漏洞，那很可能是在半夜
• ……

但真当你意识到这些绝望的时候，反倒可以提前做好应急预案，将损失限制在最小。如果拼多多在设置出100元无门槛券的时候就想到虎视眈眈的黑产羊毛党，可能事情就不会这样。不过也许现在就是他们的应急预案也说不定呢：控制损失的同时还赚了一大波曝光。世事难料啊！

换个角度，能造成巨大损失也是一种幸运。相比之下，你的产品挂了两天都没人发现，域名过期了都没人跟你抢，那才叫悲惨。所以最后，希望各位有朝一日都能参与影响巨大的项目，但要有安全意识，千万别捅出大篓子