场景：

新用户注册界面。需要填写手机号，图形验证码，短信验证码，然后有个立即注册的按钮。我在设计测试用例的时候，只是考虑了一些常规的功能场景，比如数据长度、类型，是否可以执行 sql 注入类语句，以及绕过前端直接通过接口访问，一些可能的并发等，不细讲了。我还特意考虑了恶意用户通过脚本大量刷我们的短信验证码请求，造成短信成本提高的可能。

本来我以为这就够了，然而安全测试的同学一眼就看出了问题。在这个拉新成本越来越高的当下，注册页面不仅承载着拉新的任务，同时，他还可能存在着暴露客户信息的风险！

举个例子：一个正常的用户输入手机号，图形验证码，点击发送短信验证码，我们会校验手机号规则，校验图形验证码，然后查数据库校验，看这个手机号之前有没有注册过我们的 app。如果查到了，服务端就返回查询结果，前端展示给用户 “该手机号已经注册过”，同时取消短信验证码的请求。

乍一看没毛病，已经注册过了，就没必要花几分钱一条的短信验证码了不是？漏洞恰恰就在这里，我们的竞争对手，完全可以通过号码库大量穷举的方式来测试我们的注册接口，通过抓包工具屏蔽掉图形验证码的访问请求，直接暴力请求短信验证码接口，通过接口返回的信息，判断这个手机号是不是已经注册了这个 app，然后就可以得出一个结论，这个号码的主人可能有我们的产品相关的需求，然后就可以发动电话攻势抢客户了。我们本来考虑的节省短信费的手段，恰恰成为了可能丢失用户的隐患。

问题暴露了。解决之道却还很长，我们考虑了将图形验证码逻辑进行修改，只要请求了短信验证码接口，就将图形验证码置为失效状态；另外不论用户是否已经注册过，都将他引导到客户端下载页等等，想完全避免信息泄露不太可能，但是至少提高了用户非正常操作的成本。

今晚发高质量贴的大佬好多，我反反复复改了好几遍还是不太满意。只是感觉这是个可以分享的点，忍不住记录下来。文笔排版都欠佳，各位见谅，求轻喷。Or2