一、短信验证码回传
1、原理
通过手机找回密码,响应包中包含短信验证码
2、案例
某网站选择用手机找回密码:
点击发送按钮,拦截回包,可以查看到短信验证码,如下图所示:
3、修复建议
响应包中去掉短信验证码
二、修改用户名、用户ID或手机号重置任意账号密码
1、原理
通过手机找回密码是一般需要短信验证码验证(这里可以尝试爆破或绕过)。当我们输入正确的手机号和正确的短信验证码,然后进入重置密码的最后一步,也就是输入新的密码输入密码后提交到服务端的post数据包需要包含当前用户的身份信息。
而一般网站是通过用户名或用户ID来标识用户身份的,如果这个用户名或用户ID没有和当前手机号、短信验证码进行绑定;
也就是说服务端只验证用户名、ID是否存在,而不去验证用户和当前手机号是否匹配,那么我们就可以通过修改用户名、ID去修改其他用户的密码了。
当然可以修改的地方不限于找回密码的数据包,比如修改资料的地方也可能存在这样的漏洞。
2、案例
以某网站修改任意用户资料导致修改任意账号密码为例,截取的数据包为:
POST /user/info_do HTTP/1.1
Host: www.XXX.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:59.0) Gecko/20100101 Firefox/59.0
Accept: */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Referer: http://www.XXX.com/user/info_view
Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-Requested-With: XMLHttpRequest
Content-Length: 211
Cookie: yunsuo_session_verify=9341a54b945886e9485ff54a17650468; PHPSESSID=sgbibaqe7f8f6okerps8jip916; sdrcUserlockcount=1; sdrcUseruserid=14943
Connection: keep-alive
password=A123456&email=1%40qq.com&address=1&postcode=1&mobile=13888888888&sex=man&birthday=0000-00-00°ree=collegeLT&testsite=1&post=1&__hash__=b0b15b067dea00bd34fd39421b7ef684_efc2399e5c4b2071f261e75fe3362d4fa
经分析与尝试,发现数据包中的sdrcUseruserid的值是用来标识当前用户身份的,那么我们就想到这个id可否任意修改呢?
答案是肯定的,我们修改id的值为14942、14941都是可以成功的,截图如下:
3、修复建议
- 用户操作个人信息(读取、修改)时,服务端要对当前用户身份进行验证,防止越权操作;
- 用来标识用户身份的名称或ID可以使用自定义加密,也可以隐藏这些参数,直接从cookie中获取用户信息;
- 用户修改密码时应该先对旧密码进行验证,或者使用手机短信验证;
- 用户修改手机号时需要先对原手机号进行验证。
三、修改响应包重置任意账号密码
1、原理
通过手机找回密码一般需要短信验证码验证,服务端需要告诉客户端,输入的验证码是否正确。
如果客户端收到true的信息,那么就会向带着true的信息向服务端请求进入下一步,而服务端收到true的信息,就会允许客户端进入下一步。
反之,如果是false的信息,服务端就不会允许客户端进入下一步。
也就是说我们进入下一步的关键是让服务端收到客户端的true信息。
而借助burpsuite,我们可以修改服务端返回到客户端的信息,这样一来,我们就可以输入任意短信验证码,然后将服务端返回的false信息改为true就可以绕过短信验证码的验证了。
2、案例
下面是找回密码的一个流程,输入正确的用户名,跳到第二步,这时需要输入短信验证码,这里我们随意输入一个短信验证码:123456,然后抓取服务端返回的信息如下所示。
把回包中false改为true后,即可绕过短信验证码验证,结果如下图所示。
3、修复建议
- 服务端对验证码进行验证,结果为true时直接跳到下一步,无需向客户端单独返回验证结果;
- 输入新的密码,然后提交到服务端,服务端应对当前用户名、手机号、短信验证码进行二次匹配验证,都为true时,才可以修改成功。
四、跳过验证步骤重置任意账号密码
1、原理
找回密码流程一般需要四个步骤:
1、验证用户名;
2、验证短信验证码;
3、输入新密码;
4、重置成功。
这四个步骤应该紧紧相连,互相相关,只有通过了第一个步骤验证才可以进入下一个步骤,如果每个步骤之间没有进行关联性验证,就可能导致跳过关键验证步骤,从而导致重置任意账号密码。
2、案例
某网站找回密码有四个步骤,第一步输入正确的用户名,第二步输入手机号和正确的验证码,截取服务端返回的数据包为:
<html><head><title>object moved</title></head><body>
<h2>object moved to <a href="/Personal/sys/getpasswordreset" rel="external nofollow" >here</a>.</h2>
</body></html>
上述数据包是用来跳转到输入密码的界面。
我们猜想能否输入任意验证码,然后直接访问输入密码界面,结果是可以的,而且重置密码成功了。
经分析,此处成功的关键是页面跳转到输入密码界面,当我们输入新的密码后,提交到服务端,服务端并没有对当前用户身份进行二次验证,只是简单的获取到用户名或ID以及新密码,从而导致跳过短信验证码验证重置任意账号密码。
3、修复建议
- 每一个步骤都要对前一个步骤进行验证;
- 最后提交新密码时应对当前用户名或ID、手机号、短信验证码进行二次匹配验证。
五、重置密码链接中token值未验证或不失效导致任意账号密码重置
1、原理
使用邮箱重置密码时,服务端向邮箱发送一个重置密码的链接,链接中包含当前用户的身份信息(如用户名或用户ID)和一个随机生成的token信息,如果未对token值进行验证或是验证后不失效,我们就可以通过修改用户名或用户ID来重置任意账号密码。
2、案例
某网站使用邮箱找回密码时,服务端向邮箱发送的链接为:
http://www.xxx.com/GetPwd.aspx?q=0x0531387a5a6c1227e4d6ba0ce16dc72e&r=3244166
经尝试,此处未对随机生成的q值进行验证或是验证了但是验证之后未失效,导致可以重复使用,最终只需要修改r为其他用户ID,即可重置其他用户密码。
3、修复建议
- 服务端对客户端提交的token值进行验证;
- 保证token值使用一次后即失效,防止重复使用;
- 对用户ID进行自定义加密;
- 使用根据用户ID生成的token值来标识用户,链接中不携带用户ID。
六、找回密码的短信验证码可被爆破导致任意账号密码重置
1、原理
找回密码时使用位数较少的短信验证码,或者验证码没有设置有效时间限制,导致攻击者借助自动化工具在一定时间范围内爆破获得短信验证码,从而导致重置任意账号密码。
2、案例
某网站找回密码时使用短信验证码的一个数据包为:
Code=5000&u=13888888888&Check=dc5b94101cb4f23a9ce6ae71197fc5de&a=5
此处可以对Code进行爆破,如下图所示:
3、修复建议
- 验证码满足一定复杂度,且限制验证码生效时间;
-
验证短信验证码的数据包使用token值并验证,防止自动化工具爆破