参考: The Web Application Hacker’s Handbook Chapter 6
1.防止信息泄露(Prevent Information Leakage)
- 应用程序使用的各种身份验证机制不应通过任何公开消息或从应用程序的其他方面推断的信息来披露任何关于身份验证参数的信息。攻击者不应该确定提交的各种项目的哪个部分造成了一个问题。
- 一个代码组件应该负责响应所有失败的登录尝试和一个通用消息。这避免了一种微妙的漏洞,因为在消息、不同的HTTP状态代码、隐藏在HTML中的其他信息、类似的其他信息中,从不同的代码路径返回的可能没有信息的消息实际上会被攻击者发现。
- 如果应用程序迫使某种帐户锁定来防止武力攻击(在下一节中讨论),小心不要让这导致任何信息泄漏。例如,如果一个应用程序公开了一个专门的帐户已经被暂停为X分钟因为Y失败的登录,这种行为可以很容易地用于枚举有效的用户名。此外,披露锁定策略的精确指标使攻击者能够优化任何继续猜测密码的尝试,尽管有政策。为了避免用户名的枚举,应用程序应该响应同一浏览器上的任何一系列失败的登录尝试,并使用一个通用消息通知,如果多个故障,帐户被暂停发生,用户应该稍后再试。这可以使用cookie或隐藏的affeld来跟踪来自相同浏览器的重复失败。(当然,该机制不应该用于执行任何实际的安全控制——只是为那些难以记住自己的凭证的普通用户提供了一个有用的信息。)
- 如果应用程序支持自注册,则可以防止此函数以两种方式枚举现有的用户名:
- 应用程序可以为每个新用户创建一个独特的(和不可预测的)用户名,从而消除了需要披露选定的用户名已经存在的需求。
- 应用程序可以使用电子邮件地址作为用户名。在这里,注册过程的第一个阶段要求用户输入她的电子邮件地址,然后她被告知只需等待一封电子邮件,并遵循里面包含的指令。如果电子邮件地址已经注册,用户可以在电子邮件中被告知。如果地址尚未注册,用户可以提供一个独特的、无法识别的URL访问,以继续注册过程。这可以防止攻击者枚举有效的用户名(除非他碰巧已经破坏了大量的电子邮件帐户)。
2.防止暴力破解攻击(Prevent Brute-Force Attacks)
- 需要在认证功能实现的所有挑战中执行措施,以防止使用自动化实现这些挑战的攻击。这包括登录本身,以及更改密码的功能,从被遗忘的密码状态恢复,等等。
- 使用不可预测的用户名和防止他们的枚举是完全盲目的bruforce攻击的一个重要障碍,并要求攻击者在安装攻击之前发现一个或多个专用用户名。
- 一些安全关键的应用程序(如在线银行)仅仅在少量失败的登录(如3)之后就禁用了一个帐户。他们还要求账户所有者采取各种不带的步骤来重新激活帐户,比如拨打客户支持并回答一系列安全问题。这一政策的缺点是,它允许攻击者通过多次禁用他们的帐户,以及提供帐户恢复服务的成本来拒绝向合法用户提供服务。一个更平衡的策略,适用于大多数安全意识的应用程序,是在少量失败的登录尝试(如3)之后,暂停一个短时间(比如30分钟)。这可以大大减缓任何密码猜测攻击,同时减轻拒绝服务攻击的风险,同时减少呼叫中心工作。
- 如果实施临时帐户暂停的政策,应注意确保其有效性:
- 为了防止信息泄漏导致用户名枚举,应用程序不应该表明任何特定的帐户已经被暂停。相反,它应该对任何一系列失败的登录,甚至是使用无效用户名的用户,使用一个消息通知,如果多个故障发生,用户应该再次尝试(刚刚讨论的),则会暂停帐户。
- 该政策的指标不应被披露给用户。简单地告诉合法的用户“再试一次”并没有严重降低他们的服务质量。但告诉攻击者确切地说,有多少失败的尝试是可以容忍的,以及暂停的时间是多长时间,使他能够优化任何继续猜测密码的尝试,尽管有政策。
- 如果帐户被暂停,则应该在不检查凭证的情况下进行登录尝试。一些应用程序实现了一个暂停策略,它仍然很容易受到强制强制的影响,因为它们在暂停期间继续完全处理登录尝试,当提交有效的凭证时,它们会巧妙地(或不那么微妙地)返回不同的消息。这种行为使有效的武力攻击能够全速前进,而不考虑暂停政策。
- 每个帐户的策略,如帐户锁定,并不能帮助防止一种强力攻击,这通常是非常有效的——通过一长串枚举的用户名,检查一个微弱的密码,比如密码。例如,如果五个失败的尝试触发一个帐户暂停,这意味着攻击者可以在每个帐户上尝试四个不同的密码,而不会对用户造成任何破坏。在一个包含许多弱密码的典型应用程序中,这样的攻击者很可能会危及许多帐户。
当然,如果认证机制的其他领域安全设计,这种攻击的有效性将会大大减少。如果用户名不能被枚举或可靠地预测,那么攻击者将会被减慢,因为需要在猜测用户名的情况下执行一个bruforce练习。如果有强烈的需求来进行密码质量,那么攻击者就不太可能选择一个密码来测试,即使是应用程序的单个用户也选择了。
除了这些控制之外,应用程序还可以通过使用CAPTCHA(完全自动化的公共图图测试,将计算机和人类分离的)挑战在每一页上进行攻击(见图6-9)。如果有效,这项措施可以防止任何自动提交数据到任何应用程序页面,从而使所有类型的密码猜测攻击被手动执行。注意,在CAPTCHA技术上已经做了很多研究,在某些情况下,对它们的自动攻击是可靠的。此外,一些攻击者已经设计了captcha解决的比赛,在这种比赛中,公众被利用的是无人机来帮助攻击者。然而,即使一种特殊的挑战并不完全有效,它仍然会让大多数随意的攻击者停止并不使用这种技术的应用程序。
如果您正在攻击使用CAPTCHA控件以阻碍自动化的应用程序,那么它总是会密切关注图像出现的页面的HTML源。作者遇到了在图像标记的ALT属性中,或在一个隐藏的表单feld中,在文字表单中出现的问题的案例,允许脚本攻击来击败保护,而实际上没有解决这个谜题本身。
3.防止误用密码更改功能(Prevent Misuse of the Password Change Function)
- 一个密码更改函数应该始终实现,允许周期密码过期(如果需要),并允许用户在任何原因中更改密码。作为一个关键的安全机制,这需要很好地抵御误用。
- 该函数只能从身份验证的会话中访问。
- 不应该提供一个用户名的功能,要么是明确的,要么是通过一个隐藏的表单feld或cookie。用户没有合法的需要试图改变别人的密码。
- 作为一种防御深度的措施,该函数应该受到保护,防止未经授权的访问获得在应用程序中的其他安全缺陷——比如一个session -劫持漏洞、跨站点脚本,甚至是一个无人值守的终端。为此,应该需要用户重新输入现有的密码。
- 作为一种防御深度的措施,该函数应该受到保护,防止未经授权的访问获得在应用程序中的其他安全缺陷——比如一个session -劫持漏洞、跨站点脚本,甚至是一个无人值守的终端。为此,应该需要用户重新输入现有的密码。
- 该函数应该防止针对主登录机制的各种攻击。一个单一的通用错误消息应该被用来通知用户在现有的凭证中任何错误,并且在通过少量的失败尝试来更改密码后,该函数应该被暂时暂停。
- 用户应该被通知外带(如通过电子邮件),他们的密码已经改变,但消息不应该包含他们的旧或新的凭证。
Chapter 6 Attacking Authentication(4) - Securing Authentication(1)
Chapter 6 Attacking Authentication(4) - Securing Authentication(3)
