4.4.9-测试弱密码更改或重置功能

开启学习模式

已于 2024-04-18 16:23:51 修改

阅读量77

点赞数

分类专栏： 4.4 认证测试文章标签： java 前端服务器 web安全

于 2023-10-18 09:26:20 首次发布

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

版权

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

12 篇文章 0 订阅

订阅专栏

本文详细探讨了在IT应用中测试和确保密码更改或重置功能的安全性，包括验证流程、常见漏洞、保护措施及适用场景，强调了遵循OWASP指南的重要性。

摘要由CSDN通过智能技术生成

测试弱密码更改或重置功能

ID
WSTG-ATHN-09

总结

对于任何要求用户使用密码进行身份验证的应用程序，必须有一种机制，用户在忘记密码时可以重新获得对其帐户的访问权限。虽然这有时可能是一个涉及联系网站所有者或支持团队的手动过程，但通常允许用户执行自助密码重置，并通过提供其他一些身份证明来重新获得对其帐户的访问权限。

由于此功能提供了破坏用户帐户的直接途径，因此安全实施至关重要。

测试目标

确定密码更改和重置功能是否允许帐户被盗用。

如何测试

信息收集

第一步是收集有关哪些机制可用于允许用户在应用程序上重置其密码的信息。如果同一站点上有多个界面（例如 Web 界面、移动应用程序和 API），则应检查这些界面，以防它们提供不同的功能。

建立密码后，确定用户启动密码重置所需的信息。这可以是用户名或电子邮件地址（两者都可以从公共信息中获得），但也可以是内部生成的用户 ID。

一般关注点

无论使用何种特定方法重置密码，都需要考虑许多常见方面：

密码重置过程是否比身份验证过程弱？

密码重置过程提供了访问用户帐户的替代机制，因此至少应与通常的身份验证过程一样安全。但是，它可以提供一种更简单的方法来破坏帐户，尤其是在它使用较弱的身份验证因素（如安全问题）时。

此外，密码重置过程可能会绕过使用多重身份验证（MFA）的要求，这可能会大大降低应用程序的安全性。

是否有针对自动攻击的速率限制或其他保护措施？

与任何身份验证机制一样，密码重置过程应具有针对自动或暴力攻击的保护。有多种不同的方法可用于实现此目的，例如速率限制或使用 CAPTCHA。这些对于触发外部操作（如发送电子邮件或短信）或用户输入密码重置令牌的功能尤为重要。

还可以通过在连续尝试一定次数后将帐户从密码重置过程中锁定来防止暴力攻击。但是，这也可能阻止合法用户重置其密码并重新获得对其帐户的访问权限。

它是否容易受到常见攻击？

除了本指南中讨论的特定领域外，检查其他常见漏洞（如 SQL 注入或跨站点脚本）也很重要。

重置过程是否允许用户枚举？

有关详细信息，请参阅帐户枚举测试指南。

电子邮件 - 已发送新密码

在此模型中，一旦用户证明了自己的身份，就会通过电子邮件向他们发送一个新密码。这被认为不太安全，主要有两个原因：

密码以未加密的形式发送给用户。
在提出请求时，帐户的密码会更改，从而有效地将用户锁定在其帐户之外，直到他们收到电子邮件。通过重复请求，可以阻止用户访问其帐户。

在使用这种方法时，应审查以下方面：

用户是否被迫在初次登录时更改密码？

新密码通过未加密的电子邮件发送，如果用户不删除电子邮件，则可能会无限期地保留在用户的收件箱中。因此，应要求用户在首次登录后立即更改密码。

密码是否安全生成？

密码应使用加密安全伪随机数生成器（CSPRNG）生成，并且应足够长，以防止密码猜测或暴力攻击。为了获得安全的用户友好体验，应使用安全的密码短语样式方法（即组合多个单词）而不是随机字符字符串生成它。

是否将用户的现有密码发送给他们？

某些应用程序不会为用户生成新密码，而是向用户发送其现有密码。这是一种非常不安全的方法，因为它会在未加密的电子邮件中暴露其当前密码。此外，如果站点能够恢复现有密码，这意味着密码要么使用可逆加密存储，要么（更有可能）以未加密的纯文本存储，这两者都代表了严重的安全漏洞。

从具有反欺骗保护的域发送的电子邮件是否？

该域应实现 SPF、DKIM 和 DMARC，以防止攻击者欺骗来自它的电子邮件，这可能被用作社会工程攻击的一部分。

电子邮件是否被认为足够安全？

电子邮件通常是未加密发送的，在许多情况下，用户的电子邮件帐户不会受到 MFA 的保护。它也可以在多个人之间共享，尤其是在公司环境中。

根据正在测试的应用程序的上下文，考虑基于电子邮件的密码重置功能是否合适。

电子邮件 - 链接已发送

在此模型中，用户将通过电子邮件收到一个包含令牌的链接。然后，他们可以单击此链接，并提示他们在网站上输入新密码。这是用于密码重置的最常见方法，但实现起来比前面讨论的方法更复杂。要测试的关键领域是：

链接是否使用 HTTPS？

如果令牌是通过未加密的 HTTP 发送的，则攻击者可能会拦截它。

该链接可以多次使用吗？

链接在使用后应过期，否则它们会为帐户提供持久的后门。

如果链接未使用，链接是否会过期？

链接应有时间限制。确切的时间合适将取决于网站，但很少超过一个小时。

令牌是否足够长且随机？

该过程的安全性完全依赖于攻击者无法猜测或暴力破解令牌。令牌应使用加密安全伪随机数生成器（CSPRNG）生成，并且应足够长，以至于攻击者无法猜测或暴力破解。至少 128 位（或 32 个十六进制字符）足以使这种在线攻击变得不切实际。

绝不应基于已知值生成令牌，例如，通过使用md5($email)获取用户电子邮件的 MD5 哈希值，或使用可能使用不安全的 PRNG 函数的 GUID，或者甚至可能不是随机的，具体取决于类型。

随机令牌的另一种方法是使用加密签名的令牌，例如 JWT。在这种情况下，应该进行通常的JWT检查（签名是否经过验证，是否可以使用“nONe”算法，HMAC密钥是否可以被暴力破解等）。有关详细信息，请参阅测试 JSON Web 令牌指南。

链接是否包含用户 ID？

有时，密码重置链接可能包括用户 ID 和令牌，例如 reset.php?userid=1&token=123456.在这种情况下，可以修改 userid 参数以重置其他用户的密码。

您可以注入不同的主机标头吗？

如果应用程序信任 Host 标头的值并使用它来生成密码重置链接，则可以通过将修改后的 Host 标头注入请求来窃取令牌。有关详细信息，请参阅主机标头注入测试指南。

链接是否暴露给第三方？

如果用户进入的页面包含来自其他方的内容（例如从其他域加载脚本），则 URL 中的重置令牌可能会在这些请求中发送的 HTTP Referer 标头中公开。HTTP Referrer-Policy 标头可用于防止这种情况，因此请检查是否为页面定义了一个标头。RefererReferrer-Policy

此外，如果页面包含任何跟踪、分析或广告脚本，令牌也将向它们公开。