【转】渗透笔记之密码重置漏洞发现
前言记录一次密码重置漏洞的发现过程和一些思考，和大家一起分享，一起进步。
发现
按照我的个人习惯,子域名爆破先走一波,将爆破出的域名导入到goby之中再来一波扫描看看资产分布有没有什么比较明显的漏洞点，没有发现明显的漏洞之后x-ray联动rad再走一波，一顿操作之后，能够了解到目标的资产分布情况。
接着从网站的功能逻辑入手，看看有没有比较明显的逻辑漏洞。（通常情况下我会从人员注册 登录 重置(密码找回)的这样一个闭环的功能开始测试）
注册的流程很简单，而且没有做二次验证（通过短信或者邮箱验证），其实在这一步我就冥冥之中察觉到开发偷懒了或者是不太了解这块，这里大概率存在一些安全问题。
验证密码找回的功能
回答对一个问题就可以执行密码重置功能。（单因素认证，没有安全性可言）
我决定仔细看下密码重置的功能（按照之前的注册和密码找回功能几乎没有做安全策略，这里的密码重置功能极大概率会存在安全漏洞）,这里我使用的是burpsuit看看这个功能的具体发送的请求是怎么样的。
用户名密码采用的是明文传输，这里传递的id应该对应的应该就是登录账号的用户名（如果我能知道管理员账号的id对应的就能已管理员的身份进行登录了）
验证
为了验证这个想法，我又注册了另外一个账号 账号为test0506 对应id为253。
重新修改传参，将id修改为了252（对应账号为admin123） 密码修改为了qwerty。如果我的想法没错那么admin123的账号密码会被修改为qwerty。
修改成功（我通过test0506 这个账号登录 修改了admin123这个账号的密码）。
现在试下登录 账号admin123 密码为qwerty（type修改为text可以查看到密码）
登陆成功了，现在我已经拥有了修改这个系统的任意账号密码的能力。
后记
漏洞本身触发的方法很简单，但是以一个开发者的角度去看这个问题能引发我很多思考。
我们应该如何让自己设计的身份认证系统变得更加安全可靠（以下仅以我个人经验而言，希望能够达到一个抛砖引玉的效果）。
1.设置多因素校验（无论是邮箱还是手机绑定验证码校验 多一个身份认证或限制规则相当于多了一道门禁，系统将会变得更加安全）。
2.设置token认证（早在2000多年前秦人就知道用虎符来做身份验证，基于这套方案我们也有现实的实现 例如JWT等等…… 我们应该多参考成熟的设计方案）。
3.作为开发者，特别是涉及到一些敏感数据的功能，开发之前应该要多琢磨多思考多去参照成熟的方案设计而不仅仅是功能的实现。
初次投稿写的不好不对的地方大家请指正，如果这篇文章对你有所启发,希望大家多多评论点赞,我会继续写这种实战笔记和大家一起学习进步,谢谢。
厉害。
页:
[1]
