鲁达 在移动互联时代，每个人的智能手机上都安装了各种各样的 APP，那我们在使用这些 APP 的时候都会用到找回密码这个功能，这个功能极大的方便了用户，但是如果这个功能没有做好，或者对于测试工程师来说，如果没有对这个功能测试好，也会造成一些严重的后果，比如，任意用户密码重置，用户数据泄露等一系列安全问题。这个看起来很简单的功能，却被开发工程师挖了很多坑，我们一不小心就会掉下去。下面我们就一起探讨一下，APP 找回密码这一功能中的那些坑。
APP 端的手机找回密码流程通常如下：输入手机号-获取短信验证码-设置密码如下图：
图 1：
图 2：
坑 1：验证码没有和手机号绑定
测试过程：找回密码时，输入自己的手机号点获取验证码，此时验证码会发到自己手机上，输入获取到的验证码，这个时候再修改手机号为 B（B 也是注册用户），点下一步进行设置密码。查看是否可以重置成功。实际测试过程中，某些 APP 竟然可以重置成功。也就是说用自己的手机获取的验证码，重置了用户 B 的密码。这个坑是个明显的逻辑漏洞，很明显程序并没有把验证码和手机号进行绑定，只要验证码是合法的，就可以重置任意用户的密码，一个小小的逻辑错误，导致了一个严重的后果，如果做为测试人员，没有测试出这样的问题，在市场上让用户反馈回来，是否会追究我们的责任，这还得看老板的心情。感觉这样的开发人员一定和测试有仇，要不怎么会挖个这样的坑。
坑 2：短信验证码出现在返回的数据包中
大家都知道，一般我们 APP 客户端和服务器交互走的都是 HTTP 或者 HTTPS 协议。对于 HTTP 协议来说，我向服务器发送一条请求信息，那服务器必返回一条响应信息。而发送给用户的验证码，竟然也在服务器返回的数据包中。那意味着任何人都可以获取到这个验证码，有了验证码就可以重置密码。此时验证码形同虚设，重置别人的密码变得如此简单，你怕不怕？
测试过程：这个测试过程要借助抓包工具，这样的工具很多，大家可以随意选择。我这里用的是 Fiddler ，首先设置手机代理上网，手机网络应和电脑处于同一个 WIFI 下面，代理端口设置成和 Fiddler 上和端口一致。具体设置教程可自行网上搜索，设置好
后，启动 APP，进行抓包。
在找回密码，点获取验证码时，查看 Fiddler 抓取到的数据包，查看服务器的响应信息是否包含了发送到手机上的验证码。如有，那恭喜你中奖了。如下图某 APP 获取验证码抓包截图：
另一种情况，有些开发人员也许有些安全意识，他们验证码虽然出现在了响应信息中，但他们对验证码进行了 md5 加密处理，他们以为这样便高枕无忧了，然而并没有什么卵用。对这样的纯数字仅 6 位的 md5 加密数据，破解起来其实没有一点压力。许多网站提供免费的破解。
又如下图：
坑 3：在本地验证服务器的返回信息，确定是否执行重置密码
如上面所说，APP 找回密码一般分两个步骤，第一步验证“验证码”的正确性，只有验证码正确了，才会跳转至第二个步骤，设置密码。那我们的思路时，能否跳过验证码这一步，进入到修改密码页面？
测试过程：首先在找回密码第一步中输入自己的手机号和正确的验证码，点下一 步，同时抓包，观察服务器的返回信息，如下图中的例子，此例中如果验证码正确那么服务器返回“Code:”:0，如果验证码错误服务器则返回“Code:”:1
前提设置手机代理上网，然后在找回密码第一步输入手机号点获取验证码，随意输入验证码，此时设置抓包工具 Fiddler 中断服务器的响应信息。然后点下一步，查看抓包会发现服务器做出了响应，Code:1，意味着服务器判断验证码是错误的，并准备将此信息告之客户端，但是由于我们在 Fiddler 上进行了设置，此响应信息并没有发给客户端，而是处于中断状态，我们手动将此信息改为 Code:0，如下图。然后将此信息发给客户端。此时你会发现客户端自动跳转到修改密码页，输入密码后，密码重置成功。
在此我们虽然输入了错误的验证码，但修改了服务器的返回信息，客户端看到服务
器返回的信息后，认为验证码验证通过，就进入了第二步设置密码。
坑 4：在第二步找回密码的时候，没有再次对验证码进行验证
为什么进入设置密码时还要再次验证“验证码”，验证码不是之前已经验证过了
吗？相信大家都会有这样的疑问。再次验证验证码是否有必要？回答是肯定的，之前说的第三个坑，如果在设置密码时再次验证“验证码”即使跳过了第二步，重置密码也不 会成功。
由于 HTTP 自身的无状态特性，所以我无需先执行完验证验证码的 HTTP 请求后， 再去执行设置密码的 HTTP 请求，换句话说，我可以对重设置密码这个接口直接发起请求，同样可以轻易的重置密码。
如下图某 APP 找回密码第二步设置密码时的接口，并没有对验证码再次验证，那我就可以对这个接口发起请求，修改 Username 这个字段就可以达到重置任意用户密码的效果。
坑 5：验证码的提交频率没有做相应的限制
对于验证码其实我们还应该这样测试：
故意输入一个错误的验证码，然后不断点注册，查看 APP 反应。如果 APP 一直提示验证码错误。意味着这个 APP 没有限制提交次数.那验证码这一块就会存在一个可以被别人破解的风险。
如果验证码是四位，那最多请求 9999 次，就可以破解验证码.如果是 6 位，那时间会长些，但那只是时间问题。
也许你会说，我的验证码有时效如 4 位的验证在 120 秒后就失效。你请求 9999 次
会用多久？同学你也许忘记了，现在借助工具 4 位的验证码，一般几秒钟就可以破解了。所以对于这个问题，应该限制用户的提交频率。
结论：来自客户端的数据流都应被视为不可靠的，不能被信任的，应该在服务端对其进行校验。
ps:有需要测试软件课程可关注小编