# 身份认证绕过

## 添加或更改邮箱地址

如果添加新邮箱地址或更改现有邮箱地址的操作不需要密码确认，会话劫持、XSS 或 CSRF 可能导致账户接管。

## Amazon Cognito 滥用

## 邮箱确认

### 使用确认链接绑定邮箱

尝试在账户 `B` 的会话中跟随账户 `A` 的确认链接。如果应用程序存在漏洞，它会将已验证的邮箱链接到账户 `B`。在这种情况下，攻击流程可能如下：

1. 攻击者将 `attacker@website.com` 链接到他们的账户。
2. 攻击者向受害者发送确认链接。
3. 受害者在登录应用程序时从邮件中点击链接。
4. 应用程序将 `attacker@website.com` 链接到受害者账户。

参考：

* [技术分析：注意这些链接：账户接管！](https://akashhamal0x01.medium.com/watch-out-the-links-account-takeover-32b9315390a7)

### 多个邮箱确认

添加新邮箱的方法可以在单个请求中接受多个邮箱地址。但是，该方法可能仅基于一个邮箱创建一次性令牌，但将包含恢复链接的邮件一次性发送到所有传递的邮箱。例如，如果应用程序对此类攻击存在漏洞，在以下请求中：

```http
PUT /user/profile HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/json
Content-Length: 57

{"email": ["victim@website.com", "attacker@website.com"]}
```

应用程序会向两个邮箱地址发送相同的确认链接。

您还可以尝试以下 payload：

```http
victim@website.com&attacker@website.com
victim@website.com,attacker@website.com
victim@website.com|attacker@website.com
victim@website.com%20attacker@website.com
victim@website.com%09attacker@website.com
victim@website.com%0a%0dcc:attacker@website.com
...
```

另一个类似的情况是，当确认链接发送到错误的邮箱时存在业务逻辑漏洞。例如，如果应用程序向已添加的主邮箱发送确认链接，而不是未确认的邮箱。

参考：

* [报告：myshop.myshopify.com 中的邮箱确认绕过导致通过利用 Shopify SSO 获得任意店铺所有者的完全权限提升](https://hackerone.com/reports/791775)

### 跳过确认过程

如果应用程序允许您在没有邮箱确认过程的情况下创建用户，您可以尝试滥用此功能来获取具有预确认邮箱的新用户。这在以下情况下至少是可能的：

* 应用程序允许创建具有预定义已确认邮箱的机器人用户。
* SCIM 预配功能。
* 通过易受攻击的服务进行 OAuth 认证，该服务允许使用未确认的账户进行认证。

参考：

* [报告：绕过邮箱验证——能够访问使用 Gitlab 登录并执行邮箱域名检查的内部 Gitlab 服务](https://gitlab.com/gitlab-org/gitlab/-/issues/11643)

### 使用未确认的邮箱

如果应用程序允许使用未确认的邮箱，请尝试在应用程序或其他应用程序/系统依赖邮箱地址的流程中滥用此行为。例如：

* 如果存在盲目信任易受攻击应用程序数据的应用程序/系统，您可以尝试滥用此信任。例如，如果应用程序可以用作 OAuth 授权服务器，请尝试使用具有未确认邮箱的账户通过 OAuth 向第三方应用程序进行身份验证，您可以在 [OAuth 2.0 漏洞：滥用具有未确认邮箱的账户](/web-ying-yong-an-quan/oauth-2.0-vulnerabilities.md#abusing-accounts-with-unconfirmed-email) 中找到更多详细信息。
* 尝试使用未确认的邮箱来抢占可能被其他用户使用或应用程序内部使用的邮箱。在这种情况下，您可以阻止所有或特定用户的某些应用程序功能。
* 如果某些功能不应对未确认其邮箱的用户可用，请检查这些功能对他们是否真的不可用。此外，请确保 REST 和 GraphQL API 也遵守相同的策略。

### 使用 OTP 进行邮箱确认

### 弱确认令牌

确认令牌可能使用易受攻击的生成算法生成，这可能导致预测生成值的可能性。如果您成功预测令牌，您将能够为任何邮箱生成有效的确认令牌。

## 信息泄露

应用程序在执行操作时可能会在响应中返回未知数据。这些可以是请求的密码、生成的 OTP、具有额外权限的 cookie、用户数据、详细的错误消息等。检查服务器响应中是否存在此类数据。

## OAuth 2.0

## 密码恢复

### Host 头部投毒

应用程序可以使用 `Host` 头部值来生成密码恢复链接。如果应用程序易受 `Host` 头部投毒攻击，您可以影响链接并指定您的域名。结果，如果受害者从邮件中点击链接，恢复令牌将泄露到您的域名。

有几种方法可以实现 `Host` 头部投毒。

#### Host 头部替换

您可以尝试将 `Host` 头部替换为您的域名。易受攻击请求的示例：

```http
POST /users/password HTTP/1.1
Host: attacker-website.com
Content-Type: application/json
Content-Length: 31

{"email": "victim@website.com"}
```

或绕过主机验证（参见 SSRF 相关文档）：

```http
POST /users/password HTTP/1.1
Host: attacker-website.com/vulnerable-website.com
Content-Type: application/json
Content-Length: 31

{"email": "victim@website.com"}
```

参考：

* [技术分析：通过 Host Header Poisoning 劫持密码重置链接](https://hackerone.com/reports/226659)

#### 覆盖 Host 头部

传递链中的组件，如代理，可以使用额外的 HTTP 头部传递客户端请求的原始主机：

您可以尝试使用这些头部来识别客户端在 `Host` 请求头部中请求的原始主机：

```http
POST /users/password HTTP/1.1
Host: vulnerable-website.com
x-forwarded-host: attacker-website.com
x-host: attacker-website.com
x-original-host: attacker-website.com
Content-Type: application/json
Content-Length: 31

{"email": "victim@website.com"}
```

参考：

* [技术分析：通过密码重置投毒实现账户接管](https://medium.com/@vbharad/account-takeover-through-password-reset-poisoning-72989a8bb8ea)

#### 多个 Host 头部

您可以尝试指定多个 `Host` 头部。易受攻击请求的示例：

```http
POST /users/password HTTP/1.1
Host: vulnerable-website.com
Host: attacker-website.com
Content-Type: application/json
Content-Length: 31

{"email": "victim@website.com"}
```

### 多个邮箱地址

密码恢复方法可以在一个请求中接受多个恢复邮箱。但是，该方法可以仅基于一个邮箱搜索账户来创建一次性令牌，但将包含恢复链接的邮件一次性发送到所有传递的邮箱。例如，如果应用程序对此类攻击存在漏洞，在以下请求中：

```http
POST /users/password HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/json
Content-Length: 57

{"email": ["victim@website.com", "attacker@website.com"]}
```

应用程序会向两个邮箱地址发送相同的恢复链接。

您还可以尝试以下 payload：

```http
victim@website.com&attacker@website.com
victim@website.com,attacker@website.com
victim@website.com|attacker@website.com
victim@website.com%20attacker@website.com
victim@website.com%09attacker@website.com
victim@website.com%0a%0dcc:attacker@website.com
...
```

参考：

* [技术分析：Readme.com 账户接管 #BugBounty #FullDisclosure #Fixed](https://medium.com/@0xankush/readme-com-account-takeover-bugbounty-fulldisclosure-a36ddbe915be)

### 账户和代码之间缺乏关联

尝试为您的账户请求一次性令牌，并使用它们来恢复受害者的账户：

```http
POST /users/password/recovery HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/json
Content-Length: 72

{"email": "victim@website.com","code": "<攻击者账户的代码>"}
```

### 密码恢复不会终止之前创建的会话

成功的密码恢复应该终止之前创建的会话。如果这种情况没有发生，受害者将无法管理其账户的安全性。结果，攻击者将能够在较长时间内保持活动会话。

### 通过 Referer 头部泄露令牌

[Referer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer) HTTP 请求头部包含发出请求的页面的绝对或部分地址。`Referer` 头部允许服务器识别人们访问它的页面。此数据用于分析、日志记录、优化缓存等。

Referer 头部可以包含 `origin`、`path` 和 `querystring`，可能不包含 URL 片段（即 `#section`）或 `username:password` 信息。请求的 referrer 策略定义了可以包含的数据，参见 [Referrer-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy)。

包含密码恢复的页面，应用程序通过邮件发送其链接，可以加载第三方脚本，例如分析，或包含指向第三方资源的链接，例如社交网络。如果在请求这些资源时将密码恢复链接传递到 `Referer` 头部中，一次性令牌会泄露到第三方资源，因为它被传递到 `querystring`。

参考：

* [报告：敏感信息的跨域泄露——导致 Instagram 品牌的账户接管](https://hackerone.com/reports/209352)
* [报告：\[跨域 Referer 泄露\] 密码重置令牌泄露到第三方网站。](https://hackerone.com/reports/265740)
* [报告：语言切换器中的 Referer 头部泄露可能导致 FB 令牌被盗](https://hackerone.com/reports/870062)

### 弱恢复令牌

恢复令牌可能使用易受攻击的生成算法生成，这可能导致预测生成值的可能性。如果您成功预测令牌，您将能够为任何账户生成有效的恢复令牌。

## 手机和 OTP 认证

### OTP 重发

如果应用程序没有对重发 OTP 设置速率限制，并且重发 OTP 会重置 OTP 输入尝试的速率限制，则应用程序易受 OTP 暴力破解攻击。

参考：

* [报告：使用手机登录选项进行授权绕过+在 Grab Android 应用程序上可能发生横向提权](https://hackerone.com/reports/205000)

### OTP 重用

如果应用程序允许使用已使用或重新生成的旧 OTP，任何 OTP 泄露（例如，泄露到日志或第三方服务）都将危及依赖 OTP 的功能。

### 会话固定

应用程序可以实现如下身份验证流程：

1. 应用程序调用 `/SessionCreate` 端点，传入用户的手机号码
2. 后端为用户创建会话并返回会话令牌，但在验证完成之前无法使用此会话进行操作
3. 向用户发送包含验证码的短信
4. 应用程序调用 `/SessionVerify` 端点，传入会话令牌和通过短信接收的验证码
5. 一旦此请求成功完成，会话令牌变为有效，用户现在已登录

如果后续对 `/SessionCreate` 的调用返回与第一次相同的会话令牌，直到调用 `/SessionVerify`，您可以使用 `/SessionCreate` 端点来获取将在受害者身份验证后有效的会话令牌。

参考：

* [报告：通过短信认证流程实现账户接管](https://hackerone.com/reports/1245762)

### 伪造认证请求的部分

如果在 OTP 检查期间应用程序额外使用某些参数，请尝试使用来自不同账户请求的值。该参数可以是 cookie、头部或请求参数。如果您在攻击者的 OTP 检查请求中使用受害者的参数值，您可以进入受害者账户或绕过双因子认证。

此外，尝试将攻击者的有效 OTP 值重新用作受害者的 OTP 值。如果应用程序不验证 OTP 是否属于攻击者，您将能够进入受害者账户或绕过双因子认证。

### 短期和长期 OTP

应用程序可以使用短期（少于5位）和/或长期 OTP。这种实现为暴力破解留下了许多方法，特别是在没有速率限制或速率限制较弱或可绕过的情况下。

## 速率限制

## 第三方登录或注册

实现第三方登录或注册的应用程序通常基于第三方应用程序发送的附加邮箱地址来识别用户。在这种情况下，您可以尝试使用链接到同一邮箱地址的两个不同的第三方应用程序进行登录或注册。有时这两个账户可以合并，您将通过您的第三方应用程序账户登录或注册来访问受害者的账户。

例如，假设受害者通过链接到 `victim@website.com` 的 `third-party-app1.com` 登录或注册到 `vulnerable-website.com`。要利用此漏洞，请尝试以下流程：

1. 在 `third-party-app2.com` 创建账户并输入 `victim@website.com` 邮箱地址（理想情况下不需要邮箱确认）
2. 尝试通过 `third-party-app2.com` 在 `vulnerable-website.com` 登录或注册
3. 如果应用程序存在漏洞，您将能够访问受害者的账户

参考：

* [技术分析：账户接管 https://teamplay.qiwi.com](https://hackerone.com/reports/439207)

## 用户名和密码认证

### 暴力破解

如果应用程序没有对登录尝试设置速率限制，请尝试制作字典并暴力破解密码。

速率限制的一种实现使用用户名或邮箱作为尝试计数的标识符。尝试通过使用额外空格或大小写来绕过保护：

```http
email=" username@website.com"
email="username@website.com  "
email="Username@website.com"
email="USERNAME@website.com"
...
```

您可以使用以下链接：

* [WordList Compendium](https://github.com/Dormidera/WordList-Compendium) - 个人编写的单词列表和字典集合，包含用户、密码、目录、文件、漏洞、模糊测试、注入、工具单词列表等。
* [SecLists](https://github.com/danielmiessler/SecLists) - 安全评估期间使用的多种类型列表的集合。
* [PWDB - 新一代密码大规模分析](https://github.com/ignis-sec/Pwdb-Public) - 从互联网10亿凭证泄露中提取的所有数据的集合。
* [bopscrk](https://github.com/r3nt0n/bopscrk) - 生成智能且强大的单词列表的工具。
* [BruteLoops](https://github.com/arch4ngel/BruteLoops) - 协议不可知的在线密码猜测 API。

参考：

* [报告：绕过报告 #708013 的修复](https://hackerone.com/reports/1363672)

### 凭证填充

[凭证填充](https://owasp.org/www-community/attacks/Credential_stuffing) 是搜索泄露的用户名和密码用于流行的在线服务，因为大多数用户在任何地方都"习惯于"使用相同的密码。

您可以使用以下列表：

* [PWDB - 新一代密码大规模分析](https://github.com/ignis-sec/Pwdb-Public)
* [SecLists](https://github.com/danielmiessler/SecLists)
* [Probable Wordlists - Version 2.0](https://github.com/berzerk0/Probable-Wordlists)

资源：

* [技术分析：漏洞赏金狩猎中的凭证填充](https://krevetk0.medium.com/credential-stuffing-in-bug-bounty-hunting-7168dc1d3153)
* Zeronights 2021: Valeriy Shevchenko – 奇妙的漏洞及其发现方法
  * [视频](https://www.youtube.com/watch?v=5rDGNm3DJfU)
  * [幻灯片](https://zeronights.ru/wp-content/uploads/2021/09/valeri_shevchenko_fantastic_b%CC%B6e%CC%B6a%CC%B6s%CC%B6t%CC%B6s%CC%B6_bugs_and_where_to_find_them_1.pdf)

### 默认凭证

尝试使用默认凭证登录管理面板、第三方服务、中间件等。

您可以使用以下列表：

* [默认凭证速查表](https://github.com/ihebski/DefaultCreds-cheat-sheet)
* [SecLists 默认凭证](https://github.com/danielmiessler/SecLists/tree/master/Passwords/Default-Credentials)

### 缺乏密码长度限制

大多数应用程序存储用户密码的哈希值，不以明文存储密码。因此，应用程序在验证用户时对传递的密码进行哈希处理，并将哈希值与数据库中存储的哈希值进行比较。此外，通常使用具有可变计算成本的函数作为哈希函数，其计算复杂性远高于常见的哈希函数，如 `sha256`。因此，如果应用程序没有实现对密码长度的限制，这可以用于 DoS：对非常长的密码进行哈希处理可能是资源密集型的。

## 参考

* [HackTricks：重置/忘记密码绕过](https://book.hacktricks.xyz/pentesting-web/reset-password)
* [双因子认证安全测试和可能的绕过](https://medium.com/@iSecMax/two-factor-authentication-security-testing-and-possible-bypasses-f65650412b35)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://gitbook.cdxiaodong.life/web-ying-yong-an-quan/broken-authentication.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.