渗透测试

实战案例——可重置任意用户密码

字号+ 作者:轩辕攻防实验室 来源:转载 2018-03-21 11:44 我要评论( )

知识预热: 任意用户密码重置的常见姿势 1 验证码不失效 造成原因:找回密码的时候获取的验证码缺少时间限制仅值判断了验证码是 够正确未判断验证码是否过期 2.验......

知识预热:

任意用户密码重置的常见姿势

1 验证码不失效

  • 造成原因:找回密码的时候获取的验证码缺少时间限制仅值判断了验证码是
    够正确未判断验证码是否过期

2.验证码未绑定用户

  • 造成原因:输入手机号和验证码进行重置密码的时候,仅对验证码是够正确进行了判断,未对该验证码是否与手机号匹配做验证。

3.修改信息时替换字段值

  • 造成原因:在执行修改信息的sql语句的时候,用户的密码也当作字段执行了,而且是根据隐藏参数loginid来执行的,这样就导致修改隐藏参数loginid的值,就可以修改他人的用户密码。

4.修改接收的手机或邮箱

  • 造成原因:用户名、手机号、验证码三者没有统一进行验证,仅判断了三者中的手机号和验证是否匹配和正确,如果正确则判断成功并进入下一流程。

5.本地验证的绕过

  • 造成原因:客户端在本地进行验证码是否正确的判断,而该判断结果也可以在本地修改,最终导致欺骗客户端,误以为我们已经输入了正确的验证码。

6.跳过验证步骤

  • 造成原因:对修改密码的步骤,没有做校验,导致可以直接输入最终修改密码的网址,直接跳转到该页面,然后输入新密码达到重置密码的目的。

7.未校验用户字段的值

  • 造成原因:在整个重置密码的流程中,只对验证码和手机号做了校验,未对后面设置新密码的用户身份做判断,导致在最后一步通过修改用户身份来重置他人的密码。

8.修改密码处id可替换

  • 造成原因:修改密码的时候,没有对原密码进行判断,且根据id的值来修改用户的密码,类似的SQL语句:update user set  password="qwer1234" where id = ‘1’修改数据包里的id的值,即可修改他人密码。

9.cookie值的替换

  • 造成原因:重置密码走到最后一步的时候仅判断唯一的用户标识cookie是否存在,并没有判断该cookie有没有通过之前重置密码过程的验证,导致可替换cookie重置他人用户密码。(cookie可指定用户获取)

攻击展示(漏洞已修复):

首先是密码找回页面:

随便输个名字,就admin吧,存在的。
只有手机验证,那么开burp抓包,发现手机号是没有经过处理在请求包里的。

在网页的源代码里也是一样。

接着仔细查看了下源代码,发现密码找回验证后有个页面链接。

访问后是这样一个页面:

由此,在第二步邮箱验证和手机验证的时候,输入地址栏后替换成/forgetpwd/phoneValidateNext.do,设置新密码:XXXXXX.

验证登录:


本文来自: 蜗蜗侠's Blog-关注网络安全 http://blog.icxun.cn/Security/677.html

1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。

相关文章
网友点评
暂时未开启评论功能~