Vulnerabilities in other authentication mechanisms其他身份验证机制中的漏洞

Posted Zeker62

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Vulnerabilities in other authentication mechanisms其他身份验证机制中的漏洞相关的知识,希望对你有一定的参考价值。

除了基本的登录功能外,大多数网站还提供补充功能以允许用户管理他们的帐户。例如,用户通常可以在忘记密码时更改密码或重置密码。这些机制还可能引入可被攻击者利用的漏洞。

网站通常会注意避免其登录页面中出现众所周知的漏洞。但是很容易忽略一个事实,即您需要采取类似的步骤来确保相关功能同样强大。在攻击者能够创建自己的帐户并因此可以轻松访问研究这些附加页面的情况下,这一点尤其重要。

保持用户登录

一个常见功能是即使在关闭浏览器会话后也可以保持登录状态。这通常是一个简单的复选框,标记为“记住我”或“保持登录状态”。

此功能通常通过生成某种类型的“记住我”令牌来实现,然后将其存储在持久性 cookie 中。由于有效地拥有此 cookie 可以让您绕过整个登录过程,因此最好不要猜测此 cookie。但是,某些网站会根据可预测的静态值串联生成此 cookie,例如用户名和时间戳。有些人甚至使用密码作为 cookie 的一部分。如果攻击者能够创建自己的帐户,则这种方法特别危险,因为他们可以研究自己的 cookie 并可能推断出它是如何生成的。一旦他们计算出公式,他们就可以尝试强制使用其他用户的 cookie 来访问他们的帐户。

一些网站假设,如果 cookie 以某种方式加密,即使它确实使用静态值也不会被猜测。虽然如果做得正确,这可能是正确的,但使用简单的双向编码(如 Base64)天真地“加密”cookie 不会提供任何保护。即使使用带有单向哈希函数的正确加密也不是完全防弹的。如果攻击者能够轻松识别散列算法,并且不使用盐,他们就可以通过简单地散列他们的单词列表来暴力破解 cookie。如果类似的限制不适用于 cookie 猜测,则此方法可用于绕过登录尝试限制。

即使攻击者无法创建自己的帐户,他们仍然可以利用此漏洞。使用通常的技术,例如XSS,攻击者可以窃取另一个用户的“记住我”cookie,并从中推断出 cookie 的构造方式。如果网站是使用开源框架构建的,cookie 构建的关键细节甚至可能被公开记录。

在极少数情况下,即使经过哈希处理,也可以从 cookie 中以明文形式获取用户的实际密码。众所周知的密码列表的散列版本可在线获取,因此如果用户的密码出现在这些列表之一中,解密散列有时就像将散列粘贴到搜索引擎中一样微不足道。这证明了盐在有效加密中的重要性。

重置用户密码

在实践中,某些用户会忘记他们的密码是很正常的,因此通常有一种方法可以让他们重置密码。由于通常的基于密码的身份验证在这种情况下显然是不可能的,因此网站必须依靠其他方法来确保真实用户正在重置自己的密码。出于这个原因,密码重置功能本质上是危险的,需要安全地实施。

此功能通常有几种不同的实现方式,具有不同程度的脆弱性。

通过电子邮件发送密码

毋庸置疑,如果网站首先安全地处理密码,则永远不可能向用户发送他们当前的密码。相反,一些网站会生成一个新密码并通过电子邮件将其发送给用户。

一般而言,应避免通过不安全的通道发送持久密码。在这种情况下,安全性依赖于生成的密码在很短的时间内到期,或者用户立即再次更改密码。否则,这种方法很容易受到中间人攻击。

鉴于收件箱既是持久性的,又不是真正为机密信息的安全存储而设计的,因此通常也不认为电子邮件是安全的。许多用户还通过不安全的渠道在多个设备之间自动同步他们的收件箱。

使用 URL 重置密码

一种更可靠的密码重置方法是向用户发送一个唯一的 URL,将他们带到密码重置页面。此方法的安全性较低的实现使用带有易于猜测的参数的 URL 来识别正在重置的帐户,例如:

http://vulnerable-website.com/reset-password?user=victim-user

在此示例中,攻击者可以更改user参数以引用他们已识别的任何用户名。然后他们会被直接带到一个页面,在那里他们可以为这个任意用户设置一个新密码。

这个过程的一个更好的实现是生成一个高熵、难以猜测的令牌,并基于它创建重置 URL。在最好的情况下,此 URL 不应提供有关正在重置哪个用户的密码的提示。

http://vulnerable-website.com/reset-password?token=a0ba0d1cb3b63d13822572fcff1a241895d893f659164d4cc550b421ebdd48a8

当用户访问这个 URL 时,系统应该检查这个令牌是否存在于后端,如果存在,它应该重置哪个用户的密码。此令牌应在短时间内过期并在重置密码后立即销毁。

但是,某些网站在提交重置表单时也无法再次验证令牌。在这种情况下,攻击者可以简单地从他们自己的帐户访问重置表单,删除令牌,并利用此页面重置任意用户的密码。

如果重置邮件中的 URL 是动态生成的,这也可能容易受到密码重置中毒的影响。在这种情况下,攻击者可能会窃取另一个用户的令牌并使用它来更改他们的密码。

密码重置中毒

密码重置中毒是一种攻击者操纵易受攻击的网站生成指向其控制域的密码重置链接的技术。可以利用这种行为窃取重置任意用户密码所需的秘密令牌,并最终危及他们的帐户。

密码重置如何工作?

几乎所有需要登录的网站都实现了允许用户在忘记密码时重置密码的功能。有几种方法可以做到这一点,具有不同程度的安全性和实用性。最常见的方法之一是这样的:

  • 用户输入他们的用户名或电子邮件地址并提交密码重置请求。
  • 该网站会检查该用户是否存在,然后生成一个临时的、唯一的、高熵的令牌,并将其与后端的用户帐户相关联。
  • 该网站向用户发送一封电子邮件,其中包含重置密码的链接。用户唯一的重置令牌作为查询参数包含在相应的 URL 中:
    https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9j
  • 当用户访问此 URL 时,网站会检查所提供的令牌是否有效并使用它来确定正在重置哪个帐户。如果一切都符合预期,用户可以选择输入新密码。最后,令牌被销毁。

与其他一些方法相比,此过程足够简单且相对安全。然而,它的安全性依赖于这样一个原则,即只有目标用户才能访问他们的电子邮件收件箱,因此,才能访问他们的唯一令牌。密码重置中毒是一种窃取此令牌以更改其他用户密码的方法

如何构建密码重置中毒攻击

如果发送给用户的 URL 是基于可控输入动态生成的,例如 Host 头,则可能构造如下密码重置中毒攻击:

  • 攻击者根据需要获取受害者的电子邮件地址或用户名,并代表他们提交密码重置请求。提交表单时,他们拦截生成的 HTTP 请求并修改 Host 标头,使其指向他们控制的域。对于此示例,我们将使用evil-user.net.
  • 受害者直接从网站收到一封真正的密码重置电子邮件。这似乎包含一个用于重置其密码的普通链接,最重要的是,它包含与他们的帐户相关联的有效密码重置令牌。但是,URL 中的域名指向攻击者的服务器:https://evil-user.net/reset?token=0a1b2c3d4e5f6g7h8i9j
  • 如果受害者单击此链接(或以其他方式获取,例如通过防病毒扫描程序),则密码重置令牌将发送到攻击者的服务器。
  • 攻击者现在可以访问易受攻击网站的真实 URL,并通过相应的参数提供受害者的被盗令牌。然后他们将能够将用户的密码重置为他们喜欢的任何内容,然后登录到他们的帐户。

例如,在真正的攻击中,攻击者可能会通过首先用虚假的违规通知预热受害者来增加受害者点击链接的可能性。

即使您无法控制密码重置链接,您有时也可以使用 Host 标头将 html 注入敏感电子邮件。请注意,电子邮件客户端通常不执行 javascript,但其他 HTML 注入技术(如悬空标记攻击)可能仍然适用。

更改用户密码

通常,更改密码涉及输入当前密码,然后输入两次新密码。这些页面从根本上依赖与正常登录页面相同的过程来检查用户名和当前密码是否匹配。因此,这些页面可能容易受到相同技术的攻击。

如果密码更改功能允许攻击者直接访问它而无需以受害者用户身份登录,则该功能可能特别危险。例如,如果用户名在隐藏字段中提供,攻击者可能能够在针对任意用户的请求中编辑此值。这可能会被利用来枚举用户名和暴力密码。

靶场链接:

以上是关于Vulnerabilities in other authentication mechanisms其他身份验证机制中的漏洞的主要内容,如果未能解决你的问题,请参考以下文章

article2pdf (Wordpress plug-in) Multiple vulnerabilities(CVE-2019-1000031, CVE-2019-1010257)

Vulnerabilities in multi-factor authentication:多因素身份验证漏洞

Vulnerabilities in password-based login:基于密码登录的漏洞

有报错: syntax error, '[' in D:\xampp\htdocs\DVWA\vulnerabilities\sqli\

查看漏洞修补情况:/sys/devices/system/cpu/vulnerabilities/*

XXE: XML eXternal Entity Injection vulnerabilities