接口安全性测试技术(2)：测试维度之攻击验证机制

一、攻击验证机制

身份验证是核心防御机制中最薄弱的环节，身份验证机制也是攻击者的主要攻击目标之一。

常见的验证技术

1、基于HTML表单的验证（最常见）

2、多元机制，如组合密码和物理令牌

多用于安全性要求较高的应用程序比如说提供进行巨额交易服务的私人银行

3、客户端SSL证书或智能卡

这种验证技术成本昂贵，通常只有那些用户不多的安全性极其重要的应用程序才会使用它们。

4、HTTP基本认证和摘要认证

这种验证方式通常会出现在企业内网中，这种验证机制是建立在域环境及内网对用户的访问控制之上的。

5、使用NTLM或Kerberos整合Windows的认证

6、第三方验证服务

验证机制设计缺陷

1. 可预测的用户名

有些应用程序需要用户注册时用户名符合某一特定规则，比如需要满足“姓名缩写_数字”的这种形式，其中数字是为了防止用户名重复，也
就是说如果在存在姓名缩写相同的情况下后面要跟数字或者进行数字累加。

2.非唯一性用户名

极少部分的应用程序应用程序不要求用户名的唯一性，这就可能造成这样的问题：
在恰巧有两名用户使用相同的用户名及密码的情况下应用程序要么阻止
第二个用户设置密码要么允许其设置相同的密码，前者这种情况可能导致第一名用户的密码泄露给第二名用户。

3.弱密码

具体情形：
非常短或空白的密码
以常用的字典词汇或名称为密码
用户名与密码相同

4.可预测的密码

在像学校，企业这种存在批量注册大量用户需求的应用程序中经常会为批量用户设置默认密码，这种默认密码可以是相同的也可以是与用户名
或者其身份证信息等有关系的。

5.密码确认不完善

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

6.暴力破解

如果应用程序允许用户在登录失败很多次后任能继续尝试登录，那么这种情况下此应用可能存在暴破攻击。为了防止暴破攻击，应用程序应该
设置用户登录失败次数上限，当用户失败的登录次数达到上限后应用程序应该阻止用户进一步的登录。

7.信息推测

在进行暴破时如果验证失败Web应用程序的响应信息经常为“用户名或密码出错”，通过这个响应信息我们可以推测出以下两种情况会造成验证
失败：
1)用户名不存在
2)用户名存在但密码错误
但是具体是哪种情况我们无法判断，为此我们就需要对用户名和密码同时进行暴破，这极大地增加了暴破的工作量及暴破失败的可能性。这时
候我们可以尝试使用已知用户名及随机用户名进行登录观察响应的细微之处来进行判断。除此之外还可以通过Web应用程序以下功能及其反馈
的信息来确定一些用户名然后针对于这些用户名进行密码暴破：
1)登录后返回详细的失败信息
比如在你登录时如果你的用户名不正确应用程序会返回“此用户不存在”类似的信息。
2)注册
应用程序为了防止用户名重复在注册时如果填入已经存在的用户名则会出现类似于“此用户名已存在”的提示。
3)找回密码，修改密码
Web应用程序通常会提供根据用户名找回密码及修改密码的服务，这时如果填入的用户名不存在Web应用程序经常会返回“此用户不存在”的响
应。不过当前很多Web应用程序是根据用户注册时填入的邮箱进行密码找回的。
4)公开信息
注释信息，暴露的邮箱，github库等。使用Google的高级搜索语法针对于目标网站进行收集通常会有惊喜出现！

8.修改密码

目前的修改密码的方式大概可以分为两种，第一种是要求用户键入用户名、旧密码、新密码、确认新密码四部分，一些Web应用程序会忽略修
改密码处旧密码错误输入次数过多的问题，这就容易被攻击者利用来进行密码暴破；还有一种最不安全的情况就是只需要用户键入用户名、新
密码、确认新密码即可更改用户名相应的密码，这种情况下攻击者无需暴破即可获得正确的用户名及密码组合。

9.忘记密码

1.忘记密码功能往往通过设置一组问题来验证用户身份，比如这些问题可以是“我最喜欢的颜色”，这些问题的答案组合次数相对于密码来说小
的多，并且可以通过信息收集工作来提供辅助。攻击者可以收集一组用户名并逐个遍历然后记录相应的问题在其中选择最简单的那个下手可以
获得更高的成功率。
2.忘记密码处可能不会设置错误次数限制从而允许攻击者猜测上述问题的答案。
3.通常Web应用程序也会设置密码暗示来代替上述问题，这些密码暗示往往能够辅助攻击者猜测密码，有些用户甚至直接把密码设置为密码暗
示。攻击者同样可以通过枚举收集到的用户名然后获得一组密码暗示，从而寻找出最容易获得的密码。
4.不过庆幸的是当前Web应用程序通过向用户邮箱发送密码重置链接来帮助用户修改密码，这种链接是随机的攻击者很难对其进行猜解。但是
有些应用在设计这个逻辑时可能允许Web应用程序将用户密码修复的邮件发送至攻击者，有时邮箱地址并没有直接显示出来而是存储在隐藏的
表单中这时攻击者可以将邮箱修改为自己的邮箱。在最差的情况下攻击者可以尝试推测密码重置的URL来重置用户密码。

10.“记住我”功能

一些应用程序为了方便用户访问通常会提供“记住我”的功能，此功能通常仅通过cookie中的某个字段来实现。比如Cookie中会设置一个存储
用户名的字段来实现基础我的功能如果这样的话攻击者仅需要随便注册一个用户然后将Cookie中用户名修改为其想要访问用户的用户名即可
实现对目标用户的访问。Cookie中还可能通过存储一个ID字段来唯一的标识用户，这种情况下攻击者可以遍历ID从而实现遍历访问用户。即
使Cookie中通过使用攻击者不可推测的信息来识别用户比如用户名及相应的密码散列还是存在一定的不安全性，此时攻击者可以通过XSS及
CSRF来进行攻击，如果应用程序设置了httponly及csrf_token则更能够保证用户信息的安全。

11.用户伪装功能

12.证书分配不安全

13.证书传输易受攻击

验证机制执行缺陷

验证机制在代码实现过程中也可能由于编码者某些的某些疏忽造成安全问题。

• 异常开放登录机制

用户能够控制的就是各种输入数据，为了引发异常从而绕过验证获得敏感信息的目的我们可以在各种可控参数中（Get参数，Post参数，
Cookie等）输入以下字符并观察比较此时的响应信息与正常情况下响
应信息的区别：
空字符串
完全删除键值对
特别长或者特别短的字符串
字符串代替数字或者相反
针对于某一个参数尝试重复提交相同或者不同的参数

• 多阶段登录机制中的缺陷

现实生活中有些对于安全性要求较高的应用可能会采取多阶段登录验证机制，比如一个多阶段验证机制可以有以下三个过程组成：
提交用户名及密码
响应一个质询，答案可能是PIN中的特殊数字或者一个值得纪念的词
提交物理令牌上的值
上述多阶段登录机制确实可以明显的提高登录验证的安全性，但是更多
的阶段同样意味着可能潜在有更多的执行缺陷，比如可能存在以下几个
常见的缺陷：
应用程序认为访问第三阶段的用户已经完成了一二阶段的认证。这种情
况下仅拥有部分登录凭证的攻击者可以成功登录。
在每个阶段的验证过程中应用程序会保存相应的标志，比如账户是否过
期，是否被锁定，是否属于管理员，是否需要完成更多的登录验证阶
段。如果攻击者可以在某一个登录阶段接触到上一个阶段设置的标记，
那么攻击者可以对这些标记进行修改从而完成一定程度的攻击行为。
应用程序有可能会认为各阶段认证过程中用户的身份都不会发生变化，
并且并不会在每一个阶段检查用户身份的统一性，那么如果攻击者在第
一阶段输入的用户名及密码与后面阶段输入的验证凭证不一致且应用程
序会以两种或者三种验证凭证任一对应的用户身份登录的话这就存在严
重的安全问题。这种情况下攻击者只需要知道目标用户的部分验证信息
就可以登录而其他信息则可以通过自己注册获得部分信息，这种攻击的
严重程度取决于应用程序用于确定用户身份的验证凭证的易获得度（比
如应用程序以第一阶段的用户名及密码来确定身份，那么存在上述缺陷
的情况下攻击者可以使用自己的后两个阶段的验证凭证来进行登录，
PIN码内容及物理令牌相对于用户名及密码来说更难获得所以这种情况
下攻击的严重程度比较高）。
在测试多阶段验证机制时我们可以按照如下步骤进行：
记录一次有效账户完整的登录过程，并使用代理记录每一阶段的数据
收集那些由服务器返回的且重复提交的数据，这些数据往往放置与
Cookie，URL预设参数，隐藏表单字段等位置
对于上述收集到的重复提交的数据试着在另一阶段将其修改为不同的值
看看是否能够登录成功
还需要注意任何提交到服务器且不是用户直接输入的数据，这些数据可
能是登录进展的状态信息，比如stage2complete=True，攻击者可以
直接修改这些值进入下一阶段
尝试各种畸形的登录过程，比如：
不同的登录顺序
直接进入特定的登录阶段
省略某一登录阶段
不同阶段使用不同用户的登录凭证
以及各种软件开发者想象不到的登录方式