Merge branch 'master' of github.com:HackTricks-wiki/hacktricks

src/generic-methodologies-and-resources/external-recon-methodology/github-leaked-secrets.md

@@ -3,17 +3,13 @@
 {{#include ../../banners/hacktricks-training.md}}
 
 
-
-Now that we have built the list of assets of our scope it's time to search for some OSINT low-hanging fruits.
-
-### Platforms that already searched for leaks
-
-- [https://trufflesecurity.com/blog/introducing-forager/](https://trufflesecurity.com/blog/introducing-forager/)
-
-### Api keys leaks in github
+### Tools to find secrets in git repos and file system
 
 - [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)

src/pentesting-web/oauth-to-account-takeover.md

@@ -80,9 +80,9 @@ https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</scrip
 
 ### CSRF - Improper handling of state parameter <a href="#bda5" id="bda5"></a>
 
-In OAuth implementations, the misuse or omission of the **`state` parameter** can significantly increase the risk of **Cross-Site Request Forgery (CSRF)** attacks. This vulnerability arises when the `state` parameter is either **not used, used as a static value, or not properly validated**, allowing attackers to bypass CSRF protections.
+In OAuth implementations, the misuse or omission of the **`state` parameter** can significantly increase the risk of **Cross-Site Request Forgery (CSRF)** attacks. This vulnerability arises when the `state` parameter is either **not used, used as a static value, or not properly validated or associated with the users session** while logging in, allowing attackers to bypass CSRF protections.
 
-Attackers can exploit this by intercepting the authorization process to link their account with a victim's account, leading to potential **account takeovers**. This is especially critical in applications where OAuth is used for **authentication purposes**.
+Attackers can exploit this by intercepting the authorization process to link their account with a victim's account, leading to potential **account takeovers** by making a user login with an almost finalizehd oauth flow belonging to the attacker. This is especially critical in applications where OAuth is used for **authentication purposes**.
 
 Real-world examples of this vulnerability have been documented in various **CTF challenges** and **hacking platforms**, highlighting its practical implications. The issue also extends to integrations with third-party services like **Slack**, **Stripe**, and **PayPal**, where attackers can redirect notifications or payments to their accounts.
 
@@ -227,9 +227,33 @@ Dynamic Client Registration in OAuth serves as a less obvious but critical vecto
 
 If the platform you are testing is an OAuth provider [**read this to test for possible Race Conditions**](race-condition.md).
 
+## Mutable Claims Attack
+
+In OAuth, the sub field uniquely identifies a user, but its format varies by Authorization Server. To standardize user identification, some clients use emails or user handles. However, this is risky because:
+
+- Some Authorization Servers do not ensure that these properties (like email) remain immutable.
+- In certain implementations—such as **"Login with Microsoft"**—the client relies on the email field, which is **user-controlled by the user in Entra ID** and not verified.
+- An attacker can exploit this by creating their own Azure AD organization (e.g., doyensectestorg) and using it to perform a Microsoft login.
+- Even though the Object ID (stored in sub) is immutable and secure, the reliance on a mutable email field can enable an account takeover (for example, hijacking an account like victim@gmail.com).
+
+## Client Confusion Attack
+
+In a **Client Confusion Attack**, an application using the OAuth Implicit Flow fails to verify that the final access token is specifically generated for its own Client ID. An attacker sets up a public website that uses Google’s OAuth Implicit Flow, tricking thousands of users into logging in and thereby harvesting access tokens intended for the attacker’s site. If these users also have accounts on another vulnerable website that does not validate the token's Client ID, the attacker can reuse the harvested tokens to impersonate the victims and take over their accounts.
+
+## Scope Upgrade Attack
+
+The **Authorization Code Grant** type involves secure server-to-server communication for transmitting user data. However, if the **Authorization Server** implicitly trusts a scope parameter in the Access Token Request (a parameter not defined in the RFC), a malicious application could upgrade the privileges of an authorization code by requesting a higher scope. After the **Access Token** is generated, the **Resource Server** must verify it: for JWT tokens, this involves checking the JWT signature and extracting data such as client_id and scope, while for random string tokens, the server must query the Authorization Server to retrieve the token’s details.
+
+## Redirect Scheme Hijacking
+
+In mobile OAuth implementations, apps use **custom URI schemes** to receive redirects with Authorization Codes. However, because multiple apps can register the same scheme on a device, the assumption that only the legitimate client controls the redirect URI is violated. On Android, for instance, an Intent URI like `com.example.app://` oauth is caught based on the scheme and optional filters defined in an app’s intent-filter. Since Android’s intent resolution can be broad—especially if only the scheme is specified—an attacker can register a malicious app with a carefully crafted intent filter to hijack the authorization code. This can **enable an account takeover** either through user interaction (when multiple apps are eligible to handle the intent) or via bypass techniques that exploit overly specific filters, as detailed by Ostorlab's assessment flowchart.
+
+
+
 ## References
 
 - [**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}}

src/pentesting-web/unicode-injection/README.md

@@ -49,6 +49,20 @@ Emoji lists:
 - [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 Best-Fit/Worst-fit
+
+As explained in **[this great post](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)**, Windows has a feature called **Best-Fit** which will **replace unicode characters** that cannot be displayed in ASCII mode with a similar one. This can lead to **unexpected behavior** when the backend is **expecting a specific character** but it receives a different one.
+
+It's possible to find best-fit characters in **[https://worst.fit/mapping/](https://worst.fit/mapping/)**.
+
+As Windows will usually convert unicode strings to ascii strings as one of the last parts of the execution (usually going from a "W" suffixed API to an "A" suffixed API like  `GetEnvironmentVariableA` and `GetEnvironmentVariableW`) this would allow atackers to bypass protections by sending unicode characters that will be converted lastly in ASCII characters that would perform nuexpected actions.
+
+In the blog post there are proposed methods to bypass vulnerabilities fixed using a **blacklist of chars**, exploit **path traversals** using [characters mapped to “/“ (0x2F)](https://worst.fit/mapping/#to%3A0x2f) and [characters mapped to “\“ (0x5C)](https://worst.fit/mapping/#to%3A0x5c) or even bypassing shell escape protections like PHP's `escapeshellarg` or Python's `subprocess.run` using a list, this was done for example using **fullwidth double quotes (U+FF02)** instead of double quotes so at the end what looked like 1 argument was transformed in 2 arguments.
+
+**Note that for an app to be vulnerable it needs to use "W" Windows APIs but end calling an "A" Windows api so the "Best-fit" of the unicode string is created.**
+
+**Several dicovered vulnerabilities won't be fixed as people don't agree who should be fixing this issue"**.
+
 {{#include ../../banners/hacktricks-training.md}}