逻辑漏洞——验证机制问题

普吉应用系统验证机制的脆弱点以及验证机制中的设计缺陷、执行缺陷

验证机制

身份验证是核心防御机制中最薄弱的环节，身份验证机制也是攻击者的主要攻击目标之一。
验证机制是应用程序防御恶意攻击的中心机制。它处于防御未授权的最前沿，如果用户能够突破那些防御，他们通常能够控制应用程序的全部功能，自由访问其中的数据。缺乏安全稳定的验证机制，其他核心安全机制（如会话管理和访问控制）都无法有效实施。
验证机制最常见的方式是信息系统要求用户提交用户名与密码，正确则允许用户登录，错误则拒绝用户登录。

验证机制问题主
要分为两个方面：分
别为设计缺陷和执行
缺陷。

Web应用程序常用的验证机制有：
基于HTML表单的验证（最常用）
多元机制，如组合型密码和物理令牌（多用于安全性要求较高的应用程序比如说提供进行巨额交易服务的私人银行）
客户端SSL证书或智能卡（成本非常昂贵，通常只有那些用户不多的安全性极其重要的应用程序才会使用）
HTTP基本和摘要验证（内网使用较多，建立在域环境及内网对用户的访问控制之上的）
使用NTLM或Kerberos整合windows的验证
第三方验证服务（尚未得到大量使用）

验证机制设计缺陷

可预测的用户名
有些应用程序需要用户注册时用户名符合某一特定规则，比如需要满足“姓名缩写
数字”的这种形式，其中数字是为了防止用户名重复，也就是说如果在存在姓名缩写相
同的情况下后面要跟数字或者进行数字累加。这种在学校邮箱注册时是比较常见的。通
过这种方式攻击者可以很方便的获得大量有效用户名。

极少部分的应用程序不要求用户名的唯一性，这就可能造成这样的问题
在恰巧有两名用户使用相同的用户名及密码的情况下，应用程序要么阻止第二个用户设置密码，要么允许其设置相同的密码。前者这种情况可能导致第一名用户的密码泄露给第二名用户，这种情况下攻击者如果想获得某个已知用户名对应的密码则可以通过注册功能针对于此用户名使用不同的密码注册，如果应用程序返回禁止注册，那么我们可以推测出此次注册时的密码就是这个用户名对应的密码。后者则可能导致第二名用户可以访问第一名用户的状态。

123456真的多。。。

密码确认不完善
一些应用程序在用户注册设置密码时，出于一些原因往往会对密码进行如下处理
截断前n个字符
大小写不敏感
删除特殊字符
上述操作均会减少应用程序的密码空间，攻击者通过仔细分析应用程序的密码处理规则后，可以适当修改自己的暴破字典从而提高暴破的成功率。

可预测的密码
在像学校，企业这种存在批量注册大量用户需求的应用程序中，经常会为批量用户设置默认密码，这种默认密码可以是相同的也可以是与用户名或者其身份证信息等有关系的。这种情况下攻击者可以通过Googlehacking来在公开信息汇总收集大量初始密码，也可以根据默认密码规律推测出大量密码。

暴力破解
              最常见的——暴力破解（BruteForce），也可称为童力攻击，指利用穷举法将所有的可能性一一尝试，理论上可以破解所有密码问题。实际测试中，考虑到攻击成本问题，通常使用字典攻击（DictionaryAttack），即逐一尝试用户自定义词典中的可能密码（单词或短语）的攻击方式。

如果应用程序允许用户在登录失败很多次后，仍能继续尝试登录，那么这种情况下此应用可能存在暴破攻击。为了防止暴破攻击，应用程序应该设置用户登录失败次数上限，当用户失败的登录次数达到上限后应用程序应该阻止用户进一步的登录。但是通过前端脚本或者Cookie来统计用户失败的登录次数是不可靠的，因为这些都是攻击者可以接触到并且可以修改的，如果服务器端使用Session来存储用户失败登录的次数这样就可靠的多。除了用户登录次数的统计问题外，如何处理失败登录次数达到上限的用户也是一个需要谨慎处理的问题，如果用户在登录失败很多次后被锁定，但是锁定状态下的用户使用正确密码登录时和使用错误密码登录时Web应用程序的响应信息不同那么此时此应用还是存在暴破漏洞。

实验：利用BurpSuite中lntruder模块进行字典攻击
一般步骤：
设置浏览器代理并抓取数据包
在Positions中，Clear目前payload，Add需测试payload位置
设置Payloadtype，选择payload
设置线程等参数，并Startattack
根据Response状态，判断攻击结果

验证机制执行缺陷

可利用信息
多余的提示信息
登录失败后，不应该提示如“用户不存在”、“密码错误”、“用户未注册”
等详细信息，通过这些信息可推断出用户名、密码等其他信息
可预测信息
类似user100、user101的用户名，手机号信息
类似于ABC123、123456的初始密码

在暴力破解的时候，若拥有验证码还需要绕过验证码，验证码常见的有图片验证码
和短信验证码。
图片验证码
验证码不生效/不更新/不失效
验证码可预测/删除/获取
验证码可识别
短信验证码
4/6位验证码
算改手机号
算改Response

案例：绕过验证码
查看其中的isVerfi参数，第一次传入1返回3没有得到验证码，但是修改参数为0之后返回2，绕过了验证码的限制

案例：某OA系统设计缺陷导致可暴力破解账户大量敏感信息泄漏
其中yongping/12345为管理员，权限很大

 

密码重置
在逻辑漏洞中密码重置问题是比较常见的一种场景，常见于用户修改密码页面、用户找回密码页面等涉及到网站重置密码功能的页面。
修改密码
目前的修改密码的方式大概可以分为两种，第一种是要求用户键入用户名、旧密码、新密码、确认新密码四部分，一些Web应用程序会忽略修改密码处旧密码错误输入次数过多的问题，这就容易被攻击者利用来进行密码暴破；还有一种最不安全的情况就是只需要用户键入用户名、新密码、确认新密码即可更改用户名相应的密码，这种情况下攻击者无需暴破即可获得正确的用户名及密码组合。

找回密码
忘记密码功能往往通过设置一组问题来验证用户身份，比如这些问题可以是“我最喜欢的颜色”，这些问题的答案组合次数相对于密码来说小的多，并且可以通过信息收集工作来提供辅助。攻击者可以收集一组用户名并逐个遍历然后记录相应的问题在其中选择最简单的那个下手可以获得更高的成功率忘记密码处可能不会设置错误次数限制从而允许攻击者猜测上述问题的答案通常Web应用程序也会设置密码暗示来代替上述问题，这些密码暗示往往能够辅助攻击者猜测密码，有些用户甚至直接把密码设置为密码暗示。攻击者同样可以通过枚举收集到的用户名然后获得一组密码暗示，从而寻找出最容易获得的密码

当Web应用程序可能通过向用户邮箱发送密码重置链接来帮助用户修改密码，这种链接是随机的攻击者很难对其进行猜解。但是有些应用在设计这个逻辑时可能允许Web应用程序将用户密码修复的邮件发送至攻击者，有时邮箱地址并没有直接显示出来而是存储在隐藏的表单中这时攻击者可以将邮箱修改为自己的邮箱。在最差的情况下攻击者可以尝试推测密码重置的URL来重置用户密码

常见密码重置问题
用户名枚举：网站反馈多余信息，可猜测用户信息
验证码返回前端处理：可截获、修改
修改Request：用户名、手机号、Cookie等信息可修改
修改Response：操作结果成功/失败可修改
暴力破解验证码：验证码长度有限，或验证码未设置可靠的失效时间
拼凌密码重置链接：重置密码链接有规可循

案例：修改Respone
填写验证码点击下一步，利用Burpsuit进行抓包，需设置Burp拦截Response包
若返回包中具有明显的参数字段，如yes/no、success/failed、0/1等字段，可以尝试修改为成功，或是走一遍正确的流程，记录成功的返回包

放包跳转至更改密码界面，可直接修改成功密码

一些应用程序为了方便用户访问通常会提供“记住密码”的功能，此功能通常仅通过cookie中的某个字段来实现。比如Cookie中会设置一个存储用户名的字段来实现基础我的功能如果这样的话攻击者仅需要随便注册一个用户然后将Cookie中用户名修改为其想要访问用户的用户名即可实现对目标用户的访问。Cookie中还可能通过存储一个ID字段来唯一的标识用户，这种情况下攻击者可以遍历ID从而实现遍历访问用户。

证书分配不安全
目前很多应用程序在注册时都会要求用户填入邮箱信息，并在稍后发送给用户一封激活邮件，如果邮件中保存有用户的初始用户名及密码并且这种邮件有没有及时的删除在邮件泄露或者邮箱被攻击者攻破的情况下，则会泄露应用程序的密码。除此之外有些激活URL可能存在某种规律，攻击者可以通过注册，连续地注册用户来观察这种规律，从而推测其他用户的激活URL。
证书传输易受攻击
如果Web应用程序在网络环境中以明文的方式传递证书，那么攻击者则可能通过嘎探、中间人等各种方式获取。

异常开放登录机制
验证机制在代码实现过程中也可能由于编码者某些疏忽造成安全问题。
使用控制的一个账户执行一次完整、有效的登录。使用拦截代理服务器记录提交的每一份数据、收到的每一个响应
多次重复登录过程，以非常规方式修改提交的数据。比如对于客户端传送的每个请求参数或Cookie
提交一个空字符串
完全删除键值对
提交非常长和非常短的值
提交字符串代替数字或相反
针对某一参数，尝试重复提交相同和不同的值

仔细检查应用程序对提交的每个畸形请求的响应，确定任何不同于基本情况的
差异
根据这些观察结果调整测试过程。如果某个修改造成行为改变，设法将这个修
改与其他更改组合在一起，使应用程序的逻辑达到最大限度

多阶段登录机制中的缺陷
有些对于安全性要求较高的应用可能会采取多阶段登录验证机制，比如一个多阶段验证机制可以有以下三个过程组成
提交用户名及密码
响应一个质询，答案可能使PIN中的特殊数字或者一个值得纪念的词
提交物理令牌上的值

多阶段登录机制确实可以明显的提高登录验证的安全性，但是更多的阶段同样意味着可能潜在有更多的执行缺陷。比如可能存在以下几个常见的缺陷
应用程序认为访问第三阶段的用户已经完成了一二阶段的认证。这种情况下仅拥有部分登录凭证的攻击者可以成功登录
在每个阶段的验证过程中，应用程序会保存相应的标志，比如账户是否过期、是否被锁定、是否属于管理员、是否需要完成更多的登录验证阶段。如果攻击者可以在某一个登录阶段接触到上一个阶段设置的标记，那么攻击者可以对这些标记进行修改从而完成一定程度的攻击行为

应用程序有可能会认为各阶段认证过程中用户的身份都不会发生变化，并且不会在每一个阶段检查用户身份的统一性，那么如果攻击者在第一阶段输入的用户名及密码与后面阶段输入的验证凭证不一致，且应用程序会以两种或三种验证凭证任一对应的用户身份登录的话，这就存在严重的安全问题。这种情况下攻击者只需要知道目标用户的部分验证信息就可以登录，而其他信息则可以通过自己注册获得部分信息，这种攻击的严重程度取决于应用程序用于确定用户身份的验证凭证的易获得度（比如应用程序以第一阶段的用户名及密码来确定身份，那么存在上述缺陷的情况下攻击者可以使用自己的后两个阶段的验证凭证来进行登录，PIN码内容及物理令牌相对于用户名及密码来说更难获得，所以这种情况下攻击的严重程度比较高）

测试多阶段验证机制可以按照以下步骤进行：
记录一次有效账户完整的登录过程，并使用代理记录每一阶段的数据
收集那些由服务器返回的且重复提交的数据，这些数据往往放置与Cookie，URL预设参数，隐藏表单字段等位置
对于上述收集到的重复提交的数据试着在另一阶段将其修改为不同的值看看是否能够登录成功
还需要注意任何提交到服务器且不是用户直接输入的数据，这些数据可能是登录进展的状态信息，比如stage2complete=True，攻击者可以直接修改这些值进入下一阶段
尝试各种畸形的登录过程