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

2025-10-10 18:36:50 +00:00 · 2025-03-29 22:58:20 +00:00 · 2025-03-29 22:58:20 +00:00 · 45032b8a59
commit 45032b8a59
parent b723edaa31
3 changed files with 68 additions and 35 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}}

-Maintenant que nous avons construit la liste des actifs de notre périmètre, il est temps de rechercher des fruits à portée de main en OSINT.
-
-### Plates-formes qui ont déjà recherché des fuites
-
- [https://trufflesecurity.com/blog/introducing-forager/](https://trufflesecurity.com/blog/introducing-forager/)
-
-### Fuites de clés API sur github
+### Outils pour trouver des secrets dans les dépôts git et le système de fichiers

 - [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
@ -1,26 +1,26 @@
-# OAuth pour la prise de contrôle de compte
+# OAuth vers la prise de contrôle de compte

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

 ## Informations de base <a href="#d4a8" id="d4a8"></a>

-OAuth propose différentes versions, avec des informations fondamentales accessibles dans la [documentation OAuth 2.0](https://oauth.net/2/). Cette discussion se concentre principalement sur le [type de grant de code d'autorisation OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/), fournissant un **cadre d'autorisation qui permet à une application d'accéder ou d'effectuer des actions sur le compte d'un utilisateur dans une autre application** (le serveur d'autorisation).
+OAuth propose différentes versions, avec des informations fondamentales accessibles dans la [documentation OAuth 2.0](https://oauth.net/2/). Cette discussion se concentre principalement sur le [type de code d'autorisation OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/), fournissant un **cadre d'autorisation qui permet à une application d'accéder ou d'effectuer des actions sur le compte d'un utilisateur dans une autre application** (le serveur d'autorisation).

-Considérons un site web hypothétique _**https://example.com**_, conçu pour **afficher tous vos posts sur les réseaux sociaux**, y compris les privés. Pour ce faire, OAuth 2.0 est utilisé. _https://example.com_ demandera votre permission pour **accéder à vos posts sur les réseaux sociaux**. Par conséquent, un écran de consentement apparaîtra sur _https://socialmedia.com_, décrivant les **permissions demandées et le développeur faisant la demande**. Après votre autorisation, _https://example.com_ obtient la capacité d'**accéder à vos posts en votre nom**.
+Considérons un site web hypothétique _**https://example.com**_, conçu pour **présenter tous vos posts sur les réseaux sociaux**, y compris les privés. Pour ce faire, OAuth 2.0 est utilisé. _https://example.com_ demandera votre permission pour **accéder à vos posts sur les réseaux sociaux**. Par conséquent, un écran de consentement apparaîtra sur _https://socialmedia.com_, décrivant les **permissions demandées et le développeur faisant la demande**. Après votre autorisation, _https://example.com_ obtient la capacité d'**accéder à vos posts en votre nom**.

 Il est essentiel de comprendre les composants suivants dans le cadre OAuth 2.0 :

- **propriétaire de la ressource** : Vous, en tant que **utilisateur/entité**, autorisez l'accès à votre ressource, comme vos posts de compte de réseaux sociaux.
+- **propriétaire de la ressource** : Vous, en tant que **utilisateur/entité**, autorisez l'accès à votre ressource, comme vos posts de compte sur les réseaux sociaux.
 - **serveur de ressources** : Le **serveur gérant les demandes authentifiées** après que l'application a sécurisé un `access token` au nom du `propriétaire de la ressource`, par exemple, **https://socialmedia.com**.
- **application cliente** : L'**application cherchant l'autorisation** du `propriétaire de la ressource`, comme **https://example.com**.
- **serveur d'autorisation** : Le **serveur qui délivre des `access tokens`** à l'`application cliente` après l'authentification réussie du `propriétaire de la ressource` et la sécurisation de l'autorisation, par exemple, **https://socialmedia.com**.
+- **application cliente** : L'**application cherchant à obtenir l'autorisation** du `propriétaire de la ressource`, comme **https://example.com**.
+- **serveur d'autorisation** : Le **serveur qui délivre des `access tokens`** à l'`application cliente` après l'authentification réussie du `propriétaire de la ressource` et l'obtention de l'autorisation, par exemple, **https://socialmedia.com**.
 - **client_id** : Un identifiant public et unique pour l'application.
 - **client_secret** : Une clé confidentielle, connue uniquement de l'application et du serveur d'autorisation, utilisée pour générer des `access_tokens`.
 - **response_type** : Une valeur spécifiant **le type de token demandé**, comme `code`.
 - **scope** : Le **niveau d'accès** que l'`application cliente` demande au `propriétaire de la ressource`.
- **redirect_uri** : L'**URL vers laquelle l'utilisateur est redirigé après l'autorisation**. Cela doit généralement correspondre à l'URL de redirection pré-enregistrée.
+- **redirect_uri** : L'**URL vers laquelle l'utilisateur est redirigé après l'autorisation**. Cela doit généralement correspondre à l'URL de redirection préenregistrée.
 - **state** : Un paramètre pour **maintenir des données lors de la redirection de l'utilisateur vers et depuis le serveur d'autorisation**. Son unicité est cruciale pour servir de **mécanisme de protection CSRF**.
- **grant_type** : Un paramètre indiquant **le type de grant et le type de token à retourner**.
+- **grant_type** : Un paramètre indiquant **le type de subvention et le type de token à retourner**.
 - **code** : Le code d'autorisation du `serveur d'autorisation`, utilisé en tandem avec `client_id` et `client_secret` par l'application cliente pour acquérir un `access_token`.
 - **access_token** : Le **token que l'application cliente utilise pour les requêtes API** au nom du `propriétaire de la ressource`.
 - **refresh_token** : Permet à l'application de **obtenir un nouveau `access_token` sans redemander à l'utilisateur**.
@ -30,7 +30,7 @@ Il est essentiel de comprendre les composants suivants dans le cadre OAuth 2.0 :
 Le **flux OAuth réel** se déroule comme suit :

 1. Vous naviguez vers [https://example.com](https://example.com) et sélectionnez le bouton “Intégrer avec les réseaux sociaux”.
-2. Le site envoie ensuite une demande à [https://socialmedia.com](https://socialmedia.com) demandant votre autorisation pour permettre à l'application de https://example.com d'accéder à vos posts. La demande est structurée comme :
+2. Le site envoie ensuite une demande à [https://socialmedia.com](https://socialmedia.com) demandant votre autorisation pour permettre à l'application de https://example.com d'accéder à vos posts. La demande est structurée comme suit :
 ```
 https://socialmedia.com/auth
 ?response_type=code
@ -40,7 +40,7 @@ https://socialmedia.com/auth
 &state=randomString123
 ```
 3. Vous êtes ensuite présenté avec une page de consentement.  
-4. Suite à votre approbation, Social Media envoie une réponse à l'`redirect_uri` avec les paramètres `code` et `state` :
+4. Suite à votre approbation, le réseau social envoie une réponse à l'`redirect_uri` avec les paramètres `code` et `state` :
 ```
 https://example.com?code=uniqueCode123&state=randomString123
 ```
@ -58,7 +58,7 @@ Host: socialmedia.com

 Le `redirect_uri` est crucial pour la sécurité dans les implémentations OAuth et OpenID, car il dirige où les données sensibles, comme les codes d'autorisation, sont envoyées après l'autorisation. S'il est mal configuré, cela pourrait permettre aux attaquants de rediriger ces demandes vers des serveurs malveillants, permettant ainsi la prise de contrôle de compte.

-Les techniques d'exploitation varient en fonction de la logique de validation du serveur d'autorisation. Elles peuvent aller d'une correspondance stricte de chemin à l'acceptation de n'importe quelle URL dans le domaine ou le sous-répertoire spécifié. Les méthodes d'exploitation courantes incluent les redirections ouvertes, le chemin de traversée, l'exploitation de regex faibles et l'injection HTML pour le vol de jetons.
+Les techniques d'exploitation varient en fonction de la logique de validation du serveur d'autorisation. Elles peuvent aller d'une correspondance stricte des chemins à l'acceptation de n'importe quelle URL dans le domaine ou le sous-répertoire spécifié. Les méthodes d'exploitation courantes incluent les redirections ouvertes, le parcours de chemin, l'exploitation de regex faibles et l'injection HTML pour le vol de jetons.

 En plus de `redirect_uri`, d'autres paramètres OAuth et OpenID comme `client_uri`, `policy_uri`, `tos_uri` et `initiate_login_uri` sont également susceptibles aux attaques de redirection. Ces paramètres sont optionnels et leur support varie selon les serveurs.

@ -72,17 +72,17 @@ https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</scrip
 ```
 ### CSRF - Mauvaise gestion du paramètre d'état <a href="#bda5" id="bda5"></a>

-Dans les implémentations OAuth, l'utilisation incorrecte ou l'omission du **`state` parameter** peut considérablement augmenter le risque d'attaques de **Cross-Site Request Forgery (CSRF)**. Cette vulnérabilité survient lorsque le paramètre `state` est soit **non utilisé, utilisé comme une valeur statique, ou mal validé**, permettant aux attaquants de contourner les protections CSRF.
+Dans les implémentations OAuth, l'utilisation incorrecte ou l'omission du **`state` parameter** peut considérablement augmenter le risque d'attaques de **Cross-Site Request Forgery (CSRF)**. Cette vulnérabilité survient lorsque le paramètre `state` est soit **non utilisé, utilisé comme une valeur statique, ou pas correctement validé ou associé à la session de l'utilisateur** lors de la connexion, permettant aux attaquants de contourner les protections CSRF.

-Les attaquants peuvent exploiter cela en interceptant le processus d'autorisation pour lier leur compte à celui d'une victime, ce qui peut entraîner des **prises de contrôle de compte** potentielles. Cela est particulièrement critique dans les applications où OAuth est utilisé à des fins **d'authentification**.
+Les attaquants peuvent exploiter cela en interceptant le processus d'autorisation pour lier leur compte à celui d'une victime, conduisant à de potentielles **prises de contrôle de compte** en faisant en sorte qu'un utilisateur se connecte avec un flux oauth presque finalisé appartenant à l'attaquant. Cela est particulièrement critique dans les applications où OAuth est utilisé à des fins **d'authentification**.

-Des exemples concrets de cette vulnérabilité ont été documentés dans divers **CTF challenges** et **plateformes de hacking**, soulignant ses implications pratiques. Le problème s'étend également aux intégrations avec des services tiers comme **Slack**, **Stripe**, et **PayPal**, où les attaquants peuvent rediriger des notifications ou des paiements vers leurs comptes.
+Des exemples concrets de cette vulnérabilité ont été documentés dans divers **défis CTF** et **plateformes de hacking**, soulignant ses implications pratiques. Le problème s'étend également aux intégrations avec des services tiers comme **Slack**, **Stripe**, et **PayPal**, où les attaquants peuvent rediriger des notifications ou des paiements vers leurs comptes.

 Une gestion et une validation appropriées du **`state` parameter** sont cruciales pour se protéger contre le CSRF et sécuriser le flux OAuth.

 ### Pré Prise de Contrôle de Compte <a href="#ebe4" id="ebe4"></a>

-1. **Sans Vérification d'Email lors de la Création de Compte** : Les attaquants peuvent créer préventivement un compte en utilisant l'email de la victime. Si la victime utilise plus tard un service tiers pour se connecter, l'application pourrait involontairement lier ce compte tiers au compte pré-créé de l'attaquant, entraînant un accès non autorisé.
+1. **Sans Vérification d'Email lors de la Création de Compte** : Les attaquants peuvent créer préventivement un compte en utilisant l'email de la victime. Si la victime utilise plus tard un service tiers pour se connecter, l'application pourrait involontairement lier ce compte tiers au compte pré-créé de l'attaquant, conduisant à un accès non autorisé.
 2. **Exploitation d'une Vérification d'Email OAuth Laxiste** : Les attaquants peuvent exploiter des services OAuth qui ne vérifient pas les emails en s'inscrivant avec leur service puis en changeant l'email du compte pour celui de la victime. Cette méthode présente également un risque d'accès non autorisé au compte, semblable au premier scénario mais par un vecteur d'attaque différent.

 ### Divulgation de Secrets <a href="#e177" id="e177"></a>
@ -104,7 +104,7 @@ Connection: close

 code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]
 ```
-### Référent Header fuyant Code + État
+### Fuite du code + état dans l'en-tête Referer

 Une fois que le client a le **code et l'état**, s'ils sont **réfléchis dans l'en-tête Referer** lorsqu'il navigue vers une autre page, alors il est vulnérable.

@ -114,13 +114,13 @@ Allez dans **l'historique du navigateur et vérifiez si le jeton d'accès y est

 ### Code d'autorisation éternel

-Le **code d'autorisation ne devrait vivre que pendant un certain temps pour limiter la fenêtre de temps où un attaquant peut le voler et l'utiliser**.
+Le **code d'autorisation ne devrait vivre que pendant un certain temps pour limiter la fenêtre temporelle où un attaquant peut le voler et l'utiliser**.

 ### Jeton d'autorisation/rafraîchissement non lié au client

 Si vous pouvez obtenir le **code d'autorisation et l'utiliser avec un client différent, alors vous pouvez prendre le contrôle d'autres comptes**.

-### Chemins heureux, XSS, Iframes & Messages Post pour fuir les valeurs de code & d'état
+### Chemins heureux, XSS, Iframes et messages post pour fuir les valeurs de code et d'état

 [**Vérifiez ce post**](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)

@ -143,7 +143,7 @@ aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ
 ]
 }
 ```
-Pour plus d'informations détaillées sur la façon d'abuser d'AWS Cognito, consultez :
+Pour plus d'informations détaillées sur la façon d'abuser d'AWS cognito, consultez :

 {{#ref}}
 https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum.html
@ -153,7 +153,7 @@ https://cloud.hacktricks.wiki/en/pentesting-cloud/aws-security/aws-unauthenticat

 Comme [**mentionné dans cet article**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), les flux OAuth qui s'attendent à recevoir le **token** (et non un code) pourraient être vulnérables s'ils ne vérifient pas que le token appartient à l'application.

-Ceci est dû au fait qu'un **attaquant** pourrait créer une **application supportant OAuth et se connecter avec Facebook** (par exemple) dans sa propre application. Ensuite, une fois qu'une victime se connecte avec Facebook dans l'**application de l'attaquant**, l'attaquant pourrait obtenir le **token OAuth de l'utilisateur donné à son application, et l'utiliser pour se connecter dans l'application OAuth de la victime en utilisant le token utilisateur de la victime**.
+C'est parce qu'un **attaquant** pourrait créer une **application supportant OAuth et se connecter avec Facebook** (par exemple) dans sa propre application. Ensuite, une fois qu'une victime se connecte avec Facebook dans l'**application de l'attaquant**, l'attaquant pourrait obtenir le **token OAuth de l'utilisateur donné à son application, et l'utiliser pour se connecter dans l'application OAuth de la victime en utilisant le token utilisateur de la victime**.

 > [!CAUTION]
 > Par conséquent, si l'attaquant parvient à faire accéder l'utilisateur à sa propre application OAuth, il pourra prendre le contrôle du compte de la victime dans les applications qui s'attendent à un token et ne vérifient pas si le token a été accordé à leur ID d'application.
@ -173,7 +173,7 @@ Comme expliqué dans [**cette vidéo**](https://www.youtube.com/watch?v=n9x7_J_a
 Comme [**expliqué dans cette vidéo**](https://www.youtube.com/watch?v=n9x7_J_a_7Q), il pourrait être possible d'indiquer le paramètre **`response_mode`** pour indiquer où vous souhaitez que le code soit fourni dans l'URL finale :

 - `response_mode=query` -> Le code est fourni à l'intérieur d'un paramètre GET : `?code=2397rf3gu93f`
- `response_mode=fragment` -> Le code est fourni à l'intérieur du paramètre fragment de l'URL `#code=2397rf3gu93f`
+- `response_mode=fragment` -> Le code est fourni à l'intérieur du paramètre de fragment d'URL `#code=2397rf3gu93f`
 - `response_mode=form_post` -> Le code est fourni à l'intérieur d'un formulaire POST avec un input appelé `code` et la valeur
 - `response_mode=web_message` -> Le code est envoyé dans un message post : `window.opener.postMessage({"code": "asdasdasd...`

@ -186,7 +186,7 @@ Selon [**cet article de blog**](https://cybxis.medium.com/a-bypass-on-gitlabs-lo
 Ce [**blogpost**](https://blog.voorivex.team/oauth-non-happy-path-to-ato) commente comment il était possible d'abuser d'une **redirection ouverte** vers la valeur du **référent** pour abuser d'OAuth pour ATO. L'attaque était :

 1. La victime accède à la page web de l'attaquant
-2. La victime ouvre le lien malveillant et un opener commence le flux OAuth de Google avec `response_type=id_token,code&prompt=none` comme paramètres supplémentaires en utilisant comme **référent le site web de l'attaquant**.
+2. La victime ouvre le lien malveillant et un opener démarre le flux OAuth de Google avec `response_type=id_token,code&prompt=none` comme paramètres supplémentaires en utilisant comme **référent le site web de l'attaquant**.
 3. Dans l'opener, après que le fournisseur autorise la victime, il les renvoie à la valeur du paramètre `redirect_uri` (site web de la victime) avec un code 30X qui garde toujours le site web de l'attaquant dans le référent.
 4. Le **site web de la victime déclenche la redirection ouverte basée sur le référent**, redirigeant l'utilisateur victime vers le site web de l'attaquant, comme le **`respose_type`** était **`id_token,code`**, le code sera renvoyé à l'attaquant dans le **fragment** de l'URL lui permettant de prendre le contrôle du compte de l'utilisateur via Google sur le site de la victime.

@ -198,26 +198,48 @@ L'enregistrement dynamique de clients dans OAuth sert de vecteur moins évident

 **Points clés :**

- **L'enregistrement dynamique de clients** est souvent mappé à `/register` et accepte des détails comme `client_name`, `client_secret`, `redirect_uris`, et des URL pour des logos ou des ensembles de clés JSON Web (JWKs) via des requêtes POST.
+- L'**enregistrement dynamique de clients** est souvent mappé à `/register` et accepte des détails comme `client_name`, `client_secret`, `redirect_uris`, et des URL pour des logos ou des ensembles de clés JSON Web (JWKs) via des requêtes POST.
 - Cette fonctionnalité adhère aux spécifications énoncées dans **RFC7591** et **OpenID Connect Registration 1.0**, qui incluent des paramètres potentiellement vulnérables aux SSRF.
 - Le processus d'enregistrement peut involontairement exposer les serveurs aux SSRF de plusieurs manières :
 - **`logo_uri`** : Une URL pour le logo de l'application cliente qui pourrait être récupérée par le serveur, déclenchant un SSRF ou menant à un XSS si l'URL est mal gérée.
- **`jwks_uri`** : Une URL vers le document JWK du client, qui si elle est malicieusement conçue, peut amener le serveur à effectuer des requêtes sortantes vers un serveur contrôlé par un attaquant.
+- **`jwks_uri`** : Une URL vers le document JWK du client, qui, si elle est malicieusement conçue, peut amener le serveur à effectuer des requêtes sortantes vers un serveur contrôlé par un attaquant.
 - **`sector_identifier_uri`** : Fait référence à un tableau JSON de `redirect_uris`, que le serveur pourrait récupérer, créant une opportunité de SSRF.
 - **`request_uris`** : Liste les URI de requête autorisées pour le client, qui peuvent être exploitées si le serveur récupère ces URI au début du processus d'autorisation.

 **Stratégie d'exploitation :**

- Le SSRF peut être déclenché en enregistrant un nouveau client avec des URL malveillantes dans des paramètres comme `logo_uri`, `jwks_uri`, ou `sector_identifier_uri`.
+- Le SSRF peut être déclenché en enregistrant un nouveau client avec des URL malicieuses dans des paramètres comme `logo_uri`, `jwks_uri`, ou `sector_identifier_uri`.
 - Bien que l'exploitation directe via `request_uris` puisse être atténuée par des contrôles de liste blanche, fournir un `request_uri` préenregistré, contrôlé par un attaquant, peut faciliter le SSRF pendant la phase d'autorisation.

 ## Conditions de course des fournisseurs OAuth

 Si la plateforme que vous testez est un fournisseur OAuth [**lisez ceci pour tester les éventuelles conditions de course**](race-condition.md).

+## Attaque sur les revendications mutables
+
+Dans OAuth, le champ sub identifie de manière unique un utilisateur, mais son format varie selon le serveur d'autorisation. Pour standardiser l'identification des utilisateurs, certains clients utilisent des e-mails ou des identifiants d'utilisateur. Cependant, cela est risqué car :
+
+- Certains serveurs d'autorisation ne garantissent pas que ces propriétés (comme l'e-mail) restent immuables.
+- Dans certaines implémentations—comme **"Se connecter avec Microsoft"**—le client s'appuie sur le champ e-mail, qui est **contrôlé par l'utilisateur dans Entra ID** et non vérifié.
+- Un attaquant peut exploiter cela en créant sa propre organisation Azure AD (par exemple, doyensectestorg) et en l'utilisant pour effectuer une connexion Microsoft.
+- Même si l'ID d'objet (stocké dans sub) est immuable et sécurisé, la dépendance à un champ e-mail mutable peut permettre une prise de contrôle de compte (par exemple, le détournement d'un compte comme victim@gmail.com).
+
+## Attaque de confusion de client
+
+Dans une **attaque de confusion de client**, une application utilisant le flux implicite OAuth ne parvient pas à vérifier que le token d'accès final est spécifiquement généré pour son propre ID de client. Un attaquant met en place un site web public qui utilise le flux implicite OAuth de Google, trompant des milliers d'utilisateurs pour se connecter et récoltant ainsi des tokens d'accès destinés au site de l'attaquant. Si ces utilisateurs ont également des comptes sur un autre site vulnérable qui ne valide pas l'ID de client du token, l'attaquant peut réutiliser les tokens récoltés pour usurper l'identité des victimes et prendre le contrôle de leurs comptes.
+
+## Attaque de mise à niveau de portée
+
+Le type **Authorization Code Grant** implique une communication sécurisée entre serveurs pour transmettre des données utilisateur. Cependant, si le **serveur d'autorisation** fait implicitement confiance à un paramètre de portée dans la demande de token d'accès (un paramètre non défini dans le RFC), une application malveillante pourrait augmenter les privilèges d'un code d'autorisation en demandant une portée plus élevée. Après que le **token d'accès** soit généré, le **serveur de ressources** doit le vérifier : pour les tokens JWT, cela implique de vérifier la signature JWT et d'extraire des données telles que client_id et scope, tandis que pour les tokens de chaîne aléatoire, le serveur doit interroger le serveur d'autorisation pour récupérer les détails du token.
+
+## Détournement de schéma de redirection
+
+Dans les implémentations mobiles OAuth, les applications utilisent des **schémas URI personnalisés** pour recevoir des redirections avec des codes d'autorisation. Cependant, parce que plusieurs applications peuvent enregistrer le même schéma sur un appareil, l'hypothèse selon laquelle seul le client légitime contrôle l'URI de redirection est violée. Sur Android, par exemple, un URI d'intention comme `com.example.app://` oauth est capturé en fonction du schéma et des filtres optionnels définis dans le filtre d'intention d'une application. Étant donné que la résolution d'intention d'Android peut être large—surtout si seul le schéma est spécifié—un attaquant peut enregistrer une application malveillante avec un filtre d'intention soigneusement conçu pour détourner le code d'autorisation. Cela peut **permettre une prise de contrôle de compte** soit par interaction utilisateur (lorsque plusieurs applications sont éligibles pour gérer l'intention) ou via des techniques de contournement qui exploitent des filtres trop spécifiques, comme détaillé par le diagramme de flux d'évaluation d'Ostorlab.
+
 ## Références

 - [**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
@ -10,7 +10,7 @@ Selon le comportement du back-end/front-end lorsqu'il **reçoit des caractères

 La normalisation Unicode se produit lorsque **les caractères unicode sont normalisés en caractères ascii**.

-Un scénario courant de ce type de vulnérabilité se produit lorsque le système **modifie** d'une manière ou d'une autre l'**entrée** de l'utilisateur **après l'avoir vérifiée**. Par exemple, dans certaines langues, un simple appel pour rendre l'**entrée en majuscules ou en minuscules** pourrait normaliser l'entrée donnée et le **unicode sera transformé en ASCII**, générant de nouveaux caractères.\
+Un scénario courant de ce type de vulnérabilité se produit lorsque le système **modifie** d'une manière ou d'une autre l'**entrée** de l'utilisateur **après l'avoir vérifiée**. Par exemple, dans certaines langues, un simple appel pour mettre l'**entrée en majuscules ou en minuscules** pourrait normaliser l'entrée donnée et le **unicode sera transformé en ASCII**, générant de nouveaux caractères.\
 Pour plus d'infos, consultez :

 {{#ref}}
@ -19,7 +19,7 @@ unicode-normalization.md

 ## `\u` à `%`

-Les caractères unicode sont généralement représentés avec le **préfixe `\u`**. Par exemple, le caractère `㱋` est `\u3c4b`([vérifiez-le ici](https://unicode-explorer.com/c/3c4B)). Si un backend **transforme** le préfixe **`\u` en `%`**, la chaîne résultante sera `%3c4b`, qui décodée URL est : **`<4b`**. Et, comme vous pouvez le voir, un **caractère `<` est injecté**.\
+Les caractères Unicode sont généralement représentés avec le **préfixe `\u`**. Par exemple, le caractère `㱋` est `\u3c4b`([vérifiez-le ici](https://unicode-explorer.com/c/3c4B)). Si un backend **transforme** le préfixe **`\u` en `%`**, la chaîne résultante sera `%3c4b`, qui décodée URL est : **`<4b`**. Et, comme vous pouvez le voir, un **caractère `<` est injecté**.\
 Vous pourriez utiliser cette technique pour **injecter n'importe quel type de caractère** si le backend est vulnérable.\
 Consultez [https://unicode-explorer.com/](https://unicode-explorer.com/) pour trouver les caractères dont vous avez besoin.

@ -42,9 +42,23 @@ $str = iconv("UTF-8", "ASCII//TRANSLIT", $str);

 echo "String: " . $str;
 ```
-Listes d'emoji :
+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
+
+Comme expliqué dans **[ce super article](https://blog.orange.tw/posts/2025-01-worstfit-unveiling-hidden-transformers-in-windows-ansi/)**, Windows a une fonctionnalité appelée **Best-Fit** qui va **remplacer les caractères unicode** qui ne peuvent pas être affichés en mode ASCII par un caractère similaire. Cela peut entraîner un **comportement inattendu** lorsque le backend **s'attend à un caractère spécifique** mais reçoit un caractère différent.
+
+Il est possible de trouver des caractères best-fit dans **[https://worst.fit/mapping/](https://worst.fit/mapping/)**.
+
+Comme Windows convertit généralement les chaînes unicode en chaînes ascii comme l'une des dernières parties de l'exécution (passant généralement d'une API suffixée par "W" à une API suffixée par "A" comme `GetEnvironmentVariableA` et `GetEnvironmentVariableW`), cela permettrait aux attaquants de contourner les protections en envoyant des caractères unicode qui seront finalement convertis en caractères ASCII qui effectueraient des actions inattendues.
+
+Dans l'article de blog, des méthodes sont proposées pour contourner les vulnérabilités corrigées en utilisant une **liste noire de caractères**, exploiter des **traversées de chemin** en utilisant [des caractères mappés à “/“ (0x2F)](https://worst.fit/mapping/#to%3A0x2f) et [des caractères mappés à “\“ (0x5C)](https://worst.fit/mapping/#to%3A0x5c) ou même contourner les protections d'échappement de shell comme `escapeshellarg` de PHP ou `subprocess.run` de Python en utilisant une liste, cela a été fait par exemple en utilisant **des guillemets doubles en pleine largeur (U+FF02)** au lieu de guillemets doubles, de sorte qu'à la fin ce qui semblait être 1 argument était transformé en 2 arguments.
+
+**Notez que pour qu'une application soit vulnérable, elle doit utiliser des API Windows "W" mais finir par appeler une API Windows "A" afin que le "Best-fit" de la chaîne unicode soit créé.**
+
+**Plusieurs vulnérabilités découvertes ne seront pas corrigées car les gens ne s'accordent pas sur qui devrait résoudre ce problème.**
+
 {{#include ../../banners/hacktricks-training.md}}