参考: The Web Application Hacker’s Handbook Chapter 6

由于实施中的错误，即使是设计良好的身份验证机制也可能非常不安全。这些错误可能导致信息泄漏，完整的登录绕过或削弱所设计机制的整体安全性。与设计缺陷（例如劣质密码和强行强制性）相比，实现缺陷往往更微妙且更难检测。因此，它们通常是针对最关键安全性应用程序进行攻击的富有成效的目标，在这些应用程序中，许多威胁模型和渗透测试很可能会夺走低谷。作者已经在大型银行部署的Web应用程序中标识了此处描述的每个实现缺陷。

失效开放逻辑是一种逻辑流（在第11章中有详细描述），在认证机制的上下文中会产生特别严重的后果。

以下是一个相当人为的登录机制示例，该机制无法打开。如果对db.getUser()的调用由于某种原因引发异常（例如，由于用户的请求不包含用户名或密码参数而导致出现空指针异常），则登录成功。尽管生成的会话可能未绑定到特定的用户身份，因此可能未完全正常运行，但仍可能使攻击者能够访问某些敏感数据或功能。

public Response checkLogin(Session session) {
	try {
		String uname = session.getParameter(“username”);
		String passwd = session.getParameter(“password”);
		User user = db.getUser(uname, passwd);
		if (user == null) {
			// invalid credentials
			session.setMessage(“Login failed. “);
			return doLogin(session);
		}
	}
	catch (Exception e) {}

	// valid user
	session.setMessage(“Login successful. “);
	return doMainMenu(session);
}

在该字段中，即使最粗略的安全检查，您也不希望像这样的代码通过。但是，相同的概念缺陷更可能存在于更复杂的机制中，在该机制中进行了许多分层的方法调用，其中可能会出现并在不同的地方处理许多潜在的错误，并且更复杂的验证逻辑可能涉及维护无法说明登录进度。

HACK STEPS

1.使用您控制的帐户执行完整，有效的登录。使用拦截代理记录提交给应用程序的所有数据以及收到的每个响应。
2.重复多次登录过程，以意外的方式修改提交的部分数据。例如，对于客户端发送的每个请求参数或cookie，请执行以下操作：
- a.提交一个空字符串作为值。
- b.完全删除名称/值对。
- c.提交非常长和非常短的值。
- d.提交字符串而不是数字，反之亦然。
- e.多次提交相同的项目，并使用相同和不同的值。
3.对于提交的每个格式错误的请求，请仔细检查应用程序的响应，以发现与基本情况之间的任何差异。
4.将这些观察结果反馈给构建测试用例。当一项修改导致行为发生变化时，请尝试将此行为与其他更改结合起来，以将应用程序的逻辑推到极限。

某些应用程序使用复杂的登录机制，涉及多个阶段，例如:

输入用户名和密码
PIN码或难忘单词对特定数字的挑战
提交更改的物理令牌上显示的值

多级登录机制旨在通过基于用户名和密码的简单模型提供增强的安全性。通常，第一阶段要求用户使用用户名或类似项目标识自己，随后的阶段执行各种身份验证检查。这种机制经常包含安全漏洞，尤其是各种逻辑漏洞（请参阅第11章）。

多阶段登录机制的某些实现在每个阶段都对用户与较早阶段的交互进行了潜在的不安全假设：

应用程序可以假定访问第三阶段的用户必须已清除第一阶段和第二阶段。因此，它可以对直接从第一阶段进入第三阶段的攻击者进行身份验证，并正确完成该过程，从而使攻击者仅使用通常所需的各种凭据中的一部分即可登录。
应用程序可能会信任第二阶段正在处理的某些数据，因为该数据已在第一阶段进行了验证。但是，攻击者也许可以在第二阶段操纵此数据，使其值不同于在第一阶段验证的值。例如，在第一阶段，应用程序可能会确定用户的帐户是否已过期，是否被锁定或在管理组中，或者是否需要在第二阶段之后完成登录的其他阶段。如果攻击者可以在不同阶段之间进行登录转换时干扰这些标志，则他可能能够修改应用程序的行为，并使其仅使用部分凭据或其他特权来对他进行身份验证。
应用程序可以假定使用相同的用户身份来完成每个阶段；例如，但是，它可能未明确检查。例如，第一阶段可能涉及提交有效的用户名和密码，第二阶段可能涉及重新提交用户名（现在处于隐藏形式字段）和更改的物理令牌中的值。如果攻击者在每个阶段都提交有效的数据对，但针对不同的用户，则应用程序可能会将用户身份验证为两个阶段中使用的身份之一，这将使拥有自己的物理令牌的攻击者能够发现另一个用户的密码以该用户身份登录（反之亦然）。尽管在没有任何先验信息的情况下无法完全破坏登录机制，但是其总体安全状况被大大削弱，并且实施两因素机制的大量费用和精力并未带来预期的收益。

HACK STEPS

1.使用您控制的帐户执行完整，有效的登录。使用拦截代理记录提交给应用程序的所有数据。
2.标识登录的每个不同阶段以及在每个阶段收集的数据。确定是否收集任何一条信息是一次以上还是将其发送回客户端，然后通过隐藏的表单字段，cookie或预设的URL参数重新提交（请参阅第5章）。
3.对各种格式错误的请求重复多次登录过程：
- a.尝试以其他顺序执行登录步骤。
- b.尝试直接进入任何给定阶段，然后从那里继续。
- c.尝试跳过每个阶段，然后继续进行下一个阶段。
- d.用您的想象力思考其他方法，以访问开发人员可能未曾预料到的不同阶段。
4.如果有多个数据提交了多次，请尝试在不同的阶段提交不同的值，然后查看登录是否仍然成功。可能某些提交是多余的，而应用程序并未对其进行实际处理。可能是在一个阶段验证了数据，然后随后对其进行信任。在这种情况下，请尝试在一个阶段提供一个用户的凭据，然后在下一个阶段切换以实际身份验证为其他用户。可能是同一数据段经过了多个阶段的验证，但受到了不同的检查。在这种情况下，请尝试在第一阶段提供（例如）一个用户的用户名和密码，并在第二阶段提供另一用户的用户名和PIN。
5.请密切注意通过客户端传输的，用户未直接输入的任何数据。应用程序可以使用此数据来存储有关登录进度状态的信息，并且在将其提交回服务器时，应用程序可以信任它。例如，如果对第三阶段的请求包含参数stage2complete = true，则可以通过设置该值直接进入第三阶段。尝试修改要提交的值，并确定这是否使您可以前进或跳过阶段。

一些登录机制在登录过程的其中一个阶段采用随机变化的问题。例如，提交用户名和密码后，可能会向用户询问各种“秘密”问题（关于母亲的娘家姓，出生地，第一所学校的名字）之一，或者从一个秘密短语中随机提交两个字母。此行为的基本原理是，即使攻击者捕获了用户一次输入的所有内容，这也无法使他在不同的情况下以该用户身份登录，因为会提出不同的问题。

在某些实现中，此功能被破坏，无法实现其目标：

应用程序可能会提出一个随机选择的问题，并将详细信息存储在隐藏的HTML表单字段或Cookie中，而不是存储在服务器上。用户随后提交答案和问题本身。这有效地使攻击者可以选择要回答的问题，从而使攻击者可以在一次捕获用户输入后重复登录。
该应用程序可能会在每次登录尝试时显示一个随机选择的问题，但不会记住给定用户是否未提交答案被问到哪个问题。如果稍后相同的用户发起新的登录尝试，则会生成另一个随机问题。这有效地使攻击者可以循环浏览问题，直到他收到自己知道答案的问题为止，从而使他能够在一次捕获用户输入的情况下重复登录。

这些条件中的第二个条件确实非常微妙，因此，许多实际应用程序很容易受到攻击。乍一看，向用户挑战一个难忘单词的两个随机字母的应用程序可能会正常运行并提供增强的安全性。但是，如果每次通过上一个身份验证阶段时都随机选择了字母，那么一次捕获用户登录名的攻击者可以简单地重新进行身份验证，直到请求他知道的两个字母为止，而不会冒着帐户锁定。

HACK STEPS

1.如果登录阶段之一使用随机变化的问题，请验证问题的详细信息是否与答案一起提交。如果是这样，请更改问题，提交与该问题相关的正确答案，并验证登录是否仍然成功。
2.如果应用程序无法使攻击者提交任意问题和答案，请使用一个帐户多次执行部分登录，然后每次都根据不同的问题进行操作。如果问题在每种情况下都发生变化，则攻击者仍然可以有效地选择要回答的问题。

NOTE 在某些应用中，登录的一个组成部分随机变化，该应用会在单个阶段收集所有用户的凭据。例如，主登录页面可以显示一个表单，其中包含用户名，密码和各种秘密问题之一的字段。每次加载登录页面时，机密问题都会更改。在这种情况下，机密问题的随机性无济于事，无法阻止攻击者重播捕获到用户输入的有效登录请求。无法修改登录过程的当前形式，因为攻击者可以简单地重新加载页面，直到他收到知道答案的变化的问题为止。在这种情况下的一种变体中，应用程序可以设置一个持久性cookie，以“确保”向任何给定用户提出相同的变化问题，直到该人正确回答为止。当然，可以通过修改或删除cookie来轻松规避此措施。

3.Insecure Storage of Credentials

如果应用程序不安全地存储了登录凭据，即使身份验证过程本身没有固有的缺陷，登录机制的安全性也会受到损害。

通常会遇到Web应用程序，其中用户凭据不安全地存储在数据库中。这可能涉及以明文形式存储密码。但是，如果使用标准算法（例如MD5或SHA-1）对密码进行哈希处理，则攻击者仍然可以根据预先计算的哈希值数据库简单地查看观察到的哈希值。由于应用程序所使用的数据库帐户必须具有对这些凭据的完全读/写访问权限，因此可以利用应用程序中的许多其他类型的漏洞来使您能够访问这些凭据，例如命令或SQL注入漏洞（请参见第9章）。）和访问控制的弱点（请参阅第8章）。

TIP
一些常用的哈希函数在线数据库可以在这里找到：

http://passcracking.com/index.php
http://authsecu.com/decrypter-dechiffrer-cracker-hash-md5/script-hash-md5.php

HACK STEPS

1.查看应用程序的所有与身份验证相关的功能，以及与用户维护有关的所有功能。如果您发现任何将用户密码传送回客户端的实例，则表明密码以明文形式或使用可逆加密方式存储不安全。
2.如果在应用程序中发现任何类型的任意命令或查询执行漏洞，请尝试在应用程序的数据库或文件系统中查找存储用户凭据的位置：
- a.查询这些以确定密码是否以未加密形式存储。
- b.如果密码以散列形式存储，请检查是否存在非唯一值，这表示已为帐户分配了通用密码或默认密码，并且哈希值未添加。
- c.如果使用无盐格式的标准算法对密码进行了哈希处理，请查询在线哈希数据库以确定相应的明文密码值。

Chapter 6 Attacking Authentication(2) - Design Flaws in Authentication Mechanisms(4)

Chapter 6 Attacking Authentication(4) - Securing Authentication

Chapter 6 Attacking Authentication(3) - Implementation Flaws in Authentication

3.Insecure Storage of Credentials

CATALOG

FEATURED TAGS

1.失效开放登录机制(Fail-Open Login Mechanisms)

2.多阶段登录机制中的缺陷(Defects in Multistage Login Mechanisms)

3.Insecure Storage of Credentials

CATALOG

FEATURED TAGS