**Astuce de prime de bug**: **inscrivez-vous** à **Intigriti**, une plateforme de prime de bug premium créée par des hackers, pour les 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 **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 elle est **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 qui exécutent du code JS, pourriez-vous exploiter une [**Injection de balisage en suspens - Injection HTML sans script**](../dangling-markup-html-scriptless-injection/) ?
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 é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 **exécutée**
1. Vous pouvez indiquer le nom de la fonction à exécuter. par exemple : `?callback=alert(1)`
4. Si elle est **utilisée** :
1. Vous pouvez 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 une faille**.
* **Réfléchie de manière intermédiaire** : Si vous constatez que la valeur d'un paramètre ou même du 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 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 utilisée à l'aide de JS, vous pourriez exploiter un **DOM XSS**.
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 d'une **balise 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.\
1. De **sortir de l'attribut et de la balise** (puis vous serez dans le HTML brut) et de créer une nouvelle balise HTML à abuser : `"><img [...]`
2. Si vous **pouvez sortir de l'attribut mais pas de la balise** (`>` est encodé ou supprimé), selon la balise, vous pouvez **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 selon **quel attribut** votre valeur est réfléchie et **si vous contrôlez toute la valeur ou seulement une partie**, vous pourrez l'exploiter. 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)"`**
4. Si votre entrée est réfléchie à l'intérieur de balises "**non exploitables**", vous pouvez 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 de sortir de ce contexte. Cela fonctionne parce que 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** :
Par conséquent, si vous avez des scénarios où vous pouvez **injecter du code JS après l'utilisation d'un objet non déclaré**, vous pouvez **corriger la syntaxe** en le déclarant (ainsi votre code s'exécute au lieu de générer une erreur) :
Pour plus d'informations sur le Hoisting Javascript, consultez: [https://jlajara.gitlab.io/Javascript\_Hoisting\_in\_XSS\_Scenarios](https://jlajara.gitlab.io/Javascript\_Hoisting\_in\_XSS\_Scenarios)
Plusieurs pages web ont des points d'extrémité qui **acceptent en tant que paramètre le nom de la fonction à exécuter**. Un exemple courant que l'on peut trouver est quelque chose comme : `?callback=callbackFunc`.
Une bonne façon 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 la remplaçant par 'Vulnerable') et de chercher dans la console des erreurs comme :
Dans le cas où cela 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 d'extrémité **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 de **exploiter cette vulnérabilité dans un DOM différent**, l'exploitation de la **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** des **données contrôlées par un attaquant** comme `location.href`. Un attaquant pourrait exploiter 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 côté client d'une application web, mais de **n'importe quel****contexte**. Ce type d'exécution de **JavaScript arbitraire** peut même être utilisé 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 utiliser `<` 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**.\
Mais, si une liste noire/blanche de balises/attributs est utilisée, vous devrez **forcer de manière brutale quelles balises** vous pouvez créer.\
Une fois que vous avez **localisé 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 certaines balises n'ont pas été détectées comme malveillantes par le pare-feu d'application web (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 pouvez 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** 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 pouvez essayer d'**abuser du Clickjacking** (si la page 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 **le balisage suspendu** 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 pouvez 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 pouvez 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 directement reflétée à l'intérieur de la balise_):
Les événements de style sont une technique couramment utilisée dans les attaques de script entre sites (XSS) pour exécuter du code malveillant sur un site web. Cette technique exploite les vulnérabilités dans la façon dont le site web gère les entrées utilisateur et les affiche sur la page.
L'attaque XSS par événements de style consiste à injecter du code JavaScript dans les attributs de style d'un élément HTML. Lorsque le navigateur interprète le code, il exécute le script malveillant, ce qui permet à l'attaquant de voler des informations sensibles, de modifier le contenu de la page ou de rediriger l'utilisateur vers un site malveillant.
Pour se protéger contre les attaques XSS par événements de style, les développeurs doivent mettre en œuvre des mesures de sécurité telles que la validation et l'échappement des entrées utilisateur, l'utilisation de listes blanches pour les caractères autorisés et la désactivation de l'exécution de scripts dans les attributs de style.
Il est essentiel de comprendre les techniques d'attaque XSS par événements de style afin de pouvoir les détecter et les prévenir lors de l'évaluation de la sécurité d'un site web. Les tests de pénétration et les audits de sécurité réguliers sont recommandés pour identifier et corriger les vulnérabilités XSS potentielles.
Même si vous **ne pouvez pas échapper à l'attribut** (`"` est encodé ou supprimé), selon **quel attribut** votre valeur est reflétée, **si vous contrôlez toute la valeur ou seulement une partie**, vous pourrez l'exploiter. Par **exemple**, si vous contrôlez un événement tel que `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 (la charge utile est en gras) : `<a id="author" href="http://none" onclick="var tracker='http://foo?`**`'-alert(1)-'`**`';">Go Back </a>`
**Contourner l'événement interne en utilisant l'encodage Unicode**
---
### Description
This technique involves bypassing client-side input validation by using Unicode encoding to inject malicious code into a web application. By encoding the payload, it is possible to bypass filters that are looking for specific keywords or characters.
Cross-Site Scripting (XSS) vulnerabilities occur when user input is not properly sanitized and is rendered on a web page without proper encoding. This allows an attacker to inject malicious code that will be executed by the victim's browser.
4. Trigger the execution of the payload by submitting the form or interacting with the web application.
5. The injected code will be executed by the victim's browser, allowing the attacker to perform various actions such as stealing sensitive information or performing unauthorized actions on behalf of the victim.
To prevent this type of attack, it is important to properly sanitize and validate all user input before rendering it on a web page. This can be done by implementing input validation mechanisms and using output encoding techniques to ensure that user input is properly encoded before being displayed.
*Note: This technique should only be used for educational purposes and with proper authorization. Unauthorized use of this technique is illegal and unethical.*
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, 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 truc de codage Unicode de la section précédente sont également valables car vous êtes à l'intérieur d'un attribut.**_
De plus, 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 d'être exécutée.** Donc, si vous avez besoin de **vous échapper** de la **chaîne de caractères** en utilisant une **apostrophe** et que vous constatez qu'elle est **encodée en URL**, rappelez-vous que **cela n'a pas d'importance**, elle sera **interprétée** comme une **apostrophe** lors de l'**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 la balise `iframe` (au moins) pour déclarer des **balises HTML à exécuter en JS**:
Reverse tab nabbing is a type of cross-site scripting (XSS) attack that targets users who have multiple tabs open in their web browser. The attack takes advantage of the trust users have in the websites they visit.
In a typical scenario, the attacker injects malicious code into a website that the user visits. This code is designed to detect when the user switches to a different tab or window. Once the user switches tabs, the malicious code modifies the content of the original tab, making it appear as if the user is still on the same website.
The goal of reverse tab nabbing is to trick the user into entering sensitive information, such as login credentials or credit card details, into the modified tab. Since the user believes they are still on a trusted website, they are more likely to provide this information willingly.
To protect against reverse tab nabbing, users should be cautious when switching between tabs or windows, especially when entering sensitive information. It is also important for website developers to implement proper security measures, such as input validation and output encoding, to prevent XSS attacks.
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** utiles commençant par "on".\
À partir de [**ici**](https://portswigger.net/research/exploiting-xss-in-hidden-inputs-and-meta-tags), il est maintenant possible d'abuser des inputs cachés avec :
<buttonpopovertarget="newsletter">Subscribe to newsletter</button>
<divpopoverid="newsletter">Newsletter popup</div>
```
À 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 accesskey. Voici le vecteur :
Si vous trouvez une **XSS dans une toute petite partie** du site web qui nécessite une certaine 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 activé.
Par exemple, vous pourriez ajouter un peu de style à l'élément comme ceci : `position: fixed; top: 0; left: 0; width: 100%; height: 100%; background-color: red; opacity: 0.5`
Cette astuce a été prise sur [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 = 'données réfléchies' [...] </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**, 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 cours de désinfection, 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 en cas d'erreurs, le code JS ne sera pas exécuté :
Afin de 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 littéraux 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 exploiter la syntaxe `${ ... }` pour exécuter du **code JS arbitraire** :
L'exécution de code encodé est une technique couramment utilisée dans les attaques de type Cross-Site Scripting (XSS). Elle consiste à encoder le code malveillant de manière à contourner les filtres de sécurité et à exécuter du code sur le navigateur de la victime.
L'objectif principal de cette technique est de tromper les filtres de sécurité qui analysent le contenu des requêtes et des réponses HTTP. En encodant le code malveillant, il devient plus difficile pour les filtres de détecter et de bloquer le code dangereux.
Il existe plusieurs méthodes d'encodage couramment utilisées, telles que l'encodage HTML, l'encodage URL, l'encodage JavaScript, etc. Chaque méthode d'encodage a ses propres caractéristiques et est utilisée en fonction du contexte de l'attaque.
Lors de l'exploitation de cette technique, l'attaquant insère du code malveillant encodé dans une application Web vulnérable. Lorsque la victime accède à la page contenant le code encodé, le navigateur interprète le code et l'exécute, ce qui peut entraîner des conséquences néfastes telles que le vol de données sensibles, la prise de contrôle de session, etc.
Pour se protéger contre les attaques d'exécution de code encodé, il est essentiel de mettre en place des mécanismes de sécurité appropriés, tels que la validation et l'échappement des entrées utilisateur, la mise en œuvre de listes blanches pour les caractères autorisés, l'utilisation de bibliothèques de sécurité pour l'encodage et le décodage des données, etc.
Il est également recommandé de sensibiliser les développeurs et les utilisateurs aux risques liés aux attaques XSS et de mettre en place des pratiques de développement sécurisées pour réduire les vulnérabilités potentielles.
L'encodage Unicode est une technique utilisée pour contourner les filtres de sécurité et exécuter du code JavaScript malveillant sur une application web. Cette technique exploite les vulnérabilités de sécurité liées à la manipulation incorrecte des caractères Unicode par l'application.
Lorsqu'une application web ne traite pas correctement les caractères Unicode, il est possible d'insérer des séquences spécifiques de caractères qui seront interprétées comme du code JavaScript par le navigateur. Cela permet à un attaquant d'exécuter du code arbitraire sur le navigateur de la victime, ce qui peut entraîner des conséquences graves telles que le vol de données sensibles ou la prise de contrôle de l'application.
Pour exploiter cette vulnérabilité, l'attaquant doit identifier les points d'injection de code JavaScript sur l'application web cible. Ces points peuvent être des champs de formulaire, des paramètres d'URL ou d'autres zones de saisie de données.
Une fois que l'attaquant a identifié un point d'injection, il peut utiliser des séquences de caractères Unicode spécifiques pour encoder le code JavaScript malveillant. Par exemple, l'attaquant peut utiliser l'encodage Unicode pour contourner les filtres de sécurité qui bloquent les balises `<script>`.
Voici un exemple d'encodage Unicode pour exécuter une alerte JavaScript :
```html
<script>
var payload = "\u003c\u0073\u0063\u0072\u0069\u0070\u0074\u003e\u0061\u006c\u0065\u0072\u0074\u0028\u0027XSS\u0027\u0029\u003c\u002f\u0073\u0063\u0072\u0069\u0070\u0074\u003e";
Dans cet exemple, le code JavaScript malveillant est encodé en utilisant l'encodage Unicode pour contourner les filtres de sécurité. Lorsque le navigateur interprète le code, il exécute l'instruction `alert('XSS')`, ce qui affiche une boîte de dialogue avec le message "XSS".
Pour se protéger contre les attaques d'encodage Unicode, il est essentiel de mettre en place des mécanismes de validation et de filtrage appropriés pour tous les champs de saisie de données. Voici quelques bonnes pratiques à suivre :
- Utilisez des bibliothèques de validation de données pour vérifier que les entrées utilisateur sont conformes aux attentes.
- Évitez d'accepter des caractères Unicode non autorisés ou inattendus dans les champs de saisie.
- Utilisez des filtres de sécurité pour bloquer les séquences de caractères potentiellement dangereuses.
- Éduquez les développeurs sur les bonnes pratiques de sécurité et encouragez-les à utiliser des fonctions de codage sécurisées pour manipuler les données.
En suivant ces bonnes pratiques, vous pouvez réduire considérablement le risque d'exploitation des vulnérabilités d'encodage Unicode et renforcer la sécurité de votre application web.
Lorsque vous effectuez des tests de pénétration pour détecter les vulnérabilités XSS (Cross-Site Scripting), il peut être utile de contourner les filtres de sécurité qui bloquent les caractères spéciaux. Une technique courante consiste à utiliser des substitutions d'espaces pour tromper les filtres et exécuter du code malveillant.
Les substitutions d'espaces consistent à remplacer les espaces normaux par d'autres caractères qui sont interprétés comme des espaces par le navigateur. Voici quelques exemples de substitutions d'espaces couramment utilisées :
Lorsque vous utilisez ces substitutions d'espaces, assurez-vous de les placer aux endroits appropriés dans votre code JS pour éviter toute erreur de syntaxe.
When injecting JavaScript code into a web application, it is important to understand how new lines are interpreted. In some cases, new lines can be used to bypass input filters and execute malicious code.
Lors de l'injection de code JavaScript dans une application web, il est important de comprendre comment les sauts de ligne sont interprétés. Dans certains cas, les sauts de ligne peuvent être utilisés pour contourner les filtres de saisie et exécuter du code malveillant.
To bypass this limitation, we can use the JavaScript new line trick. By using the `\` character followed by a new line, we can continue the code execution on the next line.
Pour contourner cette limitation, nous pouvons utiliser la technique du saut de ligne JavaScript. En utilisant le caractère `\` suivi d'un saut de ligne, nous pouvons continuer l'exécution du code à la ligne suivante.
En utilisant la technique du saut de ligne JavaScript, nous pouvons contourner les filtres de saisie qui peuvent rechercher des motifs ou des mots-clés spécifiques.
It is important to note that this technique may not work in all scenarios, as it depends on how the web application handles new lines and input filtering.
Il est important de noter que cette technique peut ne pas fonctionner dans tous les scénarios, car cela dépend de la façon dont l'application web gère les sauts de ligne et le filtrage des entrées.
Les espaces blancs en JavaScript se réfèrent aux caractères non imprimables tels que les espaces, les tabulations et les sauts de ligne. Ces espaces blancs sont généralement ignorés par l'interpréteur JavaScript lors de l'exécution du code.
Cependant, dans le contexte de la sécurité, les espaces blancs peuvent être utilisés de manière malveillante pour contourner les filtres de sécurité et exécuter du code JavaScript non autorisé. Cette technique est connue sous le nom d'obfuscation de code.
L'obfuscation de code consiste à ajouter des espaces blancs supplémentaires ou à les réorganiser de manière à rendre le code JavaScript illisible pour les humains, tout en restant exécutable par l'interpréteur JavaScript.
Il est important de noter que l'obfuscation de code n'est pas une technique de piratage en soi, mais plutôt une méthode utilisée par les attaquants pour masquer leur code malveillant et éviter la détection par les outils de sécurité.
Lors de l'audit de sécurité d'une application web, il est essentiel de prendre en compte la possibilité d'obfuscation de code et de mettre en place des mesures de sécurité appropriées pour détecter et prévenir les attaques utilisant cette technique.
Lors de l'audit d'une application web, il est important de vérifier si le code JavaScript est correctement filtré et sécurisé. Une technique courante utilisée par les attaquants est d'insérer du code JavaScript malveillant à l'intérieur de commentaires HTML.
Les commentaires HTML sont généralement utilisés pour fournir des informations supplémentaires sur le code ou pour désactiver temporairement une partie du code. Cependant, si ces commentaires ne sont pas correctement filtrés, ils peuvent être exploités par des attaquants pour exécuter du code JavaScript non autorisé sur le navigateur des utilisateurs.
Pour vérifier si une application est vulnérable à cette attaque, vous pouvez insérer du code JavaScript malveillant à l'intérieur d'un commentaire HTML et voir s'il est exécuté lorsque la page est chargée. Par exemple :
Pour se protéger contre cette attaque, il est essentiel de filtrer correctement les commentaires HTML et de supprimer tout code JavaScript potentiellement dangereux.
L'une des techniques couramment utilisées en XSS (Cross-Site Scripting) consiste à exécuter du code JavaScript sans utiliser de parenthèses. Cette technique est souvent utilisée pour contourner les filtres de sécurité et injecter du code malveillant dans une application web.
L'idée principale derrière cette technique est d'exploiter les contextes où le code JavaScript peut être exécuté sans l'utilisation de parenthèses. Par exemple, dans les balises HTML telles que `<script>` ou `<img>`, il est possible d'insérer du code JavaScript sans utiliser de parenthèses.
Dans cet exemple, le code JavaScript `alert("XSS")` est stocké dans la variable `payload` et est ensuite exécuté à l'aide de la fonction `eval()`. Cela permet d'afficher une boîte de dialogue avec le message "XSS" sur la page web.
Il est important de noter que l'utilisation de cette technique peut être dangereuse et illégale si elle est utilisée sans autorisation appropriée. Elle est souvent utilisée par les professionnels de la sécurité lors de tests d'intrusion pour identifier les vulnérabilités potentielles dans les applications web.
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 des **données contrôlées par un attaquant** de manière non sécurisée, 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 vers cette page**](dom-xss.md)**:**
N'oubliez pas non plus qu'à la fin de l'article mentionné, vous trouverez une explication sur les [**attaques de clobbering DOM**](dom-xss.md#dom-clobbering).
Vous pouvez vérifier si les **valeurs réfléchies** 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 la **vulnérabilité de l'attribution de masse de 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.\
Par exemple, si vous envoyez la charge utile suivante ([à partir de 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 pouvez essayer de **faire exécuter du JavaScript arbitraire par le navigateur**. Cela 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 une charge utile 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'entre eux permet au navigateur d'inspecter et d'exécuter la charge utile XSS à l'intérieur du corps.\
Si vous êtes en mesure d'indiquer la **fonction de rappel** que JavaScript va **exécuter**, limitée à ces caractères. [**Lisez cette section de cet article**](./#javascript-function) pour savoir comment exploiter ce comportement.
(À partir 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 présents dans 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)
(À partir de [**ici**](https://blog.huli.tw/2022/04/24/en/how-much-do-you-know-about-script-type/)) Alors, quels types peuvent être indiqués pour charger un script ?
* [**webbundle**](https://web.dev/web-bundles/) : Les Web Bundles sont 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 de l'exploiter et de 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. Elle fonctionne de la manière suivante :
(À partir 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 **`Types de contenu`** 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 {{template}}".replace("{{template}}", <user_input>)`** est utilisé. L'attaquant pourrait utiliser des [**remplacements de chaînes spéciales**](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Objets_globaux/String/replace#spécification_d_une_chaîne_comme_remplacement) pour tenter 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 non fiable arbitraire :
* Utilisation de import()
```javascript
// although import "fs" doesn’t work, import('fs') does.
[Selon cette source](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)
Le XSS (Cross-Site Scripting) est une vulnérabilité courante dans les applications Web qui permet à un attaquant d'injecter du code malveillant dans les pages Web consultées par les utilisateurs. Cela peut entraîner des attaques telles que le vol de sessions, le vol de cookies et la redirection vers des sites Web malveillants.
## Types de XSS
Il existe trois types de XSS :
1. XSS stocké : le code malveillant est stocké sur le serveur et est renvoyé à chaque fois que la page est consultée.
2. XSS réfléchi : le code malveillant est inclus dans un lien ou un formulaire et est renvoyé à la victime lorsqu'elle clique sur le lien ou soumet le formulaire.
3. XSS basé sur le DOM : le code malveillant est injecté dans le DOM (Document Object Model) de la page Web et est exécuté côté client.
## Prévention du XSS
Pour prévenir les attaques XSS, il est important de mettre en place les mesures suivantes :
1. Échapper les caractères spéciaux : les données provenant des utilisateurs doivent être correctement échappées pour éviter l'injection de code malveillant.
2. Valider et filtrer les entrées utilisateur : toutes les entrées utilisateur doivent être validées et filtrées pour s'assurer qu'elles ne contiennent pas de code malveillant.
3. Utiliser des bibliothèques de sécurité : utilisez des bibliothèques de sécurité telles que OWASP ESAPI pour aider à prévenir les attaques XSS.
4. Mettre en place des en-têtes de sécurité : configurez les en-têtes de sécurité HTTP tels que Content-Security-Policy (CSP) pour limiter les sources de contenu autorisées sur une page Web.
Ce code injecte un script malveillant qui affiche une alerte sur la page Web. Les attaquants peuvent utiliser des techniques plus avancées pour voler des informations sensibles ou effectuer des actions malveillantes au nom de l'utilisateur.
Il est essentiel de mettre en place des mesures de sécurité appropriées pour prévenir les attaques XSS et protéger les utilisateurs de votre application Web.
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 moyens de contourner cette protection](../hacking-with-cookies/#httponly) si vous avez de la chance.
To find internal IPs, you can use various techniques during a penetration test. These techniques can help you identify the IP addresses assigned to devices within the target network.
Perform DNS enumeration to gather information about the target's internal infrastructure. This can be done using tools like `dnsenum`, `dnsrecon`, or `nslookup`. By querying the DNS server, you may obtain internal IP addresses associated with the target domain.
Use network scanning tools such as `nmap` or `masscan` to scan the target network for live hosts. By scanning the network, you can identify active devices and their corresponding IP addresses.
Perform a reverse DNS lookup on the target IP addresses. This can be done using tools like `nslookup` or online services. By performing a reverse DNS lookup, you may obtain information about the internal hostnames associated with the IP addresses.
Use banner grabbing techniques to gather information from network services running on the target network. By analyzing the banners, you may find internal IP addresses mentioned in the service responses.
Engage in social engineering tactics to gather information about the target's internal infrastructure. This can involve contacting employees or using publicly available information to obtain internal IP addresses.
The `port-scanner-fetch.js` script is a simple port scanner that uses the `fetch` function in JavaScript to send HTTP requests to a target host and port. It can be used to quickly identify open ports on a target system.
To use the script, you need to provide the target host and a range of ports to scan. The script will then send HTTP requests to each port in the specified range and check for a response. If a response is received, it means that the port is open.
Note: Port scanning can be considered illegal or unethical if performed without proper authorization. Always ensure that you have the necessary permissions before conducting any port scanning activities.
This tool is a port scanner specifically designed for websockets. It allows you to scan for open ports on a target server that supports the websocket protocol. The scanner sends a connection request to each port and waits for a response. If a response is received, it means that the port is open and the websocket service is running.
To use the port scanner, you need to provide the target server's IP address and the range of ports you want to scan. The scanner will then attempt to connect to each port within the specified range.
Replace `<target_ip>` with the IP address of the server you want to scan. `<start_port>` and `<end_port>` should be replaced with the range of ports you want to scan. For example, to scan ports 1 to 100 on a server with IP address 192.168.0.1, you would run:
This port scanner is intended for use in authorized penetration testing or educational purposes only. Unauthorized use of this tool is strictly prohibited. The author is not responsible for any misuse or damage caused by this tool.
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).
Lors de tests d'intrusion sur des applications web, il est courant de rechercher des vulnérabilités de type Cross-Site Scripting (XSS). L'une des variantes les plus intéressantes de cette vulnérabilité est l'exploitation des mots de passe auto-remplis.
Les navigateurs modernes offrent souvent la fonctionnalité de remplissage automatique des formulaires, y compris les champs de mot de passe. Cette fonctionnalité est pratique pour les utilisateurs, mais elle peut également être exploitée par des attaquants.
L'attaque consiste à injecter un code JavaScript malveillant dans un champ de saisie de texte, tel qu'un champ de recherche ou un champ de commentaire. Lorsque le navigateur auto-remplit le champ de mot de passe, le code JavaScript est exécuté, permettant à l'attaquant de capturer le mot de passe.
Pour exploiter cette vulnérabilité, l'attaquant doit identifier les champs de saisie de texte vulnérables et injecter le code JavaScript approprié. Une fois que le mot de passe est capturé, il peut être utilisé pour accéder au compte de l'utilisateur ou pour mener d'autres attaques.
Il est important de noter que cette attaque ne fonctionne que si le navigateur de la victime a activé la fonctionnalité de remplissage automatique des mots de passe. Cependant, étant donné que de nombreux utilisateurs utilisent cette fonctionnalité, il est essentiel de prendre des mesures pour se protéger contre cette vulnérabilité.
Pour se protéger contre cette attaque, les développeurs doivent mettre en œuvre des mesures de sécurité appropriées, telles que la validation et l'échappement des entrées utilisateur, ainsi que la désactivation de la fonctionnalité de remplissage automatique des mots de passe. Les utilisateurs doivent également être conscients des risques associés à l'utilisation de cette fonctionnalité et prendre des mesures pour protéger leurs mots de passe, comme l'utilisation de gestionnaires de mots de passe sécurisés.
En tant que testeurs d'intrusion, il est important de comprendre cette vulnérabilité et de l'inclure dans nos tests afin d'aider les développeurs à identifier et à corriger les failles de sécurité potentielles.
Lorsque des données sont saisies 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 saisit rien, les informations d'identification seront exfiltrées.
Lorsque vous effectuez un test d'intrusion sur une application Web, il est important de vérifier si elle est vulnérable aux attaques de type Cross-Site Scripting (XSS). Une variante de cette attaque est le vol de messages PostMessage.
Le vol de messages PostMessage se produit lorsque des scripts malveillants sont injectés dans une application Web et interceptent les messages échangés entre les fenêtres ouvertes dans le navigateur. Ces messages peuvent contenir des informations sensibles telles que des jetons d'authentification ou des données utilisateur.
Pour exploiter cette vulnérabilité, un attaquant peut utiliser du code JavaScript pour écouter les événements de message et extraire les données qu'il souhaite voler. Il peut également envoyer des messages malveillants à d'autres fenêtres ouvertes dans le navigateur, ce qui peut entraîner des conséquences graves, telles que la divulgation de données confidentielles ou l'exécution de commandes malveillantes.
Pour se protéger contre le vol de messages PostMessage, les développeurs doivent mettre en place des mécanismes de sécurité tels que la validation et l'échappement des données avant de les envoyer via PostMessage. Les applications Web doivent également utiliser des stratégies de sécurité appropriées, telles que l'utilisation de l'attribut `sandbox` pour restreindre les fonctionnalités des fenêtres ouvertes.
En tant que testeur d'intrusion, il est essentiel de vérifier si une application Web est vulnérable au vol de messages PostMessage. Cela peut être fait en injectant du code JavaScript malveillant et en observant si les messages sont interceptés ou modifiés. Si une vulnérabilité est détectée, il est important de la signaler aux développeurs afin qu'ils puissent prendre les mesures nécessaires pour la corriger.
<!-- 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 :-]... -->
À partir de [**cette explication**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay), il est possible de constater 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 même après que la valeur de l'entrée de la REGEX ait été supprimée :
Avez-vous trouvé une XSS sur un **site qui utilise le caching** ? Essayez de **l'améliorer en SSRF** grâce à une injection de Edge Side Include avec cette charge utile :
Si une page web crée un PDF à l'aide d'une entrée contrôlée par l'utilisateur, vous pouvez essayer de **tromper le bot** qui crée le PDF en lui faisant exécuter du **code JS arbitraire**.\
Ainsi, si le **bot créateur de PDF trouve** des **balises HTML**, il va les **interpréter**, et vous pouvez **exploiter** ce comportement pour provoquer un **XSS côté serveur**.
AMP est une technologie connue pour développer des pages web ultra-rapides sur les clients mobiles. **AMP est un ensemble de balises HTML soutenues par JavaScript** qui permettent facilement des fonctionnalités avec une attention particulière sur les performances 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.
**Astuce de prime de bug** : **inscrivez-vous** sur **Intigriti**, une plateforme premium de **prime de bug 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 $** !
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? Ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* **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 piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
