做网站数据库要哪一种好百度广告投放代理商

1. 任意密码重置漏洞原理

厂商在对密码修改功能设计的时候，未对修改密码的凭证做严格的限制，导致可以被绕过进行任意的密码修改。

2. 任意密码重置漏洞产生原因

3. 任意密码重置漏洞场景

3.1 验证码爆破

表现：

• 验证码四位，服务端未对验证时间次数进行限制（出现次数比较多的地方）；
• 验证码六位，但是不过期（时间很久），并且没有对验证的次数进行限制；
• 验证码可以发送多次，而且每次都不会过期。

利用：使用burp的爆破模块即可，或者自己编写脚本。

修复：使用六位验证码，限制验证码认证次数。

案例流程：

• 重置密码发送手机验证码
• 发现验证码只有四位
• 利用burp进行爆破
• 爆破成功
• 重置密码

3.2 验证凭证回传

重置密码时，凭证为发送到手机上的验证码，但是通过拦截发送验证码请求对应的Response包时，发现验证码在Response包中。

重点：注意是凭证，有时候可能返回包里面凭证可能在cookie里面或者也有可能在其他地方。

解决方案：修改包的返回规则

案例：DeDecms任意密码重置

• DeDecms是用户使用最多的PHP类cms系统，CMS 系统，即内容管理系统（Content Management System），此次该CMS的任意密码重置漏洞，通过遍历UID的方式获取返回的静态gourl跳转地址，而CMS未对更改密码的跳转地址进行参数隐藏导致更改密码的临时密码被泄露，泄露以后构造URL传入临时密码，可以不需要任何验证即可更改任意用户密码。

3.3 验证凭证未绑是用户

输入手机号和验证码进行重置密码的时候，仅对验证码是否正确进行了判断，未对该验证码是否与手机号匹配做验证。

表现：

• 1.任意账号都能够接收到验证码并能够使用A手机的验证码，B可以拿来用
• 2.A账号的修改密码连接，B账号可以拿来用

修复：

• 1.在服务器进行有效验证，手机号和验证码在服务器进行唯─性绑定验证。
• 2.在服务端限制验证码发送周期，设置时效，限制次数

常见案例：

• 首次登录账号之后需要你绑定邮箱、手机号等情况。
• 在绑定的时候修改绑定的账号id即可把自己的手机号等绑定到别人的账号上面。

3.4 跳过验证步骤

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

测试：首先使用自己的账号走一次流程，获取每个步骤的页面链接，然后记录输入新密码的对应链接。重置他人用户时，获取验证码后，直接进入输入新密码对应链接到新密码的界面，输入密码重置成功。

3.5 凭证可预测

token可预测：使用邮件接受重置密码的链接时，一般都会带有一个token用于判断链接是否被修改过。如果token可以预测，那么攻击者可以通过构造链接来重置任意的用户密码。

表现:

• 1.基于时间戳生成的Token
• 2.基于递增序号生成的token
• 3.基于关键字段生成的token
• 4.token有规律
• 5.验证规则过于简单

3.6 同时向多个账户发送凭证

将发送验证码的包截获，修改字段添加多个账户，再发包。发现所写的有效字段均发送了凭证。

4. 任意密码重置经典案例

4.1 中国人寿某重要系统任意账户密码重置

直接修改验证返回包即可重置密码，链接地址：https://cn-sec.com/archives/1557.html

其他相关案例：

• 中国人寿任意用户密码重置二
• 中国人寿任意用户密码重置（秒改）用户保单信息全部泄漏

4.2 米鼠网设计逻辑的缺陷可重置任意用户密码

手机号没有经过处理直接在请求包里看到，并且在源码里找到重置密码链接即可直接重置密码。链接地址：http://cn-sec.com/archives/724.html

5. 权限绕过漏洞

越权漏洞的成因主要是因为开发人员在对数据进行增、删、改、查询时对客户端请求的数据过分相信而遗漏了权限的判定。越权又可以分为两种：水平越权与垂直越权。

5.1 水平越权

水平越权就是相同级别（权限）的用户或者同一角色的不同用户之间，可以越权访问、修改或者删除的非法操作。如果出现此类漏洞，那么将可能会造成大批量数据泄露，严重的甚至会造成用户信息被恶意篡改。

比如同一公司的员工 A 和 B，分别只能查看自己的一些个人资料，但是如果系统存在水平越权漏洞，则 A 可以通过这样个漏洞查看到 B 的资料。

水平权限漏洞一般出现在一个用户对象关联多个其他对象（个人资料、修改密码，订单信息，等）、并且要实现对关联对象的 CRUD 的时候。开发容易习惯性的在生成 CRUD 表单（或 AJAX 请求）的时候根据认证过的用户身份来找出其有权限的被操作对象 ID，提供入口，然后让用户提交请求，并根据这个 id 来操作相关对象。在处理 CRUD 请求时，往往默认只有有权限的用户才能得到入口，进而才能操作相关对象，因此就不再校验权限了。可悲剧的是大多数对象的 ID 都被设置为自增整型，所以攻击者只要对相关 id 加 1、减 1、直至遍历，就可以操作其他用户所关联的对象了。

案例：

• 一次水平越权，导致平台两万人被修改密码
• 小天才电话手表官网存在水平越权操作漏洞（影响用户积分安全）

5.2 垂直越权

水平越权是相同级别的用户之间的越权操作，而垂直越权则恰恰相反，是不同级别之间或不同角色之间的越权。

垂直越权又被分为向上越权与向下越权。比如，某些网站，像发布文章、删除文章等操作是属于管理员做的事情，假设一个低权限用户或者根本没权限也可以做相同的事情，这就叫作向上越权,

向下越权与向上越权恰恰相反，向下越权是一个高级别用户可以访问一个低级别的用户信息。这样做似乎没错，而且很多网站都是这么做的，包括低级别密码也可以被高级别用户掌控，但这样做可以说是完全错误！因为即使权限再低的用户都有他自己的隐私，可能用户为了更方便，会将自己的银行卡号与密码记录在网站中，这些信息都属于用户的隐私。

案例：

• Couchdb垂直权限绕过到命令执行