**Conseil de prime de bug**: **inscrivez-vous** sur **Intigriti**, une plateforme de prime de bug premium créée par des hackers, pour des hackers! Rejoignez-nous sur [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) 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 **réfléchie** dans le HTML ou **utilisée** par du code **JS**.
2.**Trouvez le contexte** où elle est réfléchie/utilisée.
3. Si **réfléchie**
1. Vérifiez **quels symboles vous pouvez utiliser** et en fonction de cela, préparez la charge utile :
1. Dans du **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_...), vous pourriez exploiter une [**Injection de Modèle 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 de Balisage Suspendu - Injection HTML sans script**](../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 où vous êtes piégé prend-il en charge l'exécution JS ?
4. Pouvez-vous contourner les protections ?
3. À l'intérieur du code **JavaScript** :
1. Pouvez-vous échapper à la balise `<script>` ?
2. Pouvez-vous échapper à la chaîne et exécuter un code JS différent ?
3. Vos entrées sont-elles dans des littéraux de modèle \`\` ?
4. Pouvez-vous contourner les protections ?
4. Fonction **JavaScript** en train d'être **exécutée** :
1. Vous pouvez indiquer le nom de la fonction à exécuter. par ex.: `?callback=alert(1)`
1. Vous pourriez exploiter un **XSS DOM**, 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 une faille**.
* **Réfléchie de manière intermédiaire** : Si vous trouvez que la valeur d'un paramètre ou même le chemin est réfléchie dans la page web, vous pourriez exploiter un **XSS Réfléchi**.
* **Stockée et réfléchie** : Si vous trouvez 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 trouvez qu'une valeur contrôlée par vous est accédée en utilisant JS, vous pourriez exploiter un **XSS DOM**.
Lorsque vous essayez d'exploiter un XSS, la première chose que vous devez savoir est **où votre entrée est réfléchie**. Selon le contexte, vous pourrez exécuter du code JS arbitraire de différentes manières.
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.\
Gardez également à l'esprit [Injection de Modèle Côté Client](../client-side-template-injection-csti.md).
1. De **sortir de l'attribut et de la balise** (ensuite vous serez dans le HTML brut) et créer une nouvelle balise HTML pour abuser : `"><img [...]`
2. Si vous **pouvez sortir de l'attribut mais pas de la balise** (`>` est encodé ou supprimé), en fonction de 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 sortir de l'attribut** (`"` est encodé ou supprimé), alors en fonction de **quel attribut** votre valeur est réfléchie et si vous contrôlez toute la valeur ou juste une partie, vous pourrez l'exploiter. 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 réfléchie à l'intérieur de "**balises non exploitables**", vous pourriez essayer le truc de **`accesskey`** pour exploiter 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 réfléchie 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 réfléchie entre les balises **`<script> [...] </script>`**, même si votre entrée est à l'intérieur de guillemets, vous pouvez essayer d'injecter `</script>` et sortir de ce contexte. Cela fonctionne car le **navigateur analysera d'abord les balises HTML** puis le contenu, il ne remarquera donc pas que votre balise `</script>` injectée est à l'intérieur du code HTML.
* Si elle est réfléchie **à 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 elle est réfléchie à 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**:
La levée de Javascript fait référence à la possibilité de **déclarer des fonctions, des variables ou des classes après leur utilisation afin de profiter des scénarios où une 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 tant que paramètre le nom de la fonction à exécuter**. Un exemple courant que l'on peut voir est quelque chose comme : `?callback=callbackFunc`.
Une bonne façon de savoir si quelque chose donné directement par l'utilisateur tente d'être exécuté est de **modifier la valeur du paramètre** (par exemple en la remplaçant par 'Vulnerable') et de chercher dans la console des erreurs comme :
Dans le cas où c'est vulnérable, vous pourriez être en mesure de **déclencher une alerte** en envoyant simplement la valeur : **`?callback=alert(1)`**. Cependant, il est très courant que ces points de terminaison **valident le contenu** pour n'autoriser que des lettres, des chiffres, des points et des traits de soulignement (**`[\w\._]`**).
Cependant, même avec cette limitation, il est toujours possible d'effectuer certaines actions. Cela est possible car vous pouvez utiliser ces caractères valides pour **accéder à n'importe quel élément dans le DOM** :
Cependant, généralement les points d'extrémité exécutant la fonction indiquée sont des points d'extrémité sans beaucoup de DOM intéressant, **d'autres pages dans la même origine** auront un **DOM plus intéressant** pour effectuer davantage d'actions.
Par conséquent, afin d'**exploiter cette vulnérabilité dans un DOM différent**, l'exploitation de la **Méthode d'Exécution de la Même Origine (SOME)** a été développée :
Il y a 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 en abuser pour exécuter du code JS arbitraire.
Ce type de XSS peut être trouvé **partout**. Ils ne dépendent pas seulement de l'exploitation côté client d'une application web mais de **tout****contexte**. Ce type d'**exécution de JavaScript arbitraire** peut même être abusé pour obtenir une **RCE**, **lire** des **fichiers** arbitraires sur les clients et les serveurs, et plus encore.\
Lorsque votre entrée est réfléchie **à l'intérieur de la page HTML** ou que vous pouvez é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 **réfléchir** ce **caractère** et vérifiez s'il est **encodé en HTML** ou **supprimé** ou s'il est **réfléchi sans modifications**. **Seulement dans le dernier cas vous pourrez exploiter ce cas**.\
Pour ces cas, gardez également à l'esprit [**l'Injection de Modèles Côté Client**](../client-side-template-injection-csti.md)**.**\
_**Remarque : Un commentaire HTML peut être fermé en utilisant\*\*\*\***** ****`-->`**** ****ou \*\*\*\*****`--!>`**_
Mais, si la liste blanche/noire des balises/attributs est utilisée, vous devrez **forcer de manière brutale quelles balises** vous pouvez créer.\
Une fois que vous avez **repéré quelles balises sont autorisées**, vous devrez **forcer de manière brutale les 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-papiers**_. Ensuite, envoyez-les toutes en utilisant Burp Intruder et vérifiez si des balises n'ont pas été découvertes comme malveillantes par le WAF. Une fois que vous avez découvert quelles balises vous pouvez utiliser, vous pouvez **forcer de manière brutale tous les événements** en utilisant les balises 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).
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 avec `#` pour que la page se **concentre sur cet objet** et **exécute** le code :
**Plus de petits XSS pour différents environnements** charge utile [**peut être trouvée 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 de [**abuser du Clickjacking**](../clickjacking.md#xss-clickjacking) (si la page est vulnérable).
Si vous pensez simplement que **il est impossible de créer une balise HTML avec un attribut pour exécuter du code JS**, vous devriez vérifier [**Balisage suspendu**](../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 **é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, les 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_):
Même si vous **ne pouvez pas vous échapper de l'attribut** (`"` est encodé ou supprimé), en fonction de **quel attribut** votre valeur est reflétée dans **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 encodés en HTML** à l'intérieur de la valeur des attributs des balises HTML sont **décodés à l'exécution**. Par conséquent, 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:`** à 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, le codage HTML et le tour de codage Unicode de la section précédente sont également valides car vous vous trouvez à l'intérieur d'un attribut.**_
De plus, il y a une **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 d'être exécutée.** Donc, si vous avez besoin de **échapper** de la **chaîne** en utilisant une **apostrophe** et que vous voyez que **elle est encodée en URL**, rappelez-vous que **cela n'a pas d'importance,** elle sera **interprétée** comme une **apostrophe** pendant le **temps d'exécution**.
Notez que si vous essayez d'**utiliser à la fois** `URLencode + HTMLencode` dans n'importe quel ordre pour encoder la **charge utile**, cela **ne fonctionnera pas**, mais vous pouvez les **mélanger à l'intérieur de la charge utile**.
Vous pouvez utiliser l'**encodage hexadécimal** et **octal** à l'intérieur de l'attribut `src` de `iframe` (au moins) pour déclarer des **balises HTML à exécuter JS**:
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**:
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.\
Au cas où il y aurait une liste noire vous empêchant de créer ces gestionnaires d'événements, vous pouvez essayer les contournements suivants:
À partir de [**ici**](https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tags), il est désormais possible d'abuser des inputs cachés avec :
À partir de [**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 touche d'accès. Voici le vecteur :
Plusieurs astuces utilisant différents encodages ont déjà été exposées dans cette section. Retournez en arrière pour apprendre où vous pouvez utiliser :
Si vous trouvez une XSS dans une toute 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 chances que le lien soit déclenché.
Cette astuce a été tirée 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 ce cas, votre **entrée** sera **réfléchie à l'intérieur du code JS** d'un fichier `.js` ou entre les balises `<script>...</script>` ou entre les événements HTML qui peuvent exécuter du code JS ou entre les attributs qui acceptent le protocole `javascript:`.
Si votre code est inséré dans `<script> [...] var input = 'reflected data' [...] </script>`, vous pouvez facilement **échapper à la fermeture de la balise `<script>`** :
Notez que dans cet exemple, nous n'avons même pas fermé l'apostrophe unique, 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 n'effectue que plus tard l'analyse JavaScript pour comprendre et exécuter les scripts intégrés.
Si `<>` sont en train d'être nettoyés, vous pouvez toujours **échapper la chaîne** là 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 dehors des guillemets simples et doubles, JS accepte également les **backticks****` `` `**. Cela est connu sous le nom de modèles de chaînes de caractères 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 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 y a du **code JS** qui utilise des **données contrôlées de manière non sécurisée par un attaquant** comme `location.href`. Un attaquant pourrait exploiter cela pour exécuter du code JS arbitraire.\
**En raison de l'extension de l'explication des** [**vulnérabilités DOM, elle a été déplacée sur cette page**](dom-xss.md)**:**
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**.\
N'oubliez pas qu'**à la fin de l'article mentionné**, vous trouverez une explication sur les [**attaques de DOM Clobbering**](dom-xss.md#dom-clobbering).
Vous pourriez vérifier si les **valeurs réfléchies** sont **normalisées en Unicode** sur le serveur (ou côté client) et abuser de cette fonctionnalité pour contourner les protections. [**Trouvez un exemple ici**](../unicode-injection/#xss-cross-site-scripting).
En raison des **affectations de masse RoR**, des guillemets sont insérés dans le HTML, puis la restriction des guillemets est contournée et des champs supplémentaires (onfocus) peuvent être ajoutés à l'intérieur de la balise.\
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 d'état de la réponse HTTP est 302, donc un payload de script entre sites 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 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.\
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.
(De [**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 :
> Refused to execute script from ‘[https://uploader.c.hc.lc/uploads/xxx'](https://uploader.c.hc.lc/uploads/xxx') because its MIME type (‘application/octet-stream’) is not executable, and strict MIME type checking is enabled.
Les seuls **types de contenu** 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 [**cette explication**](https://github.com/zwade/yaca/tree/master/solution) pour remapper une bibliothèque vers eval afin de l'abuser et déclencher une XSS.
* [**speculationrules**](https://github.com/WICG/nav-speculation)**:** Cette fonctionnalité vise principalement à résoudre certains problèmes causés par le pré-rendu. Cela fonctionne de la manière suivante :
(De [**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, vérifiez : [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 **`"des données {{modèle}}".replace("{{modèle}}", <entrée_utilisateur>)`** 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 tenter de contourner certaines protections : ``"123 {{modèle}} 456".replace("{{modèle}}", JSON.stringify({"nom": "$'$`alert(1)//"}))``
Par exemple, dans [**cette explication**](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 [**cette explication**](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 non fiable arbitraire :
[Selon ce lien](https://stackoverflow.com/questions/28955047/why-does-a-module-level-return-statement-work-in-node-js/28955050#28955050), les modules sont enveloppé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 des **gestionnaires d'erreurs** pour accéder à l'**enveloppe** du module et obtenir la fonction **`require`**:
* JSFuck plus sophistiqué: [https://medium.com/@Master\_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce](https://medium.com/@Master\_SEC/bypass-uppercase-filters-like-a-pro-xss-advanced-methods-daf7a82673ce)
Vous **ne pourrez pas accéder aux cookies depuis JavaScript** si le drapeau HTTPOnly est défini dans le cookie. Mais ici, vous avez [quelques façons de contourner cette protection](../hacking-with-cookies/#httponly) si vous avez de la chance.
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).
Lorsque des données sont saisies dans le champ 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 saisit rien, les informations d'identification seront exfiltrées.
<!-- 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 [**cette analyse**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay), il est possible de découvrir que même si certaines valeurs disparaissent du JS, il est toujours possible de les trouver dans les attributs JS de différents objets. Par exemple, il est toujours possible de trouver une entrée d'une REGEX après que la valeur de l'entrée de la REGEX ait été supprimée :
Avez-vous obtenu du XSS sur un **site qui utilise le caching** ? Essayez de **le mettre à niveau vers SSRF** en utilisant une Injection Edge Side Include avec cette charge utile :
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 **exécuter du code JS arbitraire**.\
Ainsi, si le **bot créateur de PDF trouve** des sortes de **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 développer des pages web super rapides sur les clients mobiles. **AMP est un ensemble de balises HTML soutenues par JavaScript** qui permettent facilement des fonctionnalités avec un accent supplémentaire 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 d'extrémité distants.
Le format [**AMP pour les e-mails**](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 voir et interagir avec les composants AMP directement dans l'e-mail.
**Conseil de prime de bug**: **inscrivez-vous** pour **Intigriti**, une plateforme de prime de bug premium créée par des hackers, pour des hackers! Rejoignez-nous sur [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) aujourd'hui, et commencez à gagner des primes allant jusqu'à **100 000 $**!
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF** Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop)!
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
