Translated ['src/generic-methodologies-and-resources/external-recon-meth

2025-10-10 18:36:50 +00:00 · 2025-03-29 22:58:10 +00:00 · 2025-03-29 22:58:10 +00:00 · 3c728d8bc6
commit 3c728d8bc6
parent d6c058f388
3 changed files with 85 additions and 52 deletions
--- a/src/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.md
+++ b/src/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.md
@ -2,16 +2,13 @@

 {{#include ../../banners/hacktricks-training.md}}

-现在我们已经建立了我们范围内资产的列表，是时候寻找一些OSINT的低垂果实了。
-
-### 已经搜索泄露的平台
-
- [https://trufflesecurity.com/blog/introducing-forager/](https://trufflesecurity.com/blog/introducing-forager/)
-
-### Github中的Api密钥泄露
+### 在 git 仓库和文件系统中查找秘密的工具

 - [https://github.com/dxa4481/truffleHog](https://github.com/dxa4481/truffleHog)
 - [https://github.com/gitleaks/gitleaks](https://github.com/gitleaks/gitleaks)
+- [https://github.com/praetorian-inc/noseyparker](https://github.com/praetorian-inc/noseyparker)
+- [https://github.com/GitGuardian/ggshield](https://github.com/GitGuardian/ggshield)
+- [https://github.com/JaimePolop/RExpository](https://github.com/JaimePolop/RExpository)
 - [https://github.com/Yelp/detect-secrets](https://github.com/Yelp/detect-secrets)
 - [https://github.com/hisxo/gitGraber](https://github.com/hisxo/gitGraber)
 - [https://github.com/eth0izzle/shhgit](https://github.com/eth0izzle/shhgit)
--- a/src/pentesting-web/oauth-to-account-takeover.md
+++ b/src/pentesting-web/oauth-to-account-takeover.md
@ -4,20 +4,20 @@

 ## 基本信息 <a href="#d4a8" id="d4a8"></a>

-OAuth 提供了多种版本，基础信息可在 [OAuth 2.0 documentation](https://oauth.net/2/) 中获取。本讨论主要集中在广泛使用的 [OAuth 2.0 授权码授权类型](https://oauth.net/2/grant-types/authorization-code/)，提供一个 **授权框架，使应用程序能够访问或在另一个应用程序中执行用户账户的操作**（授权服务器）。
+OAuth 提供了多种版本，基础信息可在 [OAuth 2.0 documentation](https://oauth.net/2/) 中获取。本讨论主要集中在广泛使用的 [OAuth 2.0 授权码授权类型](https://oauth.net/2/grant-types/authorization-code/)，提供一个 **授权框架，使应用程序能够访问或在另一个应用程序中执行用户账户上的操作**（授权服务器）。

-考虑一个假设的网站 _**https://example.com**_，旨在 **展示您所有的社交媒体帖子**，包括私人帖子。为此，采用 OAuth 2.0。_https://example.com_ 将请求您 **访问您的社交媒体帖子** 的权限。因此，_https://socialmedia.com_ 上会出现一个同意屏幕，概述 **请求的权限和发起请求的开发者**。在您授权后，_https://example.com_ 获得 **代表您访问您的帖子** 的能力。
+考虑一个假设的网站 _**https://example.com**_，旨在 **展示您所有的社交媒体帖子**，包括私人帖子。为此，采用 OAuth 2.0。_https://example.com_ 将请求您允许 **访问您的社交媒体帖子**。因此，_https://socialmedia.com_ 上会出现一个同意屏幕，概述 **请求的权限和发起请求的开发者**。在您授权后，_https://example.com_ 获得 **代表您访问您的帖子** 的能力。

 理解 OAuth 2.0 框架中的以下组件至关重要：

 - **资源拥有者**：您，作为 **用户/实体**，授权访问您的资源，例如您的社交媒体账户帖子。
- **资源服务器**：在应用程序代表 `资源拥有者` 获取 `access token` 后，**管理经过身份验证请求的服务器**，例如 **https://socialmedia.com**。
+- **资源服务器**：在应用程序为 `资源拥有者` 获取 `access token` 后，**管理经过身份验证请求的服务器**，例如 **https://socialmedia.com**。
 - **客户端应用程序**：向 `资源拥有者` 请求授权的 **应用程序**，例如 **https://example.com**。
 - **授权服务器**：在成功验证 `资源拥有者` 并获得授权后，**向 `客户端应用程序` 发放 `access tokens` 的服务器**，例如 **https://socialmedia.com**。
 - **client_id**：应用程序的公共唯一标识符。
 - **client_secret**：仅为应用程序和授权服务器所知的机密密钥，用于生成 `access_tokens`。
 - **response_type**：指定 **请求的令牌类型** 的值，例如 `code`。
- **scope**：`客户端应用程序` 请求的 **访问级别**。
+- **scope**：`客户端应用程序` 请求的 `资源拥有者` 的 **访问级别**。
 - **redirect_uri**：用户在授权后被重定向的 **URL**。这通常必须与预注册的重定向 URL 对齐。
 - **state**：一个参数，用于 **在用户重定向到授权服务器及返回时维护数据**。其唯一性对于作为 **CSRF 保护机制** 至关重要。
 - **grant_type**：指示 **授权类型和要返回的令牌类型** 的参数。
@ -27,10 +27,10 @@ OAuth 提供了多种版本，基础信息可在 [OAuth 2.0 documentation](https

 ### 流程

-**实际的 OAuth 流程** 如下：
+**实际的 OAuth 流程**如下：

 1. 您导航到 [https://example.com](https://example.com) 并选择“与社交媒体集成”按钮。
-2. 然后该网站向 [https://socialmedia.com](https://socialmedia.com) 发送请求，请求您的授权以让 https://example.com 的应用程序访问您的帖子。请求结构如下：
+2. 然后该网站向 [https://socialmedia.com](https://socialmedia.com) 发送请求，请求您的授权以让 https://example.com 的应用程序访问您的帖子。请求的结构为：
 ```
 https://socialmedia.com/auth
 ?response_type=code
@ -44,7 +44,7 @@ https://socialmedia.com/auth
 ```
 https://example.com?code=uniqueCode123&state=randomString123
 ```
-5. https://example.com 利用这个 `code`，连同它的 `client_id` 和 `client_secret`，向服务器发起请求以代表您获取 `access_token`，从而访问您同意的权限：
+5. https://example.com 利用这个 `code`，连同它的 `client_id` 和 `client_secret`，发起服务器端请求以代表您获取 `access_token`，从而访问您同意的权限：
 ```
 POST /oauth/access_token
 Host: socialmedia.com
@ -66,34 +66,34 @@ Host: socialmedia.com

 ### 重定向实现中的 XSS <a href="#bda5" id="bda5"></a>

-正如在这个漏洞赏金报告中提到的 [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html)，重定向 **URL 可能在用户认证后被反射在服务器的响应中**，因此 **容易受到 XSS 攻击**。可能的测试有效载荷：
+正如在这个漏洞赏金报告中提到的 [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html)，重定向 **URL 可能在用户认证后被反射在服务器的响应中**，因此 **容易受到 XSS 攻击**。可以测试的有效载荷：
 ```
 https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>
 ```
-### CSRF - 不当处理状态参数 <a href="#bda5" id="bda5"></a>
+### CSRF - Improper handling of state parameter <a href="#bda5" id="bda5"></a>

-在OAuth实现中，**`state`参数**的误用或遗漏会显著增加**跨站请求伪造（CSRF）**攻击的风险。当`state`参数**未使用、作为静态值使用或未正确验证**时，攻击者可以绕过CSRF保护。
+在OAuth实现中，**`state`参数**的误用或遗漏会显著增加**跨站请求伪造（CSRF）**攻击的风险。当`state`参数**未使用、作为静态值使用，或未正确验证或与用户会话关联**时，就会出现此漏洞，从而允许攻击者绕过CSRF保护。

-攻击者可以通过拦截授权过程，将他们的账户与受害者的账户链接，从而导致潜在的**账户接管**。在使用OAuth进行**身份验证**的应用程序中，这尤其关键。
+攻击者可以通过拦截授权过程，将他们的账户与受害者的账户关联，从而利用这一点，导致潜在的**账户接管**，使用户登录几乎完成的属于攻击者的oauth流程。这在使用OAuth进行**身份验证**的应用程序中尤其关键。

-在各种**CTF挑战**和**黑客平台**中记录了此漏洞的真实案例，突显了其实际影响。该问题还扩展到与第三方服务的集成，如**Slack**、**Stripe**和**PayPal**，攻击者可以将通知或付款重定向到他们的账户。
+此漏洞的现实世界示例已在各种**CTF挑战**和**黑客平台**中记录，突显了其实际影响。该问题还扩展到与第三方服务的集成，如**Slack**、**Stripe**和**PayPal**，攻击者可以将通知或付款重定向到他们的账户。

 正确处理和验证**`state`参数**对于防范CSRF和保护OAuth流程至关重要。

-### 预账户接管 <a href="#ebe4" id="ebe4"></a>
+### Pre Account Takeover <a href="#ebe4" id="ebe4"></a>

 1. **在账户创建时未进行电子邮件验证**：攻击者可以预先使用受害者的电子邮件创建账户。如果受害者稍后使用第三方服务登录，应用程序可能会不经意地将此第三方账户链接到攻击者预先创建的账户，从而导致未经授权的访问。
 2. **利用宽松的OAuth电子邮件验证**：攻击者可能会利用不验证电子邮件的OAuth服务，通过注册其服务并将账户电子邮件更改为受害者的电子邮件来进行攻击。这种方法同样存在未经授权的账户访问风险，类似于第一种情况，但通过不同的攻击向量。

-### 秘密泄露 <a href="#e177" id="e177"></a>
+### Disclosure of Secrets <a href="#e177" id="e177"></a>

-识别和保护秘密OAuth参数至关重要。虽然**`client_id`**可以安全披露，但泄露**`client_secret`**会带来重大风险。如果`client_secret`被泄露，攻击者可以利用应用程序的身份和信任来**窃取用户的`access_tokens`**和私人信息。
+识别和保护秘密的OAuth参数至关重要。虽然**`client_id`**可以安全披露，但泄露**`client_secret`**会带来重大风险。如果`client_secret`被泄露，攻击者可以利用应用程序的身份和信任来**窃取用户的`access_tokens`**和私人信息。

-一个常见的漏洞出现在应用程序错误地在客户端而非服务器端处理授权`code`与`access_token`的交换。这一错误导致`client_secret`的暴露，使攻击者能够以应用程序的名义生成`access_tokens`。此外，通过社会工程学，攻击者可以通过向OAuth授权添加额外的范围来提升权限，进一步利用应用程序的信任状态。
+一个常见的漏洞出现在应用程序错误地在客户端而不是服务器端处理授权`code`与`access_token`的交换。这一错误导致`client_secret`的暴露，使攻击者能够以应用程序的名义生成`access_tokens`。此外，通过社会工程学，攻击者可以通过向OAuth授权添加额外的范围来提升权限，进一步利用应用程序的信任状态。

-### 客户端密钥暴力破解
+### Client Secret Bruteforce

-您可以尝试通过身份提供者**暴力破解服务提供者的client_secret**以窃取账户。\
+您可以尝试**暴力破解服务提供商的client_secret**与身份提供者，以试图窃取账户。\
 暴力破解的请求可能类似于：
 ```
 POST /token HTTP/1.1
@ -106,11 +106,11 @@ code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=au
 ```
 ### Referer Header leaking Code + State

-一旦客户端拥有了 **code 和 state**，如果它们在浏览到不同页面时 **反映在 Referer 头中**，那么就存在漏洞。
+一旦客户端拥有了 **code 和 state**，如果它们在用户浏览到不同页面时 **反映在 Referer 头中**，那么就存在漏洞。

 ### Access Token Stored in Browser History

-前往 **浏览器历史记录，检查访问令牌是否保存在其中**。
+前往 **浏览器历史记录并检查访问令牌是否保存在其中**。

 ### Everlasting Authorization Code

@ -126,7 +126,7 @@ code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=au

 ### AWS Cognito <a href="#bda5" id="bda5"></a>

-在这个漏洞赏金报告中：[**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) 你可以看到 **AWS Cognito** 返回给用户的 **token** 可能具有 **足够的权限来覆盖用户数据**。因此，如果你可以 **将用户邮箱更改为其他用户邮箱**，你可能能够 **接管** 其他账户。
+在这个漏洞赏金报告中：[**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) 你可以看到 **AWS Cognito** 返回给用户的 **令牌** 可能具有 **足够的权限来覆盖用户数据**。因此，如果你可以 **将用户电子邮件更改为其他用户的电子邮件**，你可能能够 **接管** 其他账户。
 ```bash
 # Read info of the user
 aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]
@ -153,14 +153,14 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticat

 正如 [**在这篇文章中提到的**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts)，期望接收 **token**（而不是代码）的 OAuth 流程可能会受到攻击，如果它们没有检查该 token 是否属于该应用程序。

-这是因为 **攻击者** 可以在自己的应用程序中创建一个 **支持 OAuth 并使用 Facebook 登录的应用程序**（例如）。然后，一旦受害者在 **攻击者的应用程序** 中使用 Facebook 登录，攻击者就可以获取 **分配给其应用程序的用户的 OAuth token，并使用它在受害者的 OAuth 应用程序中登录，使用受害者的用户 token**。
+这是因为 **攻击者** 可以创建一个 **支持 OAuth 的应用程序并使用 Facebook 登录**（例如）在自己的应用程序中。然后，一旦受害者在 **攻击者的应用程序** 中使用 Facebook 登录，攻击者就可以获取 **分配给其应用程序的用户的 OAuth token，并使用它在受害者的 OAuth 应用程序中登录，使用受害者的用户 token**。

 > [!CAUTION]
 > 因此，如果攻击者设法让用户访问自己的 OAuth 应用程序，他将能够在期望 token 且未检查 token 是否授予其应用程序 ID 的应用程序中接管受害者的帐户。

 ### 两个链接和 cookie <a href="#bda5" id="bda5"></a>

-根据 [**这篇文章**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f)，可以让受害者打开一个指向攻击者主机的 **returnUrl** 的页面。此信息将被 **存储在 cookie (RU)** 中，在 **后续步骤** 中，**提示** 将 **询问** **用户** 是否希望授予对该攻击者主机的访问权限。
+根据 [**这篇文章**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f)，可以让受害者打开一个 **returnUrl** 指向攻击者主机的页面。此信息将 **存储在 cookie (RU)** 中，在 **后续步骤** 中，**提示** 将 **询问** **用户** 是否希望授予对该攻击者主机的访问权限。

 为了绕过此提示，可以打开一个选项卡以启动 **Oauth 流程**，该流程将使用 **returnUrl** 设置此 RU cookie，在提示显示之前关闭选项卡，然后打开一个没有该值的新选项卡。然后，**提示不会通知攻击者的主机**，但 cookie 将被设置为它，因此 **token 将在重定向中发送到攻击者的主机**。

@ -170,7 +170,7 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticat

 ### response_mode

-正如 [**在这段视频中解释的**](https://www.youtube.com/watch?v=n9x7_J_a_7Q)，可能可以指示参数 **`response_mode`** 以指示希望在最终 URL 中提供代码的位置：
+正如 [**在这段视频中解释的**](https://www.youtube.com/watch?v=n9x7_J_a_7Q)，可能可以指示参数 **`response_mode`** 来指示您希望在最终 URL 中提供代码的位置：

 - `response_mode=query` -> 代码在 GET 参数中提供： `?code=2397rf3gu93f`
 - `response_mode=fragment` -> 代码在 URL 片段参数中提供 `#code=2397rf3gu93f`
@ -181,14 +181,14 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticat

 根据 [**这篇博客文章**](https://cybxis.medium.com/a-bypass-on-gitlabs-login-email-verification-via-oauth-ropc-flow-e194242cad96)，这是一个允许通过 **用户名** 和 **密码** 登录 OAuth 的 OAuth 流程。如果在这个简单流程中返回一个具有用户可以执行的所有操作的访问权限的 **token**，那么就可以使用该 token 绕过 2FA。

-### 基于开放重定向到引用者的网页重定向 ATO <a href="#bda5" id="bda5"></a>
+### 基于开放重定向的网页重定向 ATO <a href="#bda5" id="bda5"></a>

-这篇 [**博客文章**](https://blog.voorivex.team/oauth-non-happy-path-to-ato) 评论了如何利用 **开放重定向** 从 **引用者** 的值滥用 OAuth 进行 ATO。攻击步骤如下：
+这篇 [**博客文章**](https://blog.voorivex.team/oauth-non-happy-path-to-ato) 评论了如何利用 **开放重定向** 从 **referrer** 的值滥用 OAuth 进行 ATO。攻击过程如下：

 1. 受害者访问攻击者的网页
-2. 受害者打开恶意链接，打开者开始使用 `response_type=id_token,code&prompt=none` 作为附加参数的 Google OAuth 流程，引用者为 **攻击者网站**。
-3. 在打开者中，提供者在授权受害者后，将他们发送回 `redirect_uri` 参数的值（受害者网站），并带有 30X 代码，这仍然保持攻击者网站在引用者中。
-4. 受害者 **网站根据引用者触发开放重定向**，将受害者用户重定向到攻击者网站，因为 **`respose_type`** 是 **`id_token,code`**，代码将通过 URL 的 **片段** 返回给攻击者，从而使他能够通过 Google 在受害者网站上接管用户的帐户。
+2. 受害者打开恶意链接，打开者使用 `response_type=id_token,code&prompt=none` 作为附加参数启动 Google OAuth 流程，**referrer 为攻击者网站**。
+3. 在打开者中，提供者在授权受害者后，将他们发送回 `redirect_uri` 参数的值（受害者网站），并带有 30X 代码，这仍然保持攻击者网站在 referer 中。
+4. 受害者 **网站根据 referrer 触发开放重定向**，将受害者用户重定向到攻击者网站，因为 **`respose_type`** 是 **`id_token,code`**，代码将通过 URL 的 **fragment** 返回给攻击者，从而使他能够通过 Google 在受害者网站上接管用户的帐户。

 ### SSRFs 参数 <a href="#bda5" id="bda5"></a>

@ -198,26 +198,48 @@ OAuth 中的动态客户端注册作为一个不太明显但关键的安全漏

 **关键点：**

- **动态客户端注册** 通常映射到 `/register`，并接受如 `client_name`、`client_secret`、`redirect_uris` 和通过 POST 请求的 logo 或 JSON Web Key Sets (JWKs) 的 URL 等详细信息。
+- **动态客户端注册** 通常映射到 `/register`，并接受诸如 `client_name`、`client_secret`、`redirect_uris` 和用于徽标或 JSON Web 密钥集 (JWKs) 的 URL 的 POST 请求。
 - 此功能遵循 **RFC7591** 和 **OpenID Connect Registration 1.0** 中列出的规范，其中包括可能对 SSRF 易受攻击的参数。
 - 注册过程可能会以多种方式无意中使服务器暴露于 SSRF：
- **`logo_uri`**：客户端应用程序 logo 的 URL，服务器可能会获取该 URL，从而触发 SSRF 或导致 XSS（如果 URL 处理不当）。
- **`jwks_uri`**：客户端 JWK 文档的 URL，如果恶意构造，可能导致服务器向攻击者控制的服务器发出外部请求。
- **`sector_identifier_uri`**：引用 `redirect_uris` 的 JSON 数组，服务器可能会获取该数组，从而创建 SSRF 机会。
+- **`logo_uri`**：客户端应用程序徽标的 URL，服务器可能会获取该 URL，从而触发 SSRF 或导致 XSS（如果 URL 处理不当）。
+- **`jwks_uri`**：客户端的 JWK 文档的 URL，如果恶意构造，可能导致服务器向攻击者控制的服务器发出外部请求。
+- **`sector_identifier_uri`**：引用 `redirect_uris` 的 JSON 数组，服务器可能会获取，从而创建 SSRF 机会。
 - **`request_uris`**：列出客户端允许的请求 URI，如果服务器在授权过程开始时获取这些 URI，则可能被利用。

 **利用策略：**

- 通过在 `logo_uri`、`jwks_uri` 或 `sector_identifier_uri` 等参数中注册带有恶意 URL 的新客户端，可以触发 SSRF。
+- 通过在参数如 `logo_uri`、`jwks_uri` 或 `sector_identifier_uri` 中注册带有恶意 URL 的新客户端，可以触发 SSRF。
 - 尽管通过白名单控制可能会减轻直接通过 `request_uris` 的利用，但提供一个预注册的、攻击者控制的 `request_uri` 可以在授权阶段促进 SSRF。

 ## OAuth 提供者竞争条件

 如果您正在测试的平台是 OAuth 提供者 [**请阅读此内容以测试可能的竞争条件**](race-condition.md)。

+## 可变声明攻击
+
+在 OAuth 中，sub 字段唯一标识用户，但其格式因授权服务器而异。为了标准化用户识别，一些客户端使用电子邮件或用户句柄。然而，这很危险，因为：
+
+- 一些授权服务器并不确保这些属性（如电子邮件）保持不变。
+- 在某些实现中——例如 **“使用 Microsoft 登录”**——客户端依赖于电子邮件字段，该字段由 **Entra ID 中的用户控制**，并未经过验证。
+- 攻击者可以通过创建自己的 Azure AD 组织（例如，doyensectestorg）并使用它执行 Microsoft 登录来利用这一点。
+- 尽管存储在 sub 中的对象 ID 是不可变且安全的，但对可变电子邮件字段的依赖可能会导致帐户接管（例如，劫持像 victim@gmail.com 这样的帐户）。
+
+## 客户端混淆攻击
+
+在 **客户端混淆攻击** 中，使用 OAuth 隐式流的应用程序未能验证最终访问 token 是否专门为其自己的客户端 ID 生成。攻击者设置一个公共网站，使用 Google 的 OAuth 隐式流，欺骗成千上万的用户登录，从而收集意图用于攻击者网站的访问 token。如果这些用户在另一个不验证 token 的客户端 ID 的易受攻击网站上也有帐户，攻击者可以重用收集到的 token 来冒充受害者并接管他们的帐户。
+
+## 范围升级攻击
+
+**授权代码授权** 类型涉及安全的服务器到服务器通信以传输用户数据。然而，如果 **授权服务器** 隐式信任访问令牌请求中的范围参数（RFC 中未定义的参数），恶意应用程序可以通过请求更高的范围来升级授权代码的权限。在生成 **访问令牌** 后，**资源服务器** 必须验证它：对于 JWT 令牌，这涉及检查 JWT 签名并提取数据，如 client_id 和 scope，而对于随机字符串令牌，服务器必须查询授权服务器以检索令牌的详细信息。
+
+## 重定向方案劫持
+
+在移动 OAuth 实现中，应用程序使用 **自定义 URI 方案** 来接收带有授权代码的重定向。然而，由于多个应用程序可以在设备上注册相同的方案，因此假设只有合法客户端控制重定向 URI 的假设被违反。例如，在 Android 上，像 `com.example.app://` 的 Intent URI 是根据方案和应用程序的 intent-filter 中定义的可选过滤器捕获的。由于 Android 的意图解析可能很广泛——尤其是如果仅指定方案——攻击者可以注册一个带有精心设计的意图过滤器的恶意应用程序，以劫持授权代码。这可以 **启用帐户接管**，无论是通过用户交互（当多个应用程序有资格处理意图时）还是通过利用过于特定的过滤器的绕过技术，如 Ostorlab 的评估流程图所详细说明的那样。
+
 ## 参考文献

 - [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1)
 - [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors)
+- [**https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html**](https://blog.doyensec.com/2025/01/30/oauth-common-vulnerabilities.html)

 {{#include ../banners/hacktricks-training.md}}
--- a/src/pentesting-web/unicode-injection/README.md
+++ b/src/pentesting-web/unicode-injection/README.md
@ -2,36 +2,36 @@

 {{#include ../../banners/hacktricks-training.md}}

-## 介绍
+## Introduction

-根据后端/前端在**接收奇怪的unicode字符**时的行为，攻击者可能能够**绕过保护并注入任意字符**，这些字符可能被用于**利用注入漏洞**，例如XSS或SQLi。
+根据后端/前端在**接收奇怪的unicode字符**时的表现，攻击者可能能够**绕过保护并注入任意字符**，这些字符可能被用于**利用注入漏洞**，例如XSS或SQLi。

-## Unicode规范化
+## Unicode Normalization

 Unicode规范化发生在**unicode字符被规范化为ascii字符**时。

-这种类型漏洞的一个常见场景发生在系统**在检查用户的输入后以某种方式修改**该输入。例如，在某些语言中，简单地调用将**输入转换为大写或小写**可能会规范化给定的输入，**unicode将被转换为ASCII**，生成新字符。\
+这种类型漏洞的一个常见场景是，当系统在**检查用户输入后**以某种方式**修改**用户的**输入**时。例如，在某些语言中，简单地调用将**输入转换为大写或小写**可能会规范化给定的输入，**unicode将被转换为ASCII**，生成新字符。\
 有关更多信息，请查看：

 {{#ref}}
 unicode-normalization.md
 {{#endref}}

-## `\u` 到 `%`
+## `\u` to `%`

-Unicode字符通常用**`\u`前缀**表示。例如字符`㱋`是`\u3c4b`（[在这里查看](https://unicode-explorer.com/c/3c4B)）。如果后端**将**前缀**`\u`转换为`%`，则结果字符串将是`%3c4b`，URL解码后为：**`<4b`**。正如你所看到的，**`<`字符被注入**。\
+Unicode字符通常用**`\u`前缀**表示。例如字符`㱋`是`\u3c4b`（[在这里查看](https://unicode-explorer.com/c/3c4B)）。如果后端**将**前缀**`\u`转换为`%`，则结果字符串将是`%3c4b`，URL解码后为：**`<4b`**。如你所见，**`<`字符被注入**。\
 如果后端存在漏洞，你可以使用此技术**注入任何类型的字符**。\
-查看[https://unicode-explorer.com/](https://unicode-explorer.com/)以找到你需要的字符。
+查看[https://unicode-explorer.com/](https://unicode-explorer.com/)以找到所需的字符。

-这个漏洞实际上来自于一位研究人员发现的漏洞，想要更深入的解释请查看[https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg)
+这个漏洞实际上源于一位研究人员发现的漏洞，想要更深入的解释请查看[https://www.youtube.com/watch?v=aUsAHb0E7Cg](https://www.youtube.com/watch?v=aUsAHb0E7Cg)

-## Emoji注入
+## Emoji Injection

-后端在**接收表情符号**时表现得有些奇怪。这就是在[**这篇文章**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209)中发生的情况，研究人员成功地通过一个有效载荷实现了XSS，例如：`💋img src=x onerror=alert(document.domain)//💛`
+后端在**接收表情符号**时表现得有些奇怪。这就是在[**这篇文章**](https://medium.com/@fpatrik/how-i-found-an-xss-vulnerability-via-using-emojis-7ad72de49209)中发生的情况，研究人员成功利用一个有效载荷实现了XSS，例如：`💋img src=x onerror=alert(document.domain)//💛`

 在这种情况下，错误在于服务器在删除恶意字符后**将UTF-8字符串从Windows-1252转换为UTF-8**（基本上输入编码和转换编码不匹配）。然后这并没有给出一个正确的<，而是一个奇怪的unicode字符：`‹`\
 ``所以他们将这个输出**再次从UTF-8转换为ASCII**。这**规范化**了`‹`为`<`，这就是该系统上漏洞能够工作的方式。\
-发生的事情是：
+这就是发生的事情：
 ```php
 <?php

@ -47,4 +47,18 @@ Emoji 列表：
 - [https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv](https://github.com/iorch/jakaton_feminicidios/blob/master/data/emojis.csv)
 - [https://unicode.org/emoji/charts-14.0/full-emoji-list.html](https://unicode.org/emoji/charts-14.0/full-emoji-list.html)

+## Windows 最佳适配/最差适配
+
+正如**[这篇精彩的文章](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)**中所解释的，Windows 有一个叫做 **最佳适配** 的功能，它会 **用一个相似的字符替换** 在 ASCII 模式下无法显示的 unicode 字符。这可能导致 **意外行为**，当后端 **期望一个特定字符** 但接收到一个不同的字符时。
+
+可以在 **[https://worst.fit/mapping/](https://worst.fit/mapping/)** 找到最佳适配字符。
+
+由于 Windows 通常会在执行的最后阶段将 unicode 字符串转换为 ascii 字符串（通常是从带有 "W" 后缀的 API 转换为带有 "A" 后缀的 API，如 `GetEnvironmentVariableA` 和 `GetEnvironmentVariableW`），这将允许攻击者通过发送 unicode 字符来绕过保护，这些字符最后会被转换为执行意外操作的 ASCII 字符。
+
+在博客文章中提出了绕过使用 **字符黑名单** 修复的漏洞的方法，利用 **路径遍历** 使用 [映射到 “/“ (0x2F) 的字符](https://worst.fit/mapping/#to%3A0x2f) 和 [映射到 “\“ (0x5C) 的字符](https://worst.fit/mapping/#to%3A0x5c)，甚至绕过像 PHP 的 `escapeshellarg` 或 Python 的 `subprocess.run` 的 shell 转义保护，使用一个列表，例如使用 **全宽双引号 (U+FF02)** 代替双引号，这样最终看起来像一个参数的内容被转化为两个参数。
+
+**请注意，应用程序要脆弱，需要使用 "W" Windows API，但最终调用 "A" Windows API，因此会创建 unicode 字符串的 "最佳适配"。**
+
+**发现的多个漏洞将不会被修复，因为人们对谁应该修复这个问题没有达成一致。**
+
 {{#include ../../banners/hacktricks-training.md}}