目录
验证机制设计缺陷
1.1、简介：
与Web应用程序常用的任何其他安全机制相比， 验证功能中存在着更多设计方面的薄弱环节。即使在基于用户名和密码验证用户这种非常简单的标准化模型中， 其中包含的设计缺陷也容易导致应用程序被非法访问
1.2、密码保密性不强
简述：
存在Web应用程序没有或很少对用户密码的强度进行控制。应用程序常常使用下列形式的密码
非常短或空白的密码
以常用的字典词汇或名称为密码
密码和用户名完全相同
仍然使用默认密码
终端用户很少具有安全意识，没有实施严格密码标准的应用程序很可能包含大扯使用脆弱密码的用户账户。攻击者很容易就可猜测出这些密码， 从而对应用程序进行未授权访问
利用：
查明任何与密码强度有关的规则
1、浏览该Web站点， 查找任何描述上述规则的内容
2、自我注册用不同种类的脆弱密码注册几个账户， 了解应用程序采用何种规则。
3、拥有一个账户并且可以更改密码， 试籽把密码更改为各种脆弱密码
1.3、蛮力攻击登录
简述：
登录功能的公开性往往诱使攻击者试图猜测用户名和密码，从而获取未授权访问应用程序的权力。如果应用程序允许攻击者使用不同的密码重复进行登录尝试， 直到找到正确的密码， 那么它就非常容易受攻击， 因为即使是业余攻击者也可以在浏览器中手动输入一些常见的用户名和密码
一些最常见的密码有：
passwod
12345678
monkey
abc123
……
利用：
1、攻击者会根据冗长的常用密码列表， 使用自动技巧尝试猜测出密码。依赖带宽和处理能力， 通过普通PC和DSL连接， 攻击者每分钟就可以发出数千个登录尝试这样， 即使最强大的密码最终也会被攻破
2、使用bp对一个账户成功实施密码猜测攻击，可通过HTTP响应码、响应长度及缺乏＂登录错误“ 消息等差异清楚区分成功的登录尝试
（筛选攻击结果，找到数据长度与大多数不一致的）
控件：
1、一些应用程序使用客户端控件防止密码猜测攻击
如某个应用程序可能会设置cookie failedlogins=1，如果登录尝试失败，递增这个值。达到某个上限后， 服务器将在提交的cookie中检测这个值， 并拒绝处理登录尝试。这种客户端防御可防止仅使用浏览器实施的手动攻击
2、如果登录失败计数器保存在当前会话中，这时就会出现前一个漏洞的变化形式。虽然在客户端并没有表明该漏洞存在的任何迹象， 但攻击者只需要获得一个全新的会话（如通过保留会话cookie）即可继续实施密码猜测攻击
3、一般情况，应用程序会在失败的登录尝试达到一定次数后锁定目标账户。并表明（或允许攻击者推测）所提交的密码是否正确的消息， 对随后的登录尝试作出响应，这意味着， 即使目标账户被锁定， 攻击者仍然可以完成密码猜测攻击。如果应用程序在一段时间后自动解除账户的锁定状态， 则攻击者只需要等到这一时刻， 然后即可使用发现的密码正常登录。
过程：
1、用控制的某个账户手动提交几个错误的登录尝试，监控接收到的错误消息
2、如果应用程序在大约10次失败后还没有返回任何有关账户锁定（lockout)的消息，再尝试正确登录。如果登录成功， 应用程序可能并未采用任何账户锁定策略
3、如果账户被锁定， 可以尝试重复使用不同的账户。如果应用程序发布任何cookie， 这次可以将每个cookie仅用于一次登录尝试， 并为随后的每次登录尝试获取新cookie
4、如果账户被锁定， 应查看与提交无效密码相比， 提交有效密码是否会导致应用程序的行为出现任何差异。如果确实如此， 则可以继续实施密码猜测攻击， 即使账户被锁定
5、如果没有控制任何账户， 尝试枚举一个有效的用户名，并使用它提交几次错误登录， 监控有关账户锁定的错误消息
6、发动蛮力攻击前， 首先确定应用程序响应成功与失败登录之间的行为差异， 以此分清它们在自动攻击过程中表现出的区别
7、列出已枚举出的或常见的用户名列表和常用密码列表。根据所获得的任何有关密码强度规则的信息对上述列表加以修改， 以避免进行多余测试
8、使用这些用户名和密码的各种排列组合， 通过适当的工具或定制脚本迅速生成登录请求。监控服务器响应以确定成功的登录尝试。
9、一次针对几个用户名，最好以广度优先而非深度优先的方式实施这种蛮力攻击。这包括循环使用一组密码（从最常用的密码开始）并轮流对每个用户名使用每一个密码。这种方法有两方面的好处：首先， 可以更加迅速地确定使用常用密码的账户；其次， 这样做可以降低触发任何账户锁定防御的可能性，因为在使用同一个账户进行连续登录之间存在时间延迟。
1.4、详细的失败消息
简介：
一个典型的登录表单要求用户输人两组信息（用户名和密码），而一些应用程序则需要更多信息（如出生日期、纪念地或PIN另码）
如果登录尝试失败，可以得出结论至少有一组信息出错，如果应用程序通知是哪一组信息无效，就可以利用它显著降低登录机制的防御效能
在最简单的情况下，如果只需要用户名和密码登录，应用程序可能会通过指出失败的原因（用户名无效或密码错误）来响应失败的登录尝试
基础利用：
1、攻击者可以发动一次自动化攻击， 遍历大量常见的用户名， 确定哪些有效。用户名一般并非秘密（ 登录时隐藏用户名）。 如果攻击者能够轻易确定有效的用户名， 就更可能在有限的时间内、运用一定的技能、付出一定的精力攻破应用程序， 并将枚举出的用户名列表作为随后各种攻击的基础， 包括密码猜测、攻击用户数据或会话， 或者社会工程学
2、除主要的登录功能外， 还可以对验证机制的其他组件进行用户名枚举， 需要提交真实或潜在用户名的任何功能都可用于这一目的。
3、可以对用户注册功能进行用户名枚举。如果应用程序允许新用户注册并指定他们自己的用户名， 由于应用程序要防止注册重复用户名，几乎不可能阻止用户名枚举攻击。有时也可以对密码修改或忘记密码功能进行用户名枚举
注：许多验证机制以隐含或明确的方式提示用户名，Web邮件账户的用户名通常为电子邮件地址。许多其他站点，在应用程序中透定用户名， 或者允许使用可轻易精测出的用户名，并未考虑攻击者会对其加以利用的情况
复杂利用：
1、应用程序要求用户提交几组信息， 或者完成几个步骤。详细的失败消息或差异点可帮助攻击者轮流针对登录过程的每个阶段发动攻击， 提高其获得未授权访问的可能性
注：这种漏洞可能会以更隐含的形式出现。即使响应有效和无效用户名的错误消息表面看来完全相同， 它们之间仍然存在细微的差别， 可用于枚举有效的用户名。
2、如果应用程序中的多条代码硌径返回 " 相同的＂ 失败消息， 这些消息之间仍然可伴存在细小的排版差别。应用程序响应在屏墓上显示的内容完全相同， 但其HTML源代码可能隐藏着细微的区别， 如注释或布局方面的不同。如果无法轻易枚举出有效的用户名， 应当仔细比较应用程序对有效和无效用户名作出的响应。
3、可以使用Bp中的"比较"工具自动分析并突出显示两个应用程序响应之间的差异。这有助于迅速确定有效的用户名是否会导致应用程序的响应出现任何系统性的差异
4、如果应用程序只允许登录某个账户时失败3次， 可能就会在使用通过自动枚举发现的每个用户名登录时“浪费” 一次登录机会。当进行枚举攻击时， 不要在每次登录时提交完全不合理的密码， 而是提交常见的密码， 如password或以用户名为密码。如果应用程序执行脆弱的密码强度规则， 在枚举操作过程中执行的一些登录尝试就很可能会取得成功， 有些情况下还可能同时查明用户名和密码。要以用户名设置密码字段， 可以使用Bp中的“破城摊" (batting ram)攻击模式， 在登录请求的几个位置插入相同的有效载荷。
5、即使应用程序对包含有效与无效用户名登录尝试的响应完全相同， 我们仍然可以根据应用程序响应登录请求的时间枚举出用户名。应用程序通常依据登录请求是否包含有效用户名， 对其进行截然不同的后端处理。
登录请求中包含一个有效的用户名， 应用程序可能会从后路数据库中获取用户资料， 对这些资料进行各种处理（如检查账户是否到期），确认密码（如资源密集型散列算法）， 如果密码错误返回一条常规消息。仅仅使用浏览器可能无法检测出应用程序处理两个请求之间的时间差异， 但自动工具能够区分这种差异（即使这种操作会产生大批错误警报，但也大大提高效率）
注：除登录功能外， 还可以从其他地方获取有效的用户名。开发者或组织内部其他人员的电子邮件地址都可能为有效的用户名， 任何可访问的日志功能也可能透露用户名
过程：
1、如果已经知道一个有效的用户名（例如一个受控制的账户） ， 使用这个用户名和一个错误的密码进行一次登录， 然后使用一个完全随机的用户名进行另一次登录
2、记录服务器响应两次登录尝试的每一个细节， 包括状态码、任何重定向、屏幕上显示的信息以及任何隐藏在HTML页面中的差异。使用拦截代理服务器保存服务器上来回流量的完整历史记录
3、找出服务器响应两次登录尝试的任何明显或细微的差异
4、如果无法发现任何差异， 在应用程序中任何提交用户名的地方（例如自我注册、密码修改与忘记密码功能）重复上述操作
5、如果发现服务器响应有效和无效用户名之间的差异，收集一个常见用户名列表并使用一个定制脚本或自动工具迅速提交每个用户名， 过滤出说明用户名有效的响应
6、开始枚举操作之前， 确定应用程序是否在登录尝试失败次数达到一定数目后执行账户锁定，如果应用程序执行账户锁定（设计枚举攻击时注意）
扫一扫
912
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
