今天分享的Writeup是一个有趣的账号劫持漏洞，漏洞原因在于目标服务端重置用户密码时，其Token生成算法有问题，存在可预测和可枚举可能，导致网站注册用户面临账号被劫持风险。

这里我们把目标服务端称为program.com，当我在测试其忘记密码功能时发现一个怪异的现象，每次我对我当前账号发起密码重置请求后，在我收到的下述密码重置Token信息中，其Token串中的前3个字符都是一样的，所以这引起了我的注意。

https://program.com/forgot_password/<TOKEN-HERE>

几分钟后，我惊奇地发现Token信息中的前3个字符，是我在目标网站时绑定注册邮箱前缀中，从第4个字符住前反向排序到第2个字符的3个字符。也就是说，假设我在该网站的注册邮箱为 johndoe@domain.com ，那么我发起密码重置请求后，在我邮箱中收到的重置Token信息其前3个字符就是“nho”（无引号），如下：

有了这个发现，我想那么Token信息中剩余字符应该也存在某种意义吧，于是，经我多次的测试分析，发现其余字符就是当前的时间戳信息（Timestamp）。但是，最后，还余下2个字符我无法找到规律，这两个字符位于前3个字符和后部份时间戳字符之间，它们可能是随机生成的。

我想，如果是随机生成的话，那就来暴力枚举试试看，非常好的是，目标服务端竟然毫无任何速率限制措施。这里，我用两个注册邮箱来进行测试，一个当成受害者邮箱的johndoe@domain.com，另一个当成攻击者邮箱的johndoe@domain2.com，可以看到它们前缀都是相同的。在测试中，我同时向目标服务端对该两个邮箱发起了账户密码重置请求，由于它们的邮箱前缀都是相同的，所以，在服务端发送回来的密码重置Token中，除了那2个随机字符之外，其余的Token字符应该是一样的。

这样，我可以登录作为攻击者的邮箱johndoe@domain2.com，从中获取包含Token信息的密码重置链接，然后，针对该密码重置链接请求，在Burp Instruder中构造字典文件进行暴力枚举。果然，不一会儿，在不多的请求发出之后，我成功地枚举到了一个302跳转的有效密码重置请求。

该漏洞上报后，厂商把该漏洞定级为P1严重级，及时进行了修复。

*参考来源：medium，clouds 编译整理，转载请注明来自 FreeBuf.COM