参考: The Web Application Hacker’s Handbook Chapter 6
1.防止误用帐户恢复功能()
- 1.在最重要的应用程序中,如在线银行,在被遗忘的密码的事件中帐户恢复处理退出频带。用户必须拨打电话,并回答一系列安全问题,以及新的凭据或重新激活代码,也通过传统邮件发送给用户注册的家庭地址。大多数应用程序不需要或需要这种级别的安全性,因此自动恢复函数可能是适当的。
- 2.一个精心设计的密码恢复机制需要防止帐户被未经授权的一方破坏,并减少对合法用户的任何破坏。
- 3.这些功能,如密码“提示”不应该被使用,因为它们主要帮助攻击者挖掘出明显提示集的帐户。
- 4.让用户重新控制帐户的最好的自动化解决方案是将用户电子邮件发送到一个独特的、时间限制的、无法识别的、单一使用的恢复URL。此电子邮件应发送到注册期间提供的用户的地址。访问URL允许用户设置新密码。在完成此之后,应该发送第二个电子邮件,指示进行了密码更改。为了防止攻击者通过不断请求密码重新激活电子邮件来阻止攻击用户,用户的现有凭证应该保持有效,直到它们被改变。
- 5.为了进一步防止未经授权的访问,应用程序可能会给用户提供次要的挑战,在获得密码重置功能之前,它们必须完成。确保这个挑战的设计不会引入新的漏洞:
- 1.在注册过程中,挑战应该为每个人执行同样的问题或问题。如果用户提供他们自己的挑战,那么其中一些可能会很弱,这也使攻击者可以通过识别那些有挑战集的人来枚举有效帐户。
- 2.对挑战的反应应该包含足够的熵,它们不能很容易地猜到。例如,向用户询问他的fi rst学校的名字比要求他喜欢的颜色更可取。
- 3.在尝试完成挑战后,应暂时暂停账户,以防止武力攻击。
- 4.应用程序不应泄露任何信息,以应对挑战——关于用户名的有效性,任何暂停的帐户,等等。
- 5.成功完成挑战应该遵循之前描述的过程,其中消息被发送到包含重新激活URL的用户注册的电子邮件地址。在任何情况下,应用程序都不应该披露用户遗忘的密码,或者只是将用户输入身份验证的会话。甚至直接进入密码重置函数是不可取的。对帐户恢复挑战的响应通常对攻击者来说比原始的密码更容易,因此不应该依靠它自己来验证用户。
2.日志、监视器和通知(Log, Monitor, and Notify)
- 1.应用程序应该记录所有与身份验证相关的事件,包括登录、注销、密码更改、密码重置、帐户暂停和帐户恢复。在适用的情况下,失败和成功的尝试都应该被记录下来。日志应该包含所有相关的细节(如用户名和IP地址),但没有安全秘密(如密码)。日志应该受到严格保护,不受未经授权的访问,因为它们是信息泄漏的关键来源。
- 2.认证事件中的异常应该通过应用程序的实时报警和入侵预防功能来处理。例如,应该让应用程序管理员意识到显示武力攻击的模式,以便考虑适当的防御和进攻措施。
- 3.用户应该被通知任何关键的安全事件。例如,应用程序应该在更改密码时向用户的注册电子邮件地址发送消息。
- 4.用户应该被通知频繁发生的安全事件。例如,在成功登录后,应用程序应该通知用户时间和源IP /域的最后登录,以及从那以后的无效登录尝试的数量。如果一个用户知道她的账户正在受到一个密码猜测攻击,她更有可能经常更改她的密码,并将其设置为一个强大的值。
Summary
身份验证功能可能是典型应用程序攻击表面中最突出的目标。通过defi nition,它们可以由无特权的匿名用户到达。如果断开,它们可以访问受保护的功能和敏感数据。他们是一个安全机制的核心,一个应用程序使用来保护自己,并是反对未经授权访问的前线。
真实的身份验证机制包含大量的设计和实现fl。对他们的有效攻击需要系统地进行,使用一种结构化的方法来通过每一个可能的攻击途径。在许多情况下,开放目标呈现自己——糟糕的密码,找出用户名的方法,脆弱于武力攻击的方法。在光谱的另一端,缺陷可能很难发现。他们可能需要一丝不苟 检查一个复杂的登录过程,以建立所做的假设,并帮助你发现可以利用的微妙的逻辑漏洞通过门。
当攻击身份验证功能时,最重要的教训是到处看。除了主登录表单之外,还可以有功能来注册新帐户、更改密码、记住密码、恢复被遗忘的密码,并模拟其他用户。这些都是潜在缺陷的一个丰富的目标,在一个函数中有意识地消除的问题经常会在其他功能中重新出现。把时间花在仔细检查和探测每一英寸的攻击表面,你可以获得,你的回报可能很好。
Chapter 6 Attacking Authentication(4) - Securing Authentication(2)