参考: The Web Application Hacker’s Handbook
1.证书传输的脆弱性(Vulnerable Transmission of Credentials)
使用未加密的HTTP协议传输,登录凭证.很容易被监听和截获.根据用户位置,可能的监听者如下:
- 在用户本地网络
- 在用户的IT部门
- 在用户的同一个ISP内(移动，联通，电信)
- 在Internet的骨干网上
- 在托管应用程序的ISP中
- 在IT部门管理的应用程序中
即使用HTTPS登录,也是有可能将凭证泄漏给未授权方.
- 如果将凭据作为查询字符串参数传输（而不是在POST请求的正文中），则这些凭据可能会记录在各个位置，例如用户的浏览器历史记录中，Web服务器日志中以及任何日志中托管基础架构中使用的反向代理。 如果攻击者成功破坏了这些资源中的任何一个，他就可以通过捕获存储在其中的用户凭据来提升特权。
- 尽管大多数Web应用程序确实使用POST请求的主体来提交HTML登录表单本身，但令人惊讶的是，常见的情况是看到登录请求是通过重定向到另一个URL来处理的，该URL具有与查询字符串参数相同的凭据。 为什么应用程序开发人员认为有必要执行这些反弹尚不清楚，但是当选择这样做时，将其作为302重定向到URL的实现比使用通过JavaScript提交的第二个HTML表单的POST请求更容易实现。
- Web应用程序有时将用户凭据存储在cookie中，通常是为了实现登录，密码更改，记住我等设计不当的机制。 这些凭据容易受到攻击，这些攻击会破坏用户cookie，对于持久cookie而言，则是任何能够访问客户端本地文件系统的人都可以捕获的。 即使凭据被加密，攻击者仍然可以简单地重播cookie，因此以用户身份登录而实际上并不知道她的凭据。 第12章和第13章描述了攻击者可以以其他方式瞄准其他用户来捕获其Cookie的各种方式。
许多应用程序将HTTP用于应用程序的未经身份验证的区域，并在登录时切换到HTTPS。 如果是这种情况，那么正确的位置就是将登录页面加载到浏览器中时切换到HTTPS的位置，从而使用户能够在输入凭据之前验证该页面的真实性。 但是，通常会遇到应用程序使用HTTP加载登录页面本身，然后在提交凭据时切换到HTTPS的应用程序。 这是不安全的，因为用户无法验证登录页面本身的真实性，因此不能保证将凭据安全提交。 定位适当的攻击者可以拦截和修改登录页面，从而将登录表单的目标URL更改为使用HTTP。 当精明的用户意识到凭据已使用HTTP提交时，它们将受到破坏。
HACK STEPS
- 1.进行成功的登录，同时监视客户端和服务器之间双向的所有流量。
- 2.标识在任一方向上传输凭据的每种情况。 您可以在拦截代理中设置拦截规则，以标记包含特定字符串的消息（请参阅第20章）。
- 3.如果发现任何实例，这些实例中的凭据都以URL查询字符串或cookie的形式提交，或者从服务器传输回客户端，请了解发生了什么，并尝试确定应用程序开发人员试图达到的目的。 尝试找到攻击者可能通过各种手段干扰应用程序的逻辑，以破坏其他用户的凭据。
- 4.如果在未加密的通道上传输任何敏感信息，那么这很容易受到拦截。
- 5.如果未发现实际凭据传输不安全的情况，请密切注意似乎已编码或混淆的任何数据。 如果其中包括敏感数据，则可以对混淆算法进行逆向工程。
- 6.如果凭据是使用HTTPS提交的，但登录表单是使用HTTP加载的，则该应用程序容易受到中间人攻击，该攻击可能会用于捕获凭据。
2.修改密码功能(Password Change Functionality)
许多web应用程序没有为用户提供任何更改密码的方法。但是，对于设计良好的身份验证机制来说，此功能是必需的，原因有二:
- 1.定期强制更改密码可缓解密码泄露的威胁。 它减小了在猜测攻击中可以锁定给定密码的窗口。 它还减少了在没有攻击者检测的情况下可以使用泄露密码的窗口。
- 2.怀疑自己的密码可能已被盗用的用户需要能够快速更改其密码，以减少未经授权使用的威胁。
尽管它是有效验证机制的必要组成部分，但密码更改功能通常在设计上容易受到攻击。 在主登录功能中故意避免的漏洞通常会再次出现在密码更改功能中。 无需身份验证即可访问许多Web应用程序的密码更改功能，并执行以下操作:
- 1.提供详细错误消息，指示所请求的用户名是否有效。
- 2.允许不受限制地猜测“现有密码”字段。
- 3.仅在验证现有密码之后，检查“新密码”和“确认新密码”字段是否具有相同的值，从而使攻击能够成功地以非侵入方式发现现有密码。
典型的密码更改功能包括相对较大的逻辑决策树。 应用程序需要识别用户，验证提供的现有密码，与任何帐户锁定防御措施集成，将提供的新密码彼此进行比较并对照密码质量规则进行比较，并以适当的方式将任何错误情况反馈给用户。 因此，密码更改功能通常包含微妙的逻辑缺陷，可利用这些缺陷来破坏整个机制。
HACK STEPS
- 1.识别应用程序中的所有密码更改功能。 如果未与发布的内容明确链接，则仍可以实施。 第4章介绍了用于发现应用程序中隐藏内容的各种技术。
- 2.使用无效的用户名，无效的现有密码以及不匹配的“新密码”和“确认新密码”值对密码更改功能进行各种请求。
- 3.尝试确定可用于用户名枚举或蛮力攻击的任何行为（如Brute-Forcible Login和Verbose Failure Messages部分中所述）。
TIP
如果只有经过身份验证的用户可以访问密码更改表单，并且不包含用户名字段，则仍然可以提供任意用户名。 表单可以将用户名存储在一个隐藏的字段中，可以很容易地对其进行修改。 如果不是，请尝试提供一个包含用户名的附加参数，并使用与主登录表单中相同的参数名称。 有时，此技巧可以成功覆盖当前用户的用户名，即使您无法在主登录名上使用，也可以强行使用其他用户的凭据。
3.忘记密码功能(Forgotten Password Functionality)
与密码更改功能一样，从忘记的密码中恢复的机制通常会带来一些在主登录功能中可以避免的问题，例如用户名枚举。
除了这些缺陷之外，忘记密码功能的设计弱点经常使它成为攻击应用程序整体身份验证逻辑的最薄弱环节。 通常会发现几种设计缺陷：
- 1.忘记密码的功能通常涉及向用户提出次要挑战，而不是主要登录，如图6-5所示。 与尝试猜测用户密码相比，攻击者通常更容易应对这一挑战。 与母亲的姓氏，难忘的日期，喜欢的颜色等有关的问题通常比一组可能的密码要少得多。 此外，它们通常涉及公开已知的信息或确定的攻击者可以通过适度的努力发现的信息。
在许多情况下，该应用程序允许用户在注册过程中设置自己的密码恢复质询和响应。 用户倾向于提出极不安全的挑战，大概是基于错误的假设，即只有它们会出现。 例如“我是否拥有船？” 在这种情况下，想要获得访问权限的攻击者可以使用自动攻击来遍历枚举或常用用户名列表，记录所有密码恢复挑战，并选择最容易猜到的挑战。 （有关在脚本化攻击中如何获取此类数据的技术，请参见第14章。）
- 2.与密码更改功能一样，即使在主登录页面上阻止了此攻击，应用程序开发人员通常也忽略了对密码恢复挑战采取强行响应的可能性。 如果应用程序允许无限制地尝试回答密码恢复挑战，则极有可能被坚定的攻击者攻陷。
- 3.在某些应用程序中，恢复挑战由用户在注册过程中配置的简单密码“提示”代替。 用户通常会设置非常明显的提示，甚至是与密码本身相同的提示，都是基于错误的假设，即只有他们会看到它们。 同样，具有常用或枚举用户名列表的攻击者可以轻松捕获大量密码提示，然后开始猜测。
-
4.应用程序允许用户在正确响应挑战后重新控制其帐户的机制通常是脆弱的。实现此功能的一种比较安全的方法是向用户在注册期间提供的电子邮件地址发送一个惟一的、不可猜测的、有时间限制的恢复URL。在几分钟内访问这个URL使用户能够设置新密码。然而，经常遇到的其他帐户恢复机制是不安全的设计:
- 4.1在成功完成挑战后，某些应用程序会将现有的，被遗忘的密码泄露给用户，从而使攻击者可以无限期地使用该帐户，而不会被所有者发现。 即使帐户所有者随后更改了密码，攻击者也可以简单地重复相同的挑战来获取新密码。
- 4.2 某些应用程序在成功完成挑战后会立即将用户置于经过身份验证的会话中，这又使攻击者可以无限制地无限期使用帐户，而无需检测，也无需知道用户密码。
- 4.3 某些应用程序采用发送唯一恢复URL的机制，但在挑战完成时将其发送到用户指定的电子邮件地址。 除了可能记录攻击者使用的电子邮件地址之外，这绝对没有为恢复过程提供增强的安全性。
TIP
即使该应用程序没有为您提供提供接收恢复URL的电子邮件地址的屏幕字段，该应用程序也可能通过隐藏的字段或cookie来发送该地址。 这提供了一个双重机会：您可以发现已受到破坏的用户的电子邮件地址，并且可以修改其值以在您选择的地址接收恢复URL。
- 4.4 某些应用程序允许用户在成功完成挑战后立即重置其密码值，并且不向用户发送任何电子邮件通知。 这意味着在所有者尝试再次登录之前，攻击者不会破坏帐户。 如果所有者认为自己必须忘记密码并以相同的方式重设密码，它甚至可能不会被注意到。 仅仅希望访问该应用程序的攻击者可以在一段时间内破坏其他用户的帐户，因此可以无限期地继续使用该应用程序。
HACK STEPS
- 1.识别应用程序中所有忘记的密码功能。 如果未与发布的内容明确链接，则仍可以实施（请参见第4章）。
- 2.通过使用您控制的帐户进行完整的演练，了解忘记的密码功能的工作方式。
- 3.如果该机制使用质询，请确定用户是否可以设置或选择自己的质询和响应。 如果是这样，请使用列举的或常用的用户名列表来收集挑战列表，并对其进行复查以查找似乎容易猜到的任何挑战。
- 4.如果该机制使用密码“提示”，请执行相同的练习以收集密码提示列表，并定位任何容易猜到的提示。
- 5.尝试找出被遗忘的密码机制中的任何行为，这些行为可被用作用户名枚举或蛮力攻击的基础（请参阅前面的详细信息）。
- 6.如果应用程序响应忘记的密码请求而生成包含恢复URL的电子邮件，请获取这些URL的数量，然后尝试识别可能使您能够预测发布给其他用户的URL的任何模式。 采用与分析会话令牌以确保可预测性相同的技术（请参见第7章）。
Chapter 6 Attacking Authentication(2) - Design Flaws in Authentication Mechanisms(1)
Chapter 6 Attacking Authentication(2) - Design Flaws in Authentication Mechanisms(3)
