<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Expert en équipe rouge AWS de HackTricks)</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 [**La famille PEASS**](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-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **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.
Rejoignez le serveur [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) pour communiquer avec des pirates expérimentés et des chasseurs de primes en bugs !
La politique de sécurité du contenu (CSP) est reconnue comme une technologie de navigateur, principalement destinée à **protéger contre des attaques telles que le script intersite (XSS)**. Elle fonctionne en définissant et en détaillant les chemins et les sources à partir desquels les ressources peuvent être chargées en toute sécurité par le navigateur. Ces ressources comprennent une gamme d'éléments tels que des images, des cadres et du JavaScript. Par exemple, une politique peut autoriser le chargement et l'exécution de ressources à partir du même domaine (self), y compris des ressources intégrées et l'exécution de code de chaîne via des fonctions telles que `eval`, `setTimeout` ou `setInterval`.
La mise en œuvre de la CSP est réalisée via des **en-têtes de réponse** ou en incorporant des **éléments meta dans la page HTML**. En suivant cette politique, les navigateurs appliquent proactivement ces stipulations et bloquent immédiatement toute violation détectée.
*`Content-Security-Policy` : Applique le CSP ; le navigateur bloque toute violation.
*`Content-Security-Policy-Report-Only` : Utilisé pour la surveillance ; signale les violations sans les bloquer. Idéal pour les tests dans des environnements de pré-production.
CSP restreint les origines pour le chargement de contenu actif et passif, contrôlant des aspects tels que l'exécution de JavaScript en ligne et l'utilisation de `eval()`. Un exemple de politique est :
* **script-src**: Autorise des sources spécifiques pour JavaScript, y compris des URL, des scripts en ligne, et des scripts déclenchés par des gestionnaires d'événements ou des feuilles de style XSLT.
* **default-src**: Définit une politique par défaut pour récupérer des ressources lorsque des directives de récupération spécifiques sont absentes.
* **child-src**: Spécifie les ressources autorisées pour les travailleurs web et le contenu des cadres intégrés.
* **connect-src**: Restreint les URL qui peuvent être chargées en utilisant des interfaces comme fetch, WebSocket, XMLHttpRequest.
* **frame-src**: Restreint les URL pour les cadres.
* **frame-ancestors**: Spécifie quelles sources peuvent intégrer la page actuelle, applicable aux éléments tels que `<frame>`, `<iframe>`, `<object>`, `<embed>`, et `<applet>`.
* **img-src**: Définit les sources autorisées pour les images.
*`'unsafe-inline'`: Autorise l'utilisation de ressources en ligne comme les `<script>` ou `<style>` en ligne, non recommandé pour des raisons de sécurité.
*`'nonce'`: Une liste blanche pour des scripts en ligne spécifiques en utilisant un nonce cryptographique (nombre utilisé une fois).
* Si vous avez une exécution JS limitée, il est possible d'obtenir un nonce utilisé à l'intérieur de la page avec `doc.defaultView.top.document.querySelector("[nonce]")` et ensuite de le réutiliser pour charger un script malveillant (si strict-dynamic est utilisé, toute source autorisée peut charger de nouvelles sources donc ce n'est pas nécessaire), comme dans :
*`'strict-dynamic'`: Autorise le chargement de scripts depuis n'importe quelle source s'ils ont été listés en liste blanche par un nonce ou un hachage.
*`'strict-origin'`: Similaire à 'self' mais garantit que le niveau de sécurité du protocole des sources correspond au document (seules les origines sécurisées peuvent charger des ressources à partir d'origines sécurisées).
*`'strict-origin-when-cross-origin'`: Envoie des URL complètes lors de la réalisation de requêtes de même origine, mais envoie uniquement l'origine lorsque la requête est cross-origin.
*`'unsafe-allow-redirects'`: Autorise le chargement de ressources qui redirigeront immédiatement vers une autre ressource. Non recommandé car cela affaiblit la sécurité.
Si vous pouvez d'une manière ou d'une autre faire en sorte qu'un **code JS autorisé crée une nouvelle balise script** dans le DOM avec votre code JS, car un script autorisé le crée, la **nouvelle balise script pourra être exécutée**.
Cependant, il est très probable que le serveur **valide le fichier téléchargé** et ne vous permettra d'**uploader que des types de fichiers spécifiques**.
De plus, même si vous pouviez télécharger un **code JS à l'intérieur** d'un fichier en utilisant une extension acceptée par le serveur (comme : _script.png_), cela ne suffira pas car certains serveurs comme le serveur apache **sélectionnent le type MIME du fichier en fonction de l'extension** et les navigateurs comme Chrome **refuseront d'exécuter du code Javascript** à l'intérieur de ce qui devrait être une image. "Heureusement", il y a des erreurs. Par exemple, lors d'un CTF, j'ai appris qu'**Apache ne reconnaît pas** l'extension _**.wave**_, donc il ne la sert pas avec un **type MIME comme audio/\***.
À partir de là, si vous trouvez une XSS et un téléchargement de fichier, et que vous parvenez à trouver une **extension mal interprétée**, vous pourriez essayer de télécharger un fichier avec cette extension et le contenu du script. Ou, si le serveur vérifie le format correct du fichier téléchargé, créez un polyglotte ([quelques exemples de polyglottes ici](https://github.com/Polydet/polyglot-database)).
Si l'injection de JS n'est pas possible, vous pouvez toujours essayer d'exfiltrer par exemple des informations d'identification en **injectant une action de formulaire** (et en espérant que les gestionnaires de mots de passe remplissent automatiquement les mots de passe). Vous pouvez trouver un [**exemple dans ce rapport**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp). De plus, notez que `default-src` ne couvre pas les actions de formulaire.
#### Payloads utilisant Angular + une bibliothèque avec des fonctions qui renvoient l'objet `window` ([consultez cet article](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
L'article montre que vous pourriez **charger** toutes les **bibliothèques** depuis `cdn.cloudflare.com` (ou tout autre référentiel de bibliothèques JS autorisé), exécuter toutes les fonctions ajoutées de chaque bibliothèque, et vérifier **quelles fonctions de quelles bibliothèques renvoient l'objet `window`**.
Selon [**cette publication de CTF**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?\_x\_tr\_sl=es&\_x\_tr\_tl=en&\_x\_tr\_hl=es&\_x\_tr\_pto=wapp#noteninja-3-solves), vous pouvez abuser de [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) à l'intérieur d'une CSP pour exécuter du code JS arbitraire en contournant la CSP :
Il est possible d'abuser de Google Apps Script pour recevoir des informations dans une page à l'intérieur de script.google.com. Comme c'est [fait dans ce rapport](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/).
Les scénarios comme celui où `script-src` est défini sur `self` et un domaine particulier qui est autorisé peuvent être contournés en utilisant JSONP. Les points de terminaison JSONP permettent des méthodes de rappel non sécurisées qui permettent à un attaquant d'exécuter du XSS, charge utile de travail:
[**JSONBee**](https://github.com/zigoo0/JSONBee) **contient des points de terminaison JSONP prêts à l'emploi pour contourner la CSP de différents sites web.**
La même vulnérabilité se produira si le **point de terminaison de confiance contient une redirection ouverte** car si le point de terminaison initial est de confiance, les redirections le sont aussi.
Comme décrit dans le [post suivant](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses), il existe de nombreux domaines tiers, qui pourraient être autorisés quelque part dans la CSP, peuvent être utilisés pour soit exfiltrer des données soit exécuter du code JavaScript. Certains de ces tiers sont :
Si vous trouvez l'un des domaines autorisés dans la CSP de votre cible, il est probable que vous puissiez contourner la CSP en vous inscrivant sur le service tiers et, soit exfiltrer des données vers ce service, soit exécuter du code.
Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, such as Cross Site Scripting (XSS) and data injection attacks. CSP is implemented by using the `Content-Security-Policy` HTTP header.
1.**Inline Script Bypass**: By using techniques like inline event handlers or inline `<script>` tags, it is possible to execute arbitrary JavaScript code even when CSP is in place.
2.**External Script Bypass**: Loading external scripts from whitelisted domains or using techniques like JSONP can help bypass CSP restrictions.
3.**Nonce Bypass**: If a website uses nonces in its CSP policy, finding a way to execute JavaScript with the correct nonce can bypass CSP.
4.**Unsafe Inline Bypass**: Some websites use the `'unsafe-inline'` keyword in their CSP policy, which allows the execution of inline scripts. Finding ways to inject and execute scripts can bypass CSP in such cases.
5.**Eval Bypass**: If CSP allows the use of `eval()` function or similar dynamic code execution methods, it can be exploited to bypass CSP restrictions.
Content Security Policy (CSP) is a powerful security mechanism, but like any security control, it is not foolproof. Understanding the various bypass techniques can help security researchers and developers in testing and improving the effectiveness of CSP implementations.
Vous devriez être capable d'exfiltrer des données, de la même manière que cela a toujours été fait avec [Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/). Dans ce cas, suivez ces étapes générales :
4. Sur le site cible dont vous souhaitez exfiltrer des données, vous pouvez le faire directement en utilisant le gadget SDK Facebook "fbq" via un "customEvent" et la charge utile de données.
5. Allez dans votre "Gestionnaire d'événements" de l'application et sélectionnez l'application que vous avez créée (notez que le gestionnaire d'événements peut être trouvé dans une URL similaire à ceci : https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events).
Ensuite, du côté de la victime, exécutez le code suivant pour initialiser le pixel de suivi Facebook afin de pointer vers le compte développeur Facebook de l'attaquant avec l'ID d'application et émettre un événement personnalisé comme ceci :
En plus de la redirection mentionnée pour contourner les restrictions de chemin, il existe une autre technique appelée Relative Path Overwrite (RPO) qui peut être utilisée sur certains serveurs.
Cela fonctionne car pour le navigateur, vous chargez un fichier nommé `..%2fangular%2fangular.js` situé sous `https://example.com/scripts/react/`, ce qui est conforme à la CSP.
Ainsi, il le décodera, demandant effectivement `https://example.com/scripts/react/../angular/angular.js`, ce qui est équivalent à `https://example.com/scripts/angular/angular.js`.
La solution consiste à ne pas traiter `%2f` comme `/` côté serveur, assurant une interprétation cohérente entre le navigateur et le serveur pour éviter ce problème.
Exemple en ligne : [](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)
Si la directive **base-uri** est manquante, vous pouvez en abuser pour effectuer une [**injection de balisage pendante**](../dangling-markup-html-scriptless-injection/).
De plus, si la **page charge un script en utilisant un chemin relatif** (comme `<script src="/js/app.js">`) en utilisant un **Nonce**, vous pouvez abuser de la balise **base** pour faire en sorte qu'elle **charge** le script depuis **votre propre serveur pour réaliser un XSS.**\
Une politique spécifique connue sous le nom de Content Security Policy (CSP) peut restreindre les événements JavaScript. Néanmoins, AngularJS introduit des événements personnalisés comme alternative. Dans un événement, AngularJS fournit un objet unique `$event`, faisant référence à l'objet d'événement natif du navigateur. Cet objet `$event` peut être exploité pour contourner le CSP. Notamment, dans Chrome, l'objet `$event/event` possède un attribut `path`, contenant un tableau d'objets impliqués dans la chaîne d'exécution de l'événement, l'objet `window` étant invariablement positionné à la fin. Cette structure est cruciale pour les tactiques d'évasion de bac à sable.
En dirigeant ce tableau vers le filtre `orderBy`, il est possible de le parcourir, en exploitant l'élément terminal (l'objet `window`) pour déclencher une fonction globale comme `alert()`. L'extrait de code ci-dessous illustre ce processus :
Ce extrait met en évidence l'utilisation de la directive `ng-focus` pour déclencher l'événement, en utilisant `$event.path|orderBy` pour manipuler le tableau `path`, et en tirant parti de l'objet `window` pour exécuter la fonction `alert()`, révélant ainsi `document.cookie`.
Un CSP policy qui autorise les domaines pour le chargement de scripts dans une application Angular JS peut être contourné en invoquant des fonctions de rappel et certaines classes vulnérables. Vous pouvez trouver plus d'informations sur cette technique dans un guide détaillé disponible sur ce [dépôt git](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22).
Autres points d'exécution arbitraire JSONP peuvent être trouvés [**ici**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) (certains d'entre eux ont été supprimés ou corrigés)
Que se passe-t-il lorsque CSP rencontre une redirection côté serveur ? Si la redirection mène à une origine différente qui n'est pas autorisée, elle échouera toujours.
Cependant, selon la description dans [la spécification CSP 4.2.2.3. Chemins et Redirections](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects), si la redirection mène à un chemin différent, elle peut contourner les restrictions initiales.
Cependant, le lien final `http://localhost:5555/301` sera **redirigé côté serveur vers `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`**. Comme il s'agit d'une redirection, le **chemin n'est pas pris en compte**, et le **script peut être chargé**, contournant ainsi la restriction du chemin.
Par conséquent, la meilleure solution est de s'assurer que le site web ne présente aucune vulnérabilité de redirection ouverte et qu'il n'y a pas de domaines qui peuvent être exploités dans les règles CSP.
`'unsafe-inline'` signifie que vous pouvez exécuter n'importe quel script à l'intérieur du code (XSS peut exécuter du code) et `img-src *` signifie que vous pouvez utiliser sur la page web n'importe quelle image provenant de n'importe quelle ressource.
Vous pouvez contourner ce CSP en exfiltrant les données via des images (dans ce cas, le XSS abuse d'un CSRF où une page accessible par le bot contient une injection SQL, et extrait le drapeau via une image):
De : [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
Vous pourriez également abuser de cette configuration pour **charger du code JavaScript inséré à l'intérieur d'une image**. Par exemple, si la page autorise le chargement d'images depuis Twitter. Vous pourriez **créer** une **image spéciale**, la **téléverser** sur Twitter et abuser de l'option "**unsafe-inline**" pour **exécuter** un code JS (comme un XSS classique) qui va **charger** l'**image**, **extraire** le **JS** de celle-ci et **l'exécuter** : [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
Si un **paramètre** envoyé par vous est **collé à l'intérieur** de la **déclaration** de la **politique**, alors vous pourriez **modifier** la **politique** de manière à la rendre **inutile**. Vous pourriez **autoriser le script 'unsafe-inline'** avec l'une de ces contournements :
Vous pouvez trouver un exemple ici: [http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
Dans Edge, c'est beaucoup plus simple. Si vous pouvez ajouter dans le CSP juste ceci: **`;_`** **Edge****supprimerait** l'ensemble de la **politique**.\
Cette fois, vous pouvez faire charger à la victime une page sous **votre contrôle** via **XSS** avec un `<iframe`. Cette fois, vous allez faire en sorte que la victime accède à la page à partir de laquelle vous souhaitez extraire des informations (**CSRF**). Vous ne pouvez pas accéder au contenu de la page, mais si d'une manière ou d'une autre vous pouvez **contrôler le temps nécessaire au chargement de la page**, vous pouvez extraire les informations dont vous avez besoin.
Cette fois, un **drapeau** va être extrait, chaque fois qu'un **caractère est correctement deviné** via SQLi, la **réponse** prend **plus de temps** en raison de la fonction de pause. Ensuite, vous pourrez extraire le drapeau:
```html
<!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
Cette attaque impliquerait un certain ingénierie sociale où l'attaquant **convainc l'utilisateur de faire glisser et déposer un lien sur le bookmarklet du navigateur**. Ce bookmarklet contiendrait du **code javascript malveillant** qui, lorsqu'il est glissé et déposé ou cliqué, serait exécuté dans le contexte de la fenêtre web actuelle, **contournant CSP et permettant de voler des informations sensibles** telles que des cookies ou des jetons.
Dans [**ce writeup CTF**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), CSP est contourné en injectant à l'intérieur d'un iframe autorisé un CSP plus restrictif qui interdit le chargement d'un fichier JS spécifique qui, ensuite, via la **pollution de prototype** ou le **dom clobbering** a permis d'**abuser d'un script différent pour charger un script arbitraire**.
Dans [**ce compte rendu de CTF**](https://github.com/aszx87410/ctf-writeups/issues/48), il était possible via une **injection HTML** de **restreindre** davantage un **CSP** afin qu'un script empêchant CSTI soit désactivé et donc que la **vulnérabilité devienne exploitable.**\
Le CSP peut être rendu plus restrictif en utilisant des **balises meta HTML** et les scripts en ligne peuvent être désactivés **en supprimant** l'**entrée** autorisant leur **nonce** et **en activant un script en ligne spécifique via sha**:
Si vous parvenez à faire en sorte que le serveur réponde avec l'en-tête **`Content-Security-Policy-Report-Only`** avec une **valeur contrôlée par vous** (peut-être à cause d'un CRLF), vous pourriez le faire pointer vers votre serveur et si vous **enveloppez** le **contenu JS** que vous souhaitez exfiltrer avec **`<script>`** et parce que `unsafe-inline` est très probablement interdit par le CSP, cela va **déclencher une erreur CSP** et une partie du script (contenant les informations sensibles) sera envoyée au serveur depuis `Content-Security-Policy-Report-Only`.
* Un `iframe` est créé qui pointe vers une URL (appelons-la `https://example.redirect.com`) qui est autorisée par CSP.
* Cette URL redirige ensuite vers une URL secrète (par exemple, `https://usersecret.example2.com`) qui n'est **pas autorisée** par CSP.
* En écoutant l'événement `securitypolicyviolation`, on peut capturer la propriété `blockedURI`. Cette propriété révèle le domaine de l'URI bloquée, divulguant le domaine secret vers lequel l'URL initiale a redirigé.
Il est intéressant de noter que des navigateurs comme Chrome et Firefox ont des comportements différents dans la gestion des iframes par rapport à CSP, ce qui peut entraîner une fuite potentielle d'informations sensibles en raison d'un comportement indéfini.
Une autre technique implique d'exploiter le CSP lui-même pour déduire le sous-domaine secret. Cette méthode repose sur un algorithme de recherche binaire et sur l'ajustement du CSP pour inclure des domaines spécifiques qui sont délibérément bloqués. Par exemple, si le sous-domaine secret est composé de caractères inconnus, vous pouvez tester de manière itérative différents sous-domaines en modifiant la directive CSP pour bloquer ou autoriser ces sous-domaines. Voici un extrait montrant comment le CSP pourrait être configuré pour faciliter cette méthode:
En surveillant quelles requêtes sont bloquées ou autorisées par la CSP, on peut réduire les caractères possibles dans le sous-domaine secret, finissant par découvrir l'URL complète.
Les deux méthodes exploitent les subtilités de la mise en œuvre et du comportement de la CSP dans les navigateurs, démontrant comment des politiques en apparence sécurisées peuvent involontairement divulguer des informations sensibles.
Rejoignez le serveur [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) pour communiquer avec des hackers expérimentés et des chasseurs de bugs !
PHP est connu pour **mettre en tampon la réponse à 4096** octets par défaut. Par conséquent, si PHP affiche un avertissement, en fournissant **suffisamment de données à l'intérieur des avertissements**, la **réponse** sera **envoyée****avant** l'en-tête **CSP**, ce qui entraîne l'ignorance de l'en-tête.\
D'après [**ce writeup**](https://blog.ssrf.kr/69), il semble qu'il était possible de contourner une protection CSP en chargeant une page d'erreur (potentiellement sans CSP) et en réécrivant son contenu.
QUELQUES est une technique qui abuse d'une XSS (ou d'une XSS très limitée) **dans un point de terminaison d'une page** pour **abuser****d'autres points de terminaison de la même origine.** Cela est fait en chargeant le point de terminaison vulnérable à partir d'une page d'attaquant, puis en actualisant la page de l'attaquant vers le vrai point de terminaison dans la même origine que vous souhaitez abuser. De cette manière, le **point de terminaison vulnérable** peut utiliser l'objet **`opener`** dans le **payload** pour **accéder au DOM** du **vrai point de terminaison à abuser**. Pour plus d'informations, consultez :
De plus, **wordpress** a un point de terminaison **JSONP** dans `/wp-json/wp/v2/users/1?_jsonp=data` qui va **refléter** les **données** envoyées en sortie (avec la limitation aux lettres, chiffres et points).
Un attaquant peut abuser de ce point de terminaison pour **générer une attaque QUELQUES** contre WordPress et **l'intégrer** à l'intérieur de `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` notez que ce **script** sera **chargé** car il est **autorisé par 'self'**. De plus, et parce que WordPress est installé, un attaquant pourrait abuser de l'**attaque QUELQUES** à travers le **point de terminaison de rappel****vulnérable** qui **contourne le CSP** pour donner plus de privilèges à un utilisateur, installer un nouveau plugin...\
Pour plus d'informations sur la façon de réaliser cette attaque, consultez [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)
S'il y a un CSP strict qui ne vous permet pas d'**interagir avec des serveurs externes**, il y a quelques choses que vous pouvez toujours faire pour exfiltrer l'information.
Pour charger les pages plus rapidement, les navigateurs vont pré-résoudre les noms d'hôtes en adresses IP et les mettre en cache pour une utilisation ultérieure.\
Le contournement de CSP basique peut être réalisé en utilisant des techniques telles que l'inclusion de scripts externes à partir de sources non autorisées ou en exploitant des vulnérabilités XSS réfléchies pour exécuter du code JavaScript malveillant.
Pour contourner CSP de manière plus avancée, vous pouvez explorer des techniques telles que l'utilisation de la directive `unsafe-eval` ou `unsafe-inline`, l'exploitation de rapports de violation pour recueillir des informations sur la politique CSP en place, ou encore l'utilisation de techniques de détournement de navigateur telles que l'injection de contenu via des extensions ou des modules complémentaires malveillants.
Rejoignez le serveur [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) pour communiquer avec des hackers expérimentés et des chasseurs de primes en bugs !
<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)!
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** nous sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **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) dépôts GitHub.
