目录
1.5、防止蛮力攻击
简述：
1、必须对验证功能执行的各种质询采取保护措施， 防止攻击者企图使用自动工具响应这些质询。这包括登录机制、修改密码功能和恢复遗忘密码等功能中的质询
2、使用无法预测的用户名， 同时阻止用户名枚举， 给完全盲目的蛮力攻击设置巨大障碍，并要求攻击者在实施攻击前已经通过某种方式发现一个或几个特殊的用户名
3、一些对安全性要求极高的应用程序（如电子银行）在检测到少数儿次（如3次）登录失败后应立即禁用该账户， 井要求账户所有者采取各种非常规步骤重新激活该账户， 如给呼叫中心拨打电话并回答一系列安全问题。这种策略的缺点在于·它允许攻击者通过重复禁用合法用户的账户向他们发动拒绝服务攻击， 因而增加了提供账户恢复服务的成本。一种更加均衡的策略适用于非常注重安全的应用程序， 即在检测到少数几次（如3次）登录失败后将该账户冻结一段时间。这种策略可有效阻止密码猜测攻击， 同时可降低拒绝服务攻击风险， 减轻呼叫中心的工作负担
4、如果采用临时冻结账户的策略， 应采取措施确保这种策略的效率
为防止信息泄露导致用户名枚举， 应用程序绝不能透漏任何账户冻结信息。相反， 应用程序应对一系列即使是使用无效用户名发起的失败登录做出响应， 通过一条常规消息提出警告：如果出现多次登录失败， 账户将被冻结， 建议用户稍后再试
应用程序不应向用户透漏账户锁定标准。只要告诉合法用户＂稍后再试” 并不会显若降低服务质量。但告知攻击者应用程序到底能够容忍多少次失败的登录尝试、账户冻结期有多长， 就会让他们对任何登录尝试进行调整， 不顾账户锁定策略而继续猜测密码
如果一个账户被冻结， 那么应用程序不用检查用户证书， 直接就可以拒绝该账户的登录尝试。因为一些应用程序在冻结期继续完全处理登录尝试， 并且在提交有效证书时返回一条差异并不明显（或者差异比较明显）的消息， 因此尽管应用程序执行账户冻结策峈， 攻击者仍然能够利用这种行为实施彻底有效的蛮力攻击
账户锁定之类的常规应对措施对防御一种极其有效的蛮力攻击并没有帮助， 即遍历大量枚举出的用户名， 检在单独一个脆弱密码， 如password。
例如， 如果5次登录失败就会触发账户冻结， 这意味疗攻击者能够对每个账户尝试使用4个不同的密码， 而不会引起任何中断。如果一个应用程序使用许多脆弱密码， 使用上述攻击手段的攻击者就能够攻破许多账户。
如果验证机制其他区域的设计安全可靠， 这种攻击的效率就会显著降低。如果攻击者无法枚举或有效预测出用户名， 他就需要实施蛮力攻击以猜测用户名， 其攻击速度也随之减慢。如果应用程序执行了严格的密码强度要求， 攻击者更没有可能选择某个应用程序用户已经选择的密码进行测试
5、应用程序还可以在每个可能成为蛮力攻击目标的页面，使用CAPTCHA（全自动区分人类和计箕机的图灵测试）质询， 专门防御这种攻击。实际上， 这种措施可防止攻击者向任何应用程序页面自动提交数据， 从而阻止其手动实施各种密码猜测攻击。实际上， 人们已经对CAPTCHA技术进行了大量的研究。有些时候， 针对这种技术的自动攻击已经能够取得相当的成效。此外， 一些攻击者甚至发起了破解CAPTCHA的竞赛， 利用不知情的公众人物作为标靶帮助攻击者实施攻击。但是， 即使一类特殊的质询无法完全生效， 它仍然可使大多数随意的攻击者停止攻击行动， 转而寻找并不使用这种技术的应用程序
攻击者在攻击一个使用CPATCHA控件阻止自动攻击的应用程序时一定会仔细检查图像页面的HTML源代码。 答案以文字形式出现在图像标签的ALT属性或一个隐藏表单字段中， 这使攻击者不必解开谜题就可以解除应用租序执行的保护
1.6、防止滥用密码修改功能
简述：
1、应用程序应始终执行密码修改功能，允许定期使用的密码到期终止并允许用户修改密码。作为一种关键的安全机制，必须精心设计这项功能以防止滥用
2、只能从已通过验证的会话中访问该功能
3、不应以任何方式直接提供用户名，也不能通过隐藏表单字段或cookie提供用户名。用户企图修改他人密码的行为属非法行为
4、作为一项高级防御措施，应用程序应对密码修改功能加以保护， 防止攻击者通过其他安
全缺陷， 如会话劫持漏洞、跨站点脚本， 甚至是无人石管的终端获得未授权访问。为达
到这种目的， 应要求用户重新输人现有密码5、为防止错误， 新密码应输入两次。应用程序应首先比较“新密码” 与“确认新密码” 字段， 看它们是否匹配， 如果不相匹配， 返回一条详细的错误消息。
6、该功能应阻止可能针对主要登录机制的各种攻击应使用一条常规错误消息告知用户现有证书中出现的任何错误；如果修改密码的尝试出现少数几次失败， 应临时冻结该功能
7、应使用非常规方式（如通过电子邮件）通知用户其密码已被修改， 但通知消息中不得包含用户的旧证书或新证书
1.7、防止滥用账户恢复功能
简述：
1、当用户遗忘密码时， 许多安全性至关重要的应用程序（如电子银行）通过非付规方式完成账户恢复，用户必须给呼叫中心打电话并回答一系列安全问题，新证书或项新激活代码也以非常规方式（通过传统的邮件）送往用户注册的家庭住址。绝大多数应用程序并不需要这种程度的安全保护， 只需使用自动恢复功能即可。
2、精心设计的密码恢复机制需要防止账户被未授权方攻破， 避免给合法用户造成任何使用中断
3、绝对不要使用密码"提示"之类的特性，因为攻击者可利用明显的暗示向账户发动攻击
4、通过电子邮件给用户发送一个唯一的、具有时间限制的、无法猜测的一次性恢复URL是帮助用户重新控制账户的最佳自动化解决方案。这封电子邮件应送至用户在注册阶段提供的地址中。用户访问该URL即可设置新密码。之后， 应用程序会向用户送出另一封电子邮件， 说明密码已被修改。为防止攻击者通过不断请求密码重新激活电子邮件而向用户发动拒绝服务攻击， 在证书得到修改前， 用户原有证书应保持有效
5、为进一步防止未授权访问， 应用程序可能会向用户提出一个次要质询， 用户必须在使用密码重设功能前完成该质询。设计质询时应小心谨慎， 确保不会引入新的漏洞。
应用程序应在注册阶段规定：质询应对每一名用户提出同一个或同一组问题。如果用户提供自己的质询， 可能其中会有一些非常易于受到攻击， 这也使攻击者能够通过确定那些自行设定质询的用户枚举出有效的账户
质询响应必须具有足够的随机性， 确保攻击者无法轻易猜测出来。例如， 询问用户就读的小学名称就优于询问他们坟喜欢的颜色
为防止蛮力攻击， 如果多次尝试完成质询都以失败告终，应临时冻结相关账户
如果质询没有得到正确响应，应用程序不应泄露任何相关信息，如用户名的有效性、账户冻结等
成功完成质询后， 应继续完成上文描述的处理过程， 即向用户注册的电子邮件地址发送一封包含重新激活URL的电子邮件。无论在什么情况下， 应用程序都不得透露用户遗忘的密码或简单将用户放入一个通过验证的会话中。此外， 最好不要直接进入密码重设功能， 因为与初始密码相比， 攻击者通常更容易猜测出账户恢复质询的响应， 因此应用程序不应依赖它对用户进行验证。
1.8、日志、监控与通知
简述：
1、应用程序应在日志中记录所有与验证有关的事件， 包括登录、退出、密码修改、密码重设、账户冻结与账户恢复。应在适当的地方记录所有失败与成功的登录尝试。日志中应包含一切相关细节（如用户名和IP地址）， 但不得泄露任何安全机密（如密码）。应用程序应为日志提供强有力的保护以防止未授权访问， 因为它们是信息泄露的主要源头
2、应用程序的实时警报与入侵防御功能应对验证过程中的异常事件进行处理。
例如， 该功能应向应用程序管理员通报所有蛮力攻击模式， 便于他们采取适当的防御与攻击措施
3、应以非常规方式向用户通报任何重大的安全事件
例如， 用户修改密码后、应用程序应向他注册的电子邮件地址发送一封邮件
4、应以非常规方式向用户通报经常发生的安全事件。
用户成功登录后， 应用程序应向用户通报上次登录的时间与来源IP/域， 以及从那以后进行的无效登录尝试的次数。如果用户获悉其账户正遭受密码猜测攻击， 他就更有可能会经常修改密码， 并设置一个安全性庙的密码