**Conseil pour les primes de bugs** : **inscrivez-vous** sur **Intigriti**, une plateforme de primes de bugs premium créée par des hackers, pour des hackers ! Rejoignez-nous sur [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) dès aujourd'hui et commencez à gagner des primes allant jusqu'à **100 000 $** !
1. Vérifiez si **une valeur que vous contrôlez** (_paramètres_, _chemin_, _en-têtes_?, _cookies_?) est **reflétée** dans le HTML ou **utilisée** par le code **JS**.
2.**Trouvez le contexte** où elle est reflétée/utilisée.
3. Si **reflétée** :
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 ?
2. Pouvez-vous utiliser des événements ou des attributs prenant en charge le protocole `javascript:` ?
3. Pouvez-vous contourner les protections ?
4. Le contenu HTML est-il interprété par un moteur JS côté client (_AngularJS_, _VueJS_, _Mavo_...) que vous pourriez exploiter via une [**Injection de Template Côté Client**](../client-side-template-injection-csti.md).
5. Si vous ne pouvez pas créer de balises HTML exécutant du code JS, pourriez-vous exploiter une [**Injection sans script - Injection HTML de balisage suspendu**](../dangling-markup-html-scriptless-injection/) ?
2. À l'intérieur d'une **balise HTML** :
1. Pouvez-vous sortir du contexte HTML brut ?
2. Pouvez-vous créer de nouveaux événements/attributs pour exécuter du code JS ?
3. L'attribut dans lequel vous êtes piégé prend-il en charge l'exécution de JS ?
4. Pouvez-vous contourner les protections ?
3. À l'intérieur du code **JavaScript** :
1. Pouvez-vous vous échapper de la balise `<script>` ?
2. Pouvez-vous sortir de la chaîne et exécuter un code JS différent ?
3. Votre entrée est-elle dans des littéraux de gabarit \`\` ?
4. Pouvez-vous contourner les protections ?
4.**Fonction JavaScript** étant **exécutée**
1. Vous pouvez indiquer le nom de la fonction à exécuter. Ex. : `?callback=alert(1)`
4. Si **utilisée** :
1. Vous pourriez exploiter un **DOM XSS**, faites attention à la manière dont votre entrée est contrôlée et si votre **entrée contrôlée est utilisée par un point d'injection**.
Lorsque vous travaillez sur un XSS complexe, il pourrait être intéressant de connaître :
* **Reflet intermédiaire** : Si vous trouvez que la valeur d'un paramètre ou même du chemin est reflétée sur la page web, vous pourriez exploiter un **XSS Reflété**.
* **Enregistré et reflété** : Si vous trouvez qu'une valeur contrôlée par vous est enregistrée sur le serveur et est reflétée à chaque fois que vous accédez à une page, vous pourriez exploiter un **XSS Stocké**.
* **Accédé via JS** : Si vous trouvez qu'une valeur contrôlée par vous est accédée en utilisant JS, vous pourriez exploiter un **DOM XSS**.
Lorsque vous essayez d'exploiter un XSS, la première chose à savoir est **où votre entrée est reflétée**. Selon le contexte, vous pourrez exécuter du code JS arbitraire de différentes manières.
Si votre entrée est **reflétée 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.\
Gardez également à l'esprit [l'Injection de Template Côté Client](../client-side-template-injection-csti.md).
1. De **vous échapper de l'attribut et de la balise** (vous serez alors dans le HTML brut) et créer une nouvelle balise HTML à abuser : `"><img [...]`
2. Si vous **pouvez vous é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 vous échapper de l'attribut** (`"` est encodé ou supprimé), alors selon **quel attribut** votre valeur est reflétée et **si vous contrôlez toute la valeur ou juste une partie**, vous pourrez l'abuser. Par **exemple**, si vous contrôlez un événement comme `onclick=`, vous pourrez le faire exécuter un 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 un code arbitraire : **`href="javascript:alert(1)"`**
4. Si votre entrée est reflétée à l'intérieur de **balises inexploitables**, vous pourriez essayer l'astuce **`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="`**
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 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, par conséquent, il ne remarquera pas que votre balise `</script>` injectée est à l'intérieur du code HTML.
* Si reflétée **à l'intérieur d'une chaîne JS** et que la dernière astuce ne fonctionne pas, vous devrez **sortir** de la chaîne, **exécuter** votre code et **reconstruire** le code JS (si une erreur se produit, il ne sera pas exécuté) :
* Si reflétée à l'intérieur de littéraux de gabarit, vous pouvez **intégrer des expressions JS** en utilisant la syntaxe `${ ... }` : `` var greetings = `Hello, ${alert(1)}` ``
* **Encoder en Unicode** fonctionne pour écrire un **code javascript valide** :
Le Javascript Hoisting fait référence à la possibilité de **déclarer des fonctions, des variables ou des classes après leur utilisation, ce qui permet d'exploiter des scénarios où un XSS utilise des variables ou des fonctions non déclarées.**\
**Consultez la page suivante pour plus d'informations :**
Plusieurs pages web ont des points de terminaison qui **acceptent en paramètre le nom de la fonction à exécuter**. Un exemple courant que l'on peut voir est quelque chose comme : `?callback=callbackFunc`.
Un bon moyen de savoir si quelque chose donné directement par l'utilisateur essaie d'être exécuté est de **modifier la valeur du paramètre** (par exemple en 'Vulnerable') et de chercher dans la console des erreurs comme :
Dans le cas où c'est vulnérable, vous pourriez être capable de **déclencher une alerte** juste en envoyant la valeur : **`?callback=alert(1)`**. Cependant, il est très courant que ces points de terminaison **valident le contenu** pour n'autoriser que les lettres, les chiffres, les points et les tirets bas (**`[\w\._]`**).
Cependant, même avec cette limitation, il est encore possible de réaliser certaines actions. Cela est dû au fait que vous pouvez utiliser ces caractères valides pour **accéder à n'importe quel élément dans le DOM** :
Cependant, habituellement, les points de terminaison exécutant la fonction indiquée sont des points de terminaison sans DOM intéressant, **d'autres pages de la même origine** auront un **DOM plus intéressant** pour effectuer plus d'actions.
Par conséquent, afin de **abuser de cette vulnérabilité dans un DOM différent**, l'exploitation **Same Origin Method Execution (SOME)** a été développée :
Il y a du **code JS** qui utilise **de manière non sécurisée** certaines **données contrôlées par un attaquant** comme `location.href`. Un attaquant pourrait abuser de cela pour exécuter du code JS arbitraire.
Ce type de XSS peut être trouvé **partout**. Ils ne dépendent pas seulement de l'exploitation client d'une application web mais de **tout****contexte**. Ce type d'**exécution arbitraire de JavaScript** peut même être abusé pour obtenir un **RCE**, **lire****des fichiers arbitraires** sur les clients et les serveurs, et plus encore.\
Lorsque votre entrée est reflétée **à l'intérieur de la page HTML** ou que vous pouvez vous échapper et injecter du code HTML dans ce contexte, la **première** chose à faire est de vérifier si vous pouvez abuser de `<` pour créer de nouvelles balises : Essayez simplement de **refléter** ce **caractère** et vérifiez s'il est **encodé en HTML** ou **supprimé** ou s'il est **reflété sans changements**. **Seulement dans le dernier cas, vous pourrez exploiter ce cas**.\
Pour ces cas, **gardez également à l'esprit** [**Client Side Template Injection**](../client-side-template-injection-csti.md)**.**\
_**Note : Un commentaire HTML peut être fermé en utilisant**** ****`-->`**** ****ou**** ****`--!>`**_
Mais, si un système de liste noire/blanche de balises/attributs est utilisé, vous devrez **forcer la découverte des balises** que vous pouvez créer.\
Une fois que vous avez **identifié les balises autorisées**, vous devrez **forcer la découverte des attributs/événements** à l'intérieur des balises valides trouvées pour voir comment vous pouvez attaquer le contexte.
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 balises dans le presse-papier**_. Ensuite, envoyez-les toutes en utilisant l'intrus de Burp et vérifiez si des balises n'ont pas été détectées comme malveillantes par le WAF. Une fois que vous avez découvert quelles balises vous pouvez utiliser, vous pouvez **forcer la découverte de tous les événements** en utilisant les balises valides (sur la même page web, cliquez sur _**Copier les événements dans le presse-papier**_ et suivez la même procédure que précédemment).
Si vous n'avez trouvé aucune balise HTML valide, vous pourriez essayer de **créer une balise personnalisée** et exécuter du code JS avec l'attribut `onfocus`. Dans la requête XSS, vous devez terminer l'URL par `#` pour que la page **se concentre sur cet objet** et **exécute** le code :
**Plus de petits XSS pour différents environnements** le payload [**peut être trouvé ici**](https://github.com/terjanq/Tiny-XSS-Payloads) et [**ici**](https://tinyxss.terjanq.me).
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 d'[**abuser du Clickjacking**](../clickjacking.md#xss-clickjacking) (si la page y est vulnérable).
Si vous pensez simplement qu'**il 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/) car vous pourriez **exploiter** la vulnérabilité **sans** exécuter de code **JS**.
Si vous êtes **à l'intérieur d'une balise HTML**, la première chose que vous pourriez essayer est de **vous é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 vous é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 un payload comme (_notez que dans cet exemple, des guillemets doubles sont utilisés pour s'é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_) :
Même si vous **ne pouvez pas vous échapper de l'attribut** (`"` est codé ou supprimé), selon **quel attribut** reflète votre valeur **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)"`**
Les **caractères codés en HTML** à l'intérieur de la valeur des attributs des balises HTML sont **décodés à l'exécution**. Ainsi, quelque chose comme ce qui suit sera valide (le payload est en gras) : `<a id="author" href="http://none" onclick="var tracker='http://foo?`**`'-alert(1)-'`**`';">Retour </a>`
Vous pouvez utiliser les protocoles **`javascript:`** ou **`data:`** dans certains endroits pour **exécuter du code JS arbitraire**. Certains nécessiteront une interaction de l'utilisateur et d'autres non.
**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`).
_**Dans ce cas, l'encodage HTML et l'astuce d'encodage Unicode de la section précédente sont également valables car vous êtes à l'intérieur d'un attribut.**_
En outre, il existe une autre **astuce intéressante** pour ces cas : **Même si votre entrée à l'intérieur de `javascript:...` est encodée en URL, elle sera décodée avant son exécution.** Donc, si vous devez **vous échapper** de la **chaîne de caractères** en utilisant une **apostrophe** et que vous voyez qu'**elle est encodée en URL**, souvenez-vous que **cela n'a pas d'importance,** elle sera **interprétée** comme une **apostrophe** lors du **temps d'exécution**.
Notez que si vous essayez **d'utiliser à la fois**`URLencode + HTMLencode` dans n'importe quel ordre pour encoder le **payload**, cela **ne fonctionnera pas**, mais vous pouvez **les mélanger à l'intérieur du payload**.
Vous pouvez utiliser l'**encodage Hex** et **Octal** à l'intérieur de l'attribut `src` de `iframe` (au moins) pour déclarer **des balises HTML pour exécuter du JS** :
Si vous pouvez injecter une URL quelconque dans une balise **`<a href=`** arbitraire qui contient les attributs **`target="_blank" et rel="opener"`**, consultez **la page suivante pour exploiter ce comportement** :
Tout d'abord, consultez cette page ([https://portswigger.net/web-security/cross-site-scripting/cheat-sheet](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)) pour des gestionnaires d'événements **"on"** utiles.\
Dans le cas où une liste noire vous empêche de créer ces gestionnaires d'événements, vous pouvez essayer les contournements suivants :
Depuis [**ici**](https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tags) **il est maintenant possible d'abuser des inputs cachés avec :**
À partir de [**ici**](https://portswigger.net/research/xss-in-hidden-input-fields) : Vous pouvez exécuter un **XSS payload à l'intérieur d'un attribut caché**, à condition de pouvoir **convaincre** la **victime** d'appuyer sur la **combinaison de touches**. Sur Firefox Windows/Linux, la combinaison 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 :
Plusieurs astuces utilisant différents encodages ont déjà été exposées dans cette section. Revenez **en arrière pour apprendre où vous pouvez utiliser :**
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 occupé par cet élément** pour maximiser les probabilités de déclenchement du lien.
Par exemple, vous pourriez ajouter du style à l'élément comme : `position: fixed; top: 0; left: 0; width: 100%; height: 100%; background-color: red; opacity: 0.5`
Cette astuce provient de [https://medium.com/@skavans\_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703](https://medium.com/@skavans\_/improving-the-impact-of-a-mouse-related-xss-with-styling-and-css-gadgets-b1e5dec2f703)
Dans ces cas, votre **entrée** va être **reflétée à l'intérieur du code JS** d'un fichier `.js` ou entre les balises `<script>...</script>` ou entre des événements HTML qui peuvent exécuter du code JS ou entre des attributs qui acceptent le protocole `javascript:`.
Si votre code est inséré à l'intérieur de `<script> [...] var input = 'données reflétées' [...] </script>`, vous pourriez facilement **échapper à la fermeture de la balise `<script>`** :
Notez que dans cet exemple, nous **n'avons même pas fermé la guillemet simple**, mais ce n'est pas nécessaire car le **navigateur effectue d'abord l'analyse HTML** pour identifier les éléments de la page, y compris les blocs de script, et effectue ensuite l'analyse JavaScript pour comprendre et exécuter les scripts intégrés.
Si les caractères `<>` sont assainis, vous pouvez toujours **échapper à la chaîne** où votre entrée est **localisée** et **exécuter du JS arbitraire**. Il est important de **corriger la syntaxe JS**, car s'il y a des erreurs, le code JS ne sera pas exécuté :
Pour construire des **chaînes de caractères**, en plus des guillemets simples et doubles, JS accepte également les **backticks****` `` `**. Cela est connu sous le nom de littéraux de gabarit car ils permettent d'**inclure des expressions JS** en utilisant la syntaxe `${ ... }`.\
Par conséquent, si vous constatez que votre entrée est **reflétée** à l'intérieur d'une chaîne JS qui utilise des backticks, vous pouvez abuser de la syntaxe `${ ... }` pour exécuter du **code JS arbitraire** :
Reflect.apply.call`${alert}${window}${[1337]}` //Pass the function to call (“alert”), then the “this” value to that function (“window”) which avoids the illegal invocation error and finally an array of arguments to pass to the function.
Reflect.set.call`${location}${'href'}${'javascript:alert\x281337\x29'}` // It requires a valid object in the first argument (“location”), a property in the second argument and a value to assign in the third.
// The “has instance” symbol allows you to customise the behaviour of the instanceof operator, if you set this symbol it will pass the left operand to the function defined by the symbol.
Il existe du **code JS** qui utilise de manière **non sécurisée des données contrôlées par un attaquant** comme `location.href`. Un attaquant pourrait exploiter cela pour exécuter du code JS arbitraire.\
**En raison de l'étendue de l'explication des** [**vulnérabilités DOM, elle a été déplacée sur cette page**](dom-xss.md)**:**
N'oubliez pas non plus qu'**à la fin du post mentionné**, vous pouvez trouver une explication sur les [**attaques de DOM Clobbering**](dom-xss.md#dom-clobbering).
Vous pourriez vérifier si les **valeurs reflétées** sont **normalisées en unicode** sur le serveur (ou côté client) et exploiter cette fonctionnalité pour contourner les protections. [**Trouvez un exemple ici**](../unicode-injection/#xss-cross-site-scripting).
En raison de **l'assignation de masse RoR**, les guillemets sont insérés dans le HTML, puis la restriction de guillemets est contournée et des champs supplémentaires (onfocus) peuvent être ajoutés à l'intérieur de la balise.\
Par exemple, si vous envoyez le payload (d'après [ce rapport](https://hackerone.com/reports/709336)) :
Si vous découvrez que vous pouvez **injecter des en-têtes dans une réponse de redirection 302**, vous pourriez essayer de **faire exécuter du JavaScript arbitraire par le navigateur**. Ce n'est **pas trivial** car les navigateurs modernes n'interprètent pas le corps de la réponse HTTP si le code de statut de la réponse HTTP est 302, donc juste un payload de cross-site scripting est inutile.
Dans [**ce rapport**](https://www.gremwell.com/firefox-xss-302) et [**celui-ci**](https://www.hahwul.com/2020/10/03/forcing-http-redirect-xss/) vous pouvez lire comment vous pouvez tester plusieurs protocoles à l'intérieur de l'en-tête Location et voir si l'un d'eux permet au navigateur d'inspecter et d'exécuter le payload XSS à l'intérieur du corps.\
Protocoles connus dans le passé : `mailto://`, `//x:1/`, `ws://`, `wss://`, _en-tête Location vide_, `resource://`.
Si vous êtes capable d'indiquer le **callback** que le javascript va **exécuter** limité à ces caractères. [**Lisez cette section de ce post**](./#javascript-function) pour trouver comment abuser de ce comportement.
(Depuis [**ici**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Si vous essayez de charger un script avec un **type de contenu** tel que `application/octet-stream`, Chrome affichera l'erreur suivante :
> Refus d'exécuter le script de ‘[https://uploader.c.hc.lc/uploads/xxx'](https://uploader.c.hc.lc/uploads/xxx') car son type MIME (‘application/octet-stream’) n'est pas exécutable, et la vérification stricte du type MIME est activée.
Les seuls **Content-Type**s qui permettront à Chrome d'exécuter un **script chargé** sont ceux à l'intérieur de la constante **`kSupportedJavascriptTypes`** de [https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third\_party/blink/common/mime\_util/mime\_util.cc](https://chromium.googlesource.com/chromium/src.git/+/refs/tags/103.0.5012.1/third\_party/blink/common/mime\_util/mime\_util.cc)
(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 ?
* [**webbundle**](https://web.dev/web-bundles/) : Web Bundles est une fonctionnalité qui vous permet de regrouper un ensemble de données (HTML, CSS, JS…) dans un fichier **`.wbn`**.
Ce comportement a été utilisé dans [**ce compte-rendu**](https://github.com/zwade/yaca/tree/master/solution) pour remapper une bibliothèque à eval afin d'en abuser et déclencher un XSS.
* [**speculationrules**](https://github.com/WICG/nav-speculation)** :** Cette fonctionnalité vise principalement à résoudre certains problèmes causés par le pré-rendu. Elle fonctionne de la manière suivante :
(Depuis [**ici**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Les types de contenu suivants peuvent exécuter XSS dans tous les navigateurs :
Dans d'autres navigateurs, d'autres **`Content-Types`** peuvent être utilisés pour exécuter du JS arbitraire, voir : [https://github.com/BlackFan/content-type-research/blob/master/XSS.md](https://github.com/BlackFan/content-type-research/blob/master/XSS.md)
Lorsque quelque chose comme **`"some {{template}} data".replace("{{template}}", <user_input>)`** est utilisé. L'attaquant pourrait utiliser des [**remplacements de chaînes spéciaux**](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/replace#specifying_a_string_as_the_replacement) pour essayer de contourner certaines protections : ``"123 {{template}} 456".replace("{{template}}", JSON.stringify({"name": "$'$`alert(1)//"}))``
Par exemple dans [**ce compte-rendu**](https://gitea.nitowa.xyz/nitowa/PlaidCTF-YACA), cela a été utilisé pour **échapper à une chaîne JSON** à l'intérieur d'un script et exécuter du code arbitraire.
Si **tout est indéfini** avant d'exécuter du code non fiable (comme dans [**ce compte-rendu**](https://blog.huli.tw/2022/02/08/en/what-i-learned-from-dicectf-2022/#miscx2fundefined55-solves)), il est possible de générer des objets utiles "à partir de rien" pour abuser de l'exécution de code arbitraire non fiable :
[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 :
Par conséquent, si à partir de ce module nous pouvons **appeler une autre fonction**, il est possible d'utiliser `arguments.callee.caller.arguments[1]` depuis cette fonction pour accéder à **`require`** : 
De manière similaire à l'exemple précédent, il est possible **d'utiliser les gestionnaires d'erreurs** pour accéder au **wrapper** du module et obtenir la fonction **`require`** :
Vous **ne pourrez pas accéder aux cookies depuis JavaScript** si le drapeau HTTPOnly est défini dans le cookie. Mais voici [quelques méthodes pour contourner cette protection](../hacking-with-cookies/#httponly) si vous avez de la chance.
Consultez la liste des ports bannis 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).
Lorsque des données sont introduites dans le champ du mot de passe, le nom d'utilisateur et le mot de passe sont envoyés au serveur de l'attaquant, même si le client sélectionne un mot de passe enregistré et ne tape rien, les identifiants seront exfiltrés.
<!-- html5sec - eventhandler - element fires an "onpageshow" event without user interaction on all modern browsers. This can be abused to bypass blacklists as the event is not very well known. -->
<!-- ... add more CDNs, you'll get WARNING: Tried to load angular more than once if multiple load. but that does not matter you'll get a HTTP interaction/exfiltration :-]... -->
D'après [**ce compte-rendu**](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 retrouver dans les attributs JS de 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 :
Vous avez un XSS sur un **site qui utilise la mise en cache** ? Essayez **d'élever cela à SSRF** grâce à l'injection Edge Side Include avec ce payload :
Si une page web crée un PDF en utilisant une entrée contrôlée par l'utilisateur, vous pouvez essayer de **tromper le bot** qui crée le PDF pour qu'il **exécute du code JS arbitraire**.
Ainsi, si le **bot créateur de PDF trouve** des **balises HTML**, il va les **interpréter**, et vous pouvez **abuser** de ce comportement pour provoquer un **XSS côté serveur**.
AMP est une technologie connue pour le développement de pages web super rapides sur les clients mobiles. **AMP est un ensemble de balises HTML soutenues par JavaScript** qui permet facilement de fonctionnalités avec un accent particulier sur la performance et la sécurité. Il existe des [composants AMP](https://amp.dev/documentation/components/?format=websites) pour tout, des carrousels aux éléments de formulaire réactifs, en passant par la récupération de contenu frais à partir de points de terminaison distants.
Le format [**AMP pour Email**](https://amp.dev/documentation/guides-and-tutorials/learn/email-spec/amp-email-format/) fournit [un sous-ensemble de composants AMP](https://github.com/ampproject/amphtml/blob/master/docs/spec/email/amp-email-components.md) que vous pouvez utiliser dans les messages électroniques. Les destinataires des e-mails AMP peuvent visualiser et interagir avec les composants AMP directement dans l'e-mail.
**Conseil pour les primes de bugs** : **inscrivez-vous** sur **Intigriti**, une plateforme de primes de bugs premium créée par des hackers, pour des hackers ! Rejoignez-nous sur [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) dès aujourd'hui, et commencez à gagner des primes allant jusqu'à **100 000 $** !
* Vous travaillez dans une **entreprise de cybersécurité** ? Vous voulez voir votre **entreprise annoncée dans HackTricks** ? ou souhaitez-vous accéder à la **dernière version du PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection d'[**NFTs**](https://opensea.io/collection/the-peass-family) exclusifs
* Obtenez le [**merchandising officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-moi** sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de hacking en soumettant des PR au** [**dépôt hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**dépôt hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
