业务安全-任意用户密码重置的姿势总结

       随着网络安全发展到目前，最初最常见的注入、跨站、上传等Web安全问题基本得到大多数人的重视，目前常见的web扫描器也基本都能发现，业务安全却却日益成为网络安全的重要风险来源，而且各种逻辑问题也出现的五花八门。

       登录密码作为业务安全的第一道入口，是业务安全问题最高发的地方之一。本文把日常渗透及CTF见过的安全案例总结一下，希望能够尽可能全面的把关于重置用户密码的姿势作个归纳总结，仅仅起到一个记录的作用，具体的测试方法暂不加以详叙。

 一、验证码可爆破 （简单粗暴，不详叙了）

二、修改密码的过程分成了好几步（一般是输入用户名-输入验证码-输入新密码3步），前后没有关联。

     导致可以直接跳到第三步去修改密码。有的是通过本地判断相应的状态来跳转的，可以通过直接替换正确的响应包来到最后一步。

     这种情况还有就是在认证方法都是在前端js中完成的，js中可能会泄露隐藏的关键步骤逻辑，如正常到第三步修改密码的方法是update3，其实隐藏了一个update5方法，这个update5没有和前边关联从而直接被服务器验证通过。

三、HTTP响应包泄密

    最简单的就是直接响应包里把验证码回显了，不过除了CTF入门题里，实际再没见过这种了。

    另外一种就是重置密码的链接，是由用户的token拼接而成的，回显包里会显示拼接后跳转location，自行根据响应的token凭证拼接修改密码的链接即可。这种情况其实还有就是通过分析重置密码的链接，可以发现链接是有规律的，比如是用户名或者用户id的md5或者base64编码或者uriencode,或任意两参数的组合MD5或加入了时间戳组合的MD5等等，从而直接构造重置密码链接。

四、用户名或手机号与验证码没有进行一致性关联验证

     如用自己手机号收到的验证码重置其他用户的密码， 这种情况比较多，综合起来也最常见最容易出现问题。

简单的可能是直接能够修改接受验证码的手机号或者邮箱，复杂一点的可能是一致性校验不全面（如仅仅校验了手机号与验证码是否一致，而修改密码是通过用户名生效）。

Freebuf的文章有详细测试方法，可以参考：http://www.freebuf.com/articles/database/161495.html

http://www.freebuf.com/articles/web/162152.html

这种总结起来其实就是验证码（亦或是cookie、token）之类的凭证信息没有和实际用户做严格的绑定校验，如果是通过未登录状态的cookie进行绕过校验，就是经典的cookie混淆。

五、修改信息时替换隐藏字段

       这个是从乌云大神carry_your那涨姿势了。平时大家默认关注的都是正常的登录或者找回密码的逻辑。却没想到在更新用户信息的时候也能达到重置别人密码的目的。

       其实这个地方准备来说算是一种横向越权，造成原因就是在执行修改信息的语句时，用户的密码也当作字段执行了，而且是根据隐藏参数loginid来执行的，这样就导致修改隐藏参数loginid的值，就可以修改他人的用户密码。

所以修改个人资料的时候，不妨做下源码审计，看看前端是否有隐藏的字段不在post请求里。

 

上述的几种姿势，其实目前就常见度来说，验证码爆破和凭证信息未严格校验是最常见的，而凭证信息校验的情况也是最多最潜在的，很多看似安全的场景，仔细深挖这点的话，都可能会发现问题。

所以针对这种问题的防护，一定要将重置用户与接收重置凭证作一致性比较，直接从服务端直接生成，不从客户端获取。另外，密码找回逻辑中含有用户标识（用户名、用户 ID、cookie）、接收端（手机、邮箱）、凭证（验证码、token）等四个要素，在最后一步提交时必须完整关联，否则可能导致任意密码重置漏洞。另外，HTTP 参数污染、参数未提交等问题，服务端也要严格判断。