4.4.11-测试多重身份验证（MFA）

开启学习模式

已于 2024-07-18 12:57:07 修改

阅读量52

点赞数

分类专栏： 4.4 认证测试文章标签： web安全

于 2023-10-18 09:29:28 首次发布

本文链接：https://blog.csdn.net/qq_44232452/article/details/133898777

版权

4.4 认证测试专栏收录该内容

12 篇文章 0 订阅

订阅专栏

测试多重身份验证（MFA）

ID
WSTG-ATHN-11

总结

许多应用程序将多重身份验证（MFA）作为额外的安全层来保护登录过程。这也称为双因素身份验证（2FA）或两步验证（2SV） - 尽管它们并不严格相同。MFA 意味着要求用户在登录时提供 *至少 *两个不同的身份验证因素。

MFA 为身份验证功能以及其他与安全相关的领域（例如凭据管理和密码恢复）增加了额外的复杂性，这意味着以正确和可靠的方式实现它至关重要。

测试目标

确定应用程序使用的 MFA 类型。
确定 MFA 实现是否可靠且安全。
尝试绕过 MFA。

如何测试

MFA 的类型

MFA 意味着身份验证至少需要满足以下两个因素：

因素(Factor)	例子(Examples）
你所知道的Something You Know	密码、PIN 和安全问题。Passwords, PINs and security questions.
你拥有的东西Something You Have	硬件或软件令牌、证书、电子邮件、短信和电话。Hardware or software tokens, certificates, email, SMS, and phone calls.
你的某种东西 Something You Are	指纹、面部识别、虹膜扫描、手印扫描和行为因素。Fingerprints, facial recognition, iris scans, handprint scans and behavioural factors.
位置 Location	源 IP 范围和地理位置。 Source IP ranges, and geolocation.

* 只有当电子邮件帐户本身受到 MFA 保护时，电子邮件才真正构成“您拥有的东西”。因此，它应该被认为比其他替代品（如证书或 TOTP）弱，并且在某些定义下可能不被接受为 MFA。

请注意，要求单个因素的多个示例（例如同时需要密码和 PIN）并不构成 MFA，尽管它可能比简单密码提供一些安全优势，并且可能被视为两步验证（2SV）。

由于在基于浏览器的环境中实现生物识别技术的复杂性，“Something You Are”很少用于 Web 应用程序，尽管它开始使用 WebAuthn 等标准。最常见的第二个因素是“你拥有的东西”。

检查 MFA 绕过

测试 MFA 的第一步是确定应用程序中的所有身份验证功能，其中可能包括：

主登录页面。
安全关键功能（例如禁用 MFA 或更改密码）。
联合登录提供程序。
API 端点（来自主 Web 界面和移动应用程序）。
替代（非 HTTP）协议。
测试或调试功能。

应检查所有不同的登录方法，以确保一致地执行 MFA。如果某些方法不需要 MFA，则这些方法可以提供一种简单的方法来绕过它们。

如果身份验证分多个步骤完成，则可以通过完成身份验证过程的第一步（输入用户名和密码），然后强制浏览到应用程序或直接发出 API 请求来绕过它，而无需完成第二阶段（输入 MFA 代码）。

在某些情况下，还可能有意实现 MFA 绕过，例如不需要 MFA：

来自特定 IP 地址（可能使用 X-Forwarded-ForHTTP 标头进行欺骗）。
当设置了特定的 HTTP 标头（例如 X-Debug）时。
对于特定的硬编码帐户（例如“root”或“breakglass”帐户）。

如果应用程序同时支持本地登录和联合登录，则如果这两种类型的帐户之间没有强分离，则可以绕过 MFA。例如，如果用户注册了本地帐户并为其配置了 MFA，但未在联合登录提供程序上的帐户上配置 MFA，则攻击者可能会通过破坏用户在联合登录提供程序上的帐户，在目标应用程序上使用相同的电子邮件地址重新注册（或链接）联合帐户。

最后，如果 MFA 是在与主应用程序不同的系统上实现的（例如在反向代理上，以保护本机不支持 MFA 的旧应用程序），则可以通过直接连接到后端应用程序服务器来绕过它，如如何映射应用程序体系结构.的指南中所述。

检查 MFA 管理

应用于从用户帐户内部管理 MFA 的功能应测试漏洞，包括：

用户是否需要重新进行身份验证才能删除或更改 MFA 设置？
MFA 管理功能是否容易受到跨站点请求伪造的影响？
其他用户的MFA设置可以通过IDOR漏洞进行修改吗？

检查 MFA 恢复选项

许多应用程序将为用户提供一种方法，让他们在无法使用第二个因素进行身份验证时（例如，如果他们丢失了手机）重新获得对其帐户的访问权限。这些机制通常代表应用程序中的一个重大弱点，因为它们有效地允许绕过第二个身份验证因素。

恢复代码

某些应用程序在启用 MFA 时会向用户提供恢复或备份代码列表，这些代码可用于登录。应检查这些以确保：

它们足够长且复杂，可以防止暴力攻击。
它们是安全生成的。
它们只能使用一次。
暴力保护已到位（例如帐户锁定）。
当使用代码时，用户会收到通知（通过电子邮件、短信等）。

有关详细信息，请参阅忘记密码备忘单中的“备份代码” 部分。

MFA 重置过程

如果应用程序实现 MFA 重置过程，则应以测试密码重置过程的相同方式进行测试。重要的是，此过程至少与应用程序的 MFA 实现一样强大。

替代身份验证

某些应用程序将允许用户通过其他方式证明其身份，例如使用安全问题。这通常代表一个明显的弱点，因为安全问题提供的安全级别远低于 MFA。

一次性密码

最常见的 MFA 形式是一次性密码（OTP）之一，它通常是六位数字代码（尽管它们可以更长或更短）。这些可以由服务器和用户生成（例如，使用身份验证器应用），也可以在服务器上生成并发送给用户。可以通过多种方式向用户提供此 OTP，包括：

Type	Description
HMAC 一次性密码（HOPT）	基于密钥和共享计数器的 HMAC 生成代码。
基于时间的一次性密码（TOTP）	根据密钥的 HMAC 和当前时间生成代码。
Email	通过电子邮件发送代码。
SMS	通过短信发送代码。
Phone	通过语音呼叫向电话号码发送代码。

OTP 通常在用户提供其用户名和密码后输入。应执行各种检查，包括：

多次 MFA 尝试失败后，帐户是否被锁定？
在跨不同帐户进行多次失败的 MFA 尝试后，用户的 IP 地址是否被阻止？
是否记录了失败的 MFA 尝试？
表单是否容易受到注入攻击，包括 SQL 通配符注入？

根据所使用的 OTP 类型，还应执行一些其他特定检查：

OTP如何发送给用户（电子邮件、短信、电话等）
- 是否有速率限制以防止短信/电话垃圾邮件花钱？
OTP（长度和键空间）有多强？
一次性密码的有效期是多久？
多个一次性密码是否同时有效？
OTP 可以多次使用吗？
OTP 是否与正确的用户帐户相关联，或者是否可以在其他帐户上使用它们进行身份验证？

HOTP 和 TOTP

HOTP 和 TOTP 代码都基于服务器和用户之间共享的密钥。对于 TOTP 代码，这通常以二维码的形式提供给用户，他们使用身份验证器应用程序扫描该二维码（尽管它也可以作为文本密钥提供供他们手动输入）。

如果密钥是在服务器上生成的，则应对其进行检查，以确保其足够长且足够复杂（RFC 4226 建议至少 160 位），并且它是使用安全函数随机生成的。

如果密钥可以由用户提供，则应强制执行适当的最小长度，并应检查输入是否存在通常的注入攻击。

TOTP 代码的有效期通常为 30 秒，但某些应用程序选择接受多个代码（例如上一个代码、当前代码和下一个代码），以处理服务器和用户设备上的系统时间之间的差异。某些应用程序可能允许在当前代码的任一侧使用多个代码，这可能使攻击者更容易猜测或暴力破解代码。下表显示了基于攻击者每秒能够发出 10 个请求的成功暴力破解 OTP 代码的机会，适用于仅接受当前代码或多个代码的应用程序（有关表后面的计算，请参阅本文 for the calculations behind the table)）。

有效代码	1小时后成功率	4小时后成功率	12小时后成功率	24小时后成功率
1	4%	13%	35%	58%
3	10%	35%	72%	92%
5	16%	51%	88%	99%
7	22%	63%	95%	99%

电子邮件、短信和电话

如果代码由服务器生成并发送到客户端，则应考虑以下方面：

传输机制（电子邮件、短信或语音）对于应用程序来说是否足够安全？
代码是否足够长和复杂？
代码是否使用安全随机函数生成？
代码的有效期是多久？
多个代码是同时有效，还是生成新代码会使前一个代码失效？
- 这是否可以用于通过反复请求代码来阻止对帐户的访问？
是否有足够的速率限制来防止攻击者请求大量代码？
- 大量通过电子邮件发送的代码可能会阻止服务器发送垃圾邮件。
- 大量的短信或语音通话可能会花费金钱，或被用来骚扰用户。

移动应用程序和推送通知
OTP 代码的另一种方法是向用户的手机发送推送通知，他们可以批准或拒绝。此方法不太常见，因为它要求用户安装特定于应用程序的身份验证器。

正确评估其安全性需要扩大测试范围，以涵盖移动应用程序及其使用的任何支持 API 或服务;这意味着它通常超出了传统 Web 应用程序测试的范围。但是，可以在不测试移动应用程序的情况下执行一些简单的检查，包括：

通知是否为用户提供了足够的上下文（IP 地址、位置等），以便用户就是否批准或拒绝通知做出明智的决定？
是否有任何类型的质询和响应机制（例如在网站上提供用户需要输入应用程序的代码 - 通常称为“号码匹配”或“号码质询”）？
是否有任何速率限制或机制可以防止用户收到垃圾邮件通知，希望他们只是盲目接受通知？

IP 地址和位置过滤

有时与 MFA 一起使用的因素之一是位置（“你所在的地方”），尽管这是否构成适当的身份验证因素是有争议的。在 Web 应用程序的上下文中，这通常意味着限制对特定 IP 地址的访问，或者只要用户从特定的受信任 IP 地址进行连接，就不提示用户输入第二个因素。这种情况的常见情况是，当从办公室 IP 范围连接时，仅使用用户的密码对用户进行身份验证，但在从其他位置连接时需要 OTP 代码。

根据实现的不同，用户可以通过设置 X-Forwarded-For 标头来欺骗受信任的 IP 地址，这可能允许他们绕过此检查。请注意，如果应用程序没有正确清理此标头的内容，则也可以在此处执行 SQL 注入等攻击。如果应用程序支持 IPv6，则还应检查这一点，以确保对这些连接应用适当的限制。X-Forwarded-For

此外，应审查受信任的 IP 地址，以确保它们不存在任何弱点，例如，如果它们包括：

不受信任的用户可以访问的 IP 地址（例如办公室中的访客无线网络）。
动态分配的 IP 地址可能会更改。
攻击者可以托管自己的系统（例如 Azure 或 AWS）的公用网络范围。

证书和智能卡
传输层安全性（TLS）通常用于加密客户端和服务器之间的通信，并为客户端提供一种机制来确认服务器的身份（通过将证书上的公用名（CN）或使用者备用名称（SAN）与请求的域进行比较）。但是，它还可以为服务器提供一种机制来确认客户端的身份，称为客户端证书身份验证或双向 TLS （mTLS）。对客户端证书身份验证的完整讨论超出了本指南的范围，但关键原则是用户提供由服务器验证的数字证书（存储在其计算机或智能卡上）。

测试的第一步是确定目标应用程序是否限制受信任颁发证书的证书颁发机构（CA）。可以使用各种工具或手动检查 TLS 握手来获取此信息。最简单的方法是使用 OpenSSL 的 s_client：

$ openssl s_client -connect example:443
[...]
Acceptable client certificate CA names
C = US, ST = Example, L = Example, O = Example Org, CN = Example Org Root Certificate Authority
Client Certificate Types: RSA sign, DSA sign, ECDSA sign

如果没有限制，则可以使用来自其他 CA 的证书进行身份验证。如果存在限制，但实施不当，则可以创建具有正确名称的本地 CA（上例中的“示例组织根证书颁发机构”），并使用此新 CA 对客户端证书进行签名。

如果可以获取有效的证书，则还应验证该证书只能用于为其颁发证书的用户（即，您不能使用颁发给 Alice 的证书对 Bob 的帐户进行身份验证）。此外，应检查证书以确保它们既没有过期也没有被吊销。

修复

确保：

MFA 是为应用程序上的所有相关帐户和功能实现的。
支持 MFA 方法适用于应用程序。
用于实现 MFA 的机制得到适当的保护，并防止暴力攻击。
所有与 MFA 相关的活动都有适当的审核和日志记录。

有关进一步的建议，请参阅 OWASP 多重身份验证备忘单。

引用

OWASP多因素身份验证备忘单

开启学习模式

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
4.4.11-测试多重身份验证（MFA）

许多应用程序将多重身份验证（MFA）作为额外的安全层来保护登录过程。这也称为双因素身份验证（2FA）或两步验证（2SV） - 尽管它们并不严格相同。MFA 意味着要求用户在登录时提供 *至少 *两个不同的身份验证因素。MFA 为身份验证功能以及其他与安全相关的领域（例如凭据管理和密码恢复）增加了额外的复杂性，这意味着以正确和可靠的方式实现它至关重要。
复制链接

扫一扫