Content Security Policy (CSP) Bypass
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F365789996-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FoC7kdpmNTJZIcPU2vQzG%252Fuploads%252Fgit-blob-7ebaebfa37dac753bd916c91429befb49dfd6309%252Fimage%2520%28380%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=bdfdcda4&sv=1)
Treten Sie dem HackenProof Discord Server bei, um mit erfahrenen Hackern und Bug-Bounty-Jägern zu kommunizieren!
Hacking Einblicke Engagieren Sie sich mit Inhalten, die in den Nervenkitzel und die Herausforderungen des Hackens eintauchen
Echtzeit-Hack-Nachrichten Bleiben Sie auf dem Laufenden über die schnelllebige Hackerwelt durch Echtzeitnachrichten und Einblicke
Neueste Ankündigungen Bleiben Sie informiert über die neuesten Bug-Bounties und wichtige Plattform-Updates
Treten Sie uns auf Discord bei und beginnen Sie noch heute mit den besten Hackern zusammenzuarbeiten!
Was ist CSP
Content Security Policy (CSP) wird als Browsertechnologie anerkannt, die hauptsächlich darauf abzielt, sich gegen Angriffe wie Cross-Site-Scripting (XSS) zu schützen. Es funktioniert, indem es Pfade und Quellen definiert und detailliert, von denen Ressourcen sicher vom Browser geladen werden können. Diese Ressourcen umfassen eine Reihe von Elementen wie Bilder, Frames und JavaScript. Zum Beispiel könnte eine Richtlinie das Laden und Ausführen von Ressourcen von derselben Domain (self) erlauben, einschließlich Inline-Ressourcen und die Ausführung von String-Code durch Funktionen wie eval
, setTimeout
oder setInterval
.
Die Implementierung von CSP erfolgt durch Antwort-Header oder durch die Einfügung von Meta-Elementen in die HTML-Seite. In Übereinstimmung mit dieser Richtlinie setzen Browser diese Bestimmungen proaktiv durch und blockieren sofort alle erkannten Verstöße.
Implementiert über Antwort-Header:
Implementiert über das Meta-Tag:
Headers
CSP kann mit diesen Headern durchgesetzt oder überwacht werden:
Content-Security-Policy
: Setzt die CSP durch; der Browser blockiert alle Verstöße.Content-Security-Policy-Report-Only
: Wird zur Überwachung verwendet; meldet Verstöße, ohne sie zu blockieren. Ideal für Tests in Pre-Production-Umgebungen.
Defining Resources
CSP beschränkt die Ursprünge für das Laden sowohl aktiver als auch passiver Inhalte und kontrolliert Aspekte wie die Ausführung von Inline-JavaScript und die Verwendung von eval()
. Ein Beispiel für eine Richtlinie ist:
Direktiven
script-src: Erlaubt spezifische Quellen für JavaScript, einschließlich URLs, Inline-Skripte und Skripte, die durch Ereignis-Handler oder XSLT-Stylesheets ausgelöst werden.
default-src: Legt eine Standardrichtlinie für das Abrufen von Ressourcen fest, wenn spezifische Abrufrichtlinien fehlen.
child-src: Gibt erlaubte Ressourcen für Web-Worker und eingebettete Frame-Inhalte an.
connect-src: Beschränkt URLs, die mit Schnittstellen wie fetch, WebSocket, XMLHttpRequest geladen werden können.
frame-src: Beschränkt URLs für Frames.
frame-ancestors: Gibt an, welche Quellen die aktuelle Seite einbetten können, anwendbar auf Elemente wie
<frame>
,<iframe>
,<object>
,<embed>
und<applet>
.img-src: Definiert erlaubte Quellen für Bilder.
font-src: Gibt gültige Quellen für Schriftarten an, die mit
@font-face
geladen werden.manifest-src: Definiert erlaubte Quellen für Anwendungsmanifestdateien.
media-src: Definiert erlaubte Quellen für das Laden von Medienobjekten.
object-src: Definiert erlaubte Quellen für
<object>
,<embed>
und<applet>
-Elemente.base-uri: Gibt erlaubte URLs für das Laden mit
<base>
-Elementen an.form-action: Listet gültige Endpunkte für Formularübermittlungen auf.
plugin-types: Beschränkt MIME-Typen, die eine Seite aufrufen kann.
upgrade-insecure-requests: Weist Browser an, HTTP-URLs in HTTPS umzuschreiben.
sandbox: Wendet Einschränkungen an, die ähnlich wie das Sandbox-Attribut eines
<iframe>
sind.report-to: Gibt eine Gruppe an, an die ein Bericht gesendet wird, wenn die Richtlinie verletzt wird.
worker-src: Gibt gültige Quellen für Worker-, SharedWorker- oder ServiceWorker-Skripte an.
prefetch-src: Gibt gültige Quellen für Ressourcen an, die abgerufen oder vorab abgerufen werden.
navigate-to: Beschränkt die URLs, zu denen ein Dokument auf beliebige Weise navigieren kann (a, Formular, window.location, window.open usw.)
Quellen
*
: Erlaubt alle URLs, außer denen mitdata:
,blob:
,filesystem:
-Schemas.'self'
: Erlaubt das Laden von derselben Domain.'data'
: Erlaubt das Laden von Ressourcen über das Daten-Schema (z. B. Base64-kodierte Bilder).'none'
: Blockiert das Laden von jeder Quelle.'unsafe-eval'
: Erlaubt die Verwendung voneval()
und ähnlichen Methoden, aus Sicherheitsgründen nicht empfohlen.'unsafe-hashes'
: Ermöglicht spezifische Inline-Ereignis-Handler.'unsafe-inline'
: Erlaubt die Verwendung von Inline-Ressourcen wie Inline-<script>
oder<style>
, aus Sicherheitsgründen nicht empfohlen.'nonce'
: Eine Whitelist für spezifische Inline-Skripte unter Verwendung eines kryptografischen Nonce (einmal verwendete Zahl).Wenn Sie eine eingeschränkte Ausführung von JS haben, ist es möglich, einen verwendeten Nonce innerhalb der Seite mit
doc.defaultView.top.document.querySelector("[nonce]")
zu erhalten und ihn dann wiederzuverwenden, um ein bösartiges Skript zu laden (wenn strict-dynamic verwendet wird, kann jede erlaubte Quelle neue Quellen laden, sodass dies nicht erforderlich ist), wie in:
'sha256-<hash>'
: Whitelistet Skripte mit einem spezifischen sha256-Hash.'strict-dynamic'
: Erlaubt das Laden von Skripten aus jeder Quelle, wenn sie durch ein nonce oder einen Hash whitelisted wurde.'host'
: Gibt einen spezifischen Host an, wieexample.com
.https:
: Beschränkt URLs auf solche, die HTTPS verwenden.blob:
: Erlaubt das Laden von Ressourcen von Blob-URLs (z.B. Blob-URLs, die über JavaScript erstellt wurden).filesystem:
: Erlaubt das Laden von Ressourcen vom Dateisystem.'report-sample'
: Beinhaltet ein Beispiel des verletzenden Codes im Verletzungsbericht (nützlich für das Debugging).'strict-origin'
: Ähnlich wie 'self', stellt jedoch sicher, dass das Sicherheitsniveau des Protokolls der Quellen mit dem Dokument übereinstimmt (nur sichere Ursprünge können Ressourcen von sicheren Ursprüngen laden).'strict-origin-when-cross-origin'
: Sendet vollständige URLs bei Anfragen mit demselben Ursprung, sendet jedoch nur den Ursprung, wenn die Anfrage cross-origin ist.'unsafe-allow-redirects'
: Erlaubt das Laden von Ressourcen, die sofort zu einer anderen Ressource umleiten. Nicht empfohlen, da es die Sicherheit schwächt.
Unsichere CSP-Regeln
'unsafe-inline'
Working payload: "/><script>alert(1);</script>
self + 'unsafe-inline' über Iframes
CSP bypass: self + 'unsafe-inline' with Iframes'unsafe-eval'
Das funktioniert nicht, für mehr Informationen hier überprüfen.
Funktionierender Payload:
strict-dynamic
Wenn Sie es irgendwie schaffen können, dass ein erlaubter JS-Code ein neues Skript-Tag im DOM mit Ihrem JS-Code erstellt, weil ein erlaubtes Skript es erstellt, wird das neue Skript-Tag erlaubt sein, ausgeführt zu werden.
Wildcard (*)
Funktionierender Payload:
Fehlende object-src und default-src
Es scheint, dass dies nicht mehr funktioniert
Funktionierende Payloads:
Datei-Upload + 'self'
Wenn Sie eine JS-Datei hochladen können, können Sie diese CSP umgehen:
Funktionierender Payload:
Es ist jedoch sehr wahrscheinlich, dass der Server die hochgeladene Datei validiert und nur bestimmte Dateitypen erlaubt.
Darüber hinaus, selbst wenn Sie einen JS-Code in einer Datei mit einer vom Server akzeptierten Erweiterung (wie: script.png) hochladen könnten, wäre das nicht genug, da einige Server wie der Apache-Server den MIME-Typ der Datei basierend auf der Erweiterung auswählen und Browser wie Chrome Javascript-Code in etwas, das ein Bild sein sollte, nicht ausführen. "Hoffentlich" gibt es Fehler. Zum Beispiel habe ich von einem CTF gelernt, dass Apache nicht weiß, was die .wave-Erweiterung ist, daher wird sie nicht mit einem MIME-Typ wie audio/ bedient.
Von hier aus, wenn Sie ein XSS und einen Datei-Upload finden und es Ihnen gelingt, eine missverstandene Erweiterung zu finden, könnten Sie versuchen, eine Datei mit dieser Erweiterung und dem Inhalt des Skripts hochzuladen. Oder, wenn der Server das korrekte Format der hochgeladenen Datei überprüft, erstellen Sie ein Polyglot (einige Polyglot-Beispiele hier).
Form-action
Wenn es nicht möglich ist, JS zu injizieren, könnten Sie immer noch versuchen, beispielsweise Anmeldeinformationen durch das Injizieren einer Formularaktion zu exfiltrieren (und vielleicht erwarten, dass Passwortmanager Passwörter automatisch ausfüllen). Sie finden ein Beispiel in diesem Bericht. Beachten Sie auch, dass default-src
keine Formularaktionen abdeckt.
Third Party Endpoints + ('unsafe-eval')
Für einige der folgenden Payloads wird unsafe-eval
nicht einmal benötigt.
Laden Sie eine verwundbare Version von Angular und führen Sie beliebigen JS aus:
Payloads unter Verwendung von Angular + einer Bibliothek mit Funktionen, die das window
-Objekt zurückgeben (schau dir diesen Beitrag an):
window
-Objekt zurückgeben (schau dir diesen Beitrag an):Der Beitrag zeigt, dass du alle Bibliotheken von cdn.cloudflare.com
(oder einem anderen erlaubten JS-Bibliotheks-Repo) laden, alle hinzugefügten Funktionen aus jeder Bibliothek ausführen und überprüfen kannst, welche Funktionen aus welchen Bibliotheken das window
-Objekt zurückgeben.
Angular XSS von einem Klassennamen:
Missbrauch des Google reCAPTCHA JS-Codes
Laut diesem CTF-Bericht können Sie https://www.google.com/recaptcha/ innerhalb einer CSP missbrauchen, um beliebigen JS-Code auszuführen und die CSP zu umgehen:
Mehr Payloads aus diesem Bericht:
Missbrauch von www.google.com für offene Weiterleitungen
Die folgende URL leitet zu example.com weiter (von hier):
Abusing *.google.com/script.google.com
Es ist möglich, Google Apps Script zu missbrauchen, um Informationen auf einer Seite innerhalb von script.google.com zu erhalten. Wie es in diesem Bericht gemacht wird.
Third Party Endpoints + JSONP
Szenarien wie dieses, in denen script-src
auf self
und eine bestimmte, auf die Whitelist gesetzte Domain eingestellt ist, können mit JSONP umgangen werden. JSONP-Endpunkte erlauben unsichere Callback-Methoden, die es einem Angreifer ermöglichen, XSS durchzuführen, funktionierender Payload:
JSONBee enthält einsatzbereite JSONP-Endpunkte zum Umgehen der CSP verschiedener Websites.
Die gleiche Schwachstelle tritt auf, wenn der vertrauenswürdige Endpunkt eine Open Redirect enthält, da, wenn der ursprüngliche Endpunkt vertrauenswürdig ist, auch Weiterleitungen vertrauenswürdig sind.
Missbrauch durch Dritte
Wie im folgenden Beitrag beschrieben, gibt es viele Drittanbieter-Domains, die irgendwo in der CSP erlaubt sein könnten und missbraucht werden können, um entweder Daten zu exfiltrieren oder JavaScript-Code auszuführen. Einige dieser Drittanbieter sind:
Entity | Erlaubte Domain | Fähigkeiten |
---|---|---|
www.facebook.com, *.facebook.com | Exfil | |
Hotjar | *.hotjar.com, ask.hotjar.io | Exfil |
Jsdelivr | *.jsdelivr.com, cdn.jsdelivr.net | Exec |
Amazon CloudFront | *.cloudfront.net | Exfil, Exec |
Amazon AWS | *.amazonaws.com | Exfil, Exec |
Azure Websites | *.azurewebsites.net, *.azurestaticapps.net | Exfil, Exec |
Salesforce Heroku | *.herokuapp.com | Exfil, Exec |
Google Firebase | *.firebaseapp.com | Exfil, Exec |
Wenn Sie eine der erlaubten Domains in der CSP Ihres Ziels finden, besteht die Möglichkeit, dass Sie die CSP umgehen können, indem Sie sich bei dem Drittanbieterdienst registrieren und entweder Daten an diesen Dienst exfiltrieren oder Code ausführen.
Zum Beispiel, wenn Sie die folgende CSP finden:
oder
Sie sollten in der Lage sein, Daten zu exfiltrieren, ähnlich wie es immer mit Google Analytics/Google Tag Manager gemacht wurde. In diesem Fall folgen Sie diesen allgemeinen Schritten:
Erstellen Sie hier ein Facebook-Entwicklerkonto.
Erstellen Sie eine neue "Facebook Login"-App und wählen Sie "Website".
Gehen Sie zu "Einstellungen -> Grundlegend" und holen Sie sich Ihre "App-ID".
Auf der Zielseite, von der Sie Daten exfiltrieren möchten, können Sie Daten direkt über das Facebook SDK-Gadget "fbq" durch ein "customEvent" und die Datenlast exfiltrieren.
Gehen Sie zu Ihrem App "Event Manager" und wählen Sie die von Ihnen erstellte Anwendung aus (beachten Sie, dass der Event-Manager in einer URL zu finden sein könnte, die ähnlich aussieht wie: https://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events).
Wählen Sie die Registerkarte "Testereignisse", um die von "Ihrer" Website gesendeten Ereignisse zu sehen.
Führen Sie dann auf der Seite des Opfers den folgenden Code aus, um das Facebook-Tracking-Pixel zu initialisieren, das auf die App-ID des Facebook-Entwicklerkontos des Angreifers zeigt, und um ein benutzerdefiniertes Ereignis wie folgt auszulösen:
Was die anderen sieben Drittanbieter-Domains betrifft, die in der vorherigen Tabelle angegeben sind, gibt es viele weitere Möglichkeiten, wie Sie diese missbrauchen können. Verweisen Sie auf den vorherigen Blogbeitrag für zusätzliche Erklärungen zu anderen Drittanbieter-Missbräuchen.
Bypass via RPO (Relative Path Overwrite)
Neben der oben genannten Umleitung, um Pfadbeschränkungen zu umgehen, gibt es eine weitere Technik namens Relative Path Overwrite (RPO), die auf einigen Servern verwendet werden kann.
Wenn CSP beispielsweise den Pfad https://example.com/scripts/react/
zulässt, kann er wie folgt umgangen werden:
Der Browser wird letztendlich https://example.com/scripts/angular/angular.js
laden.
Dies funktioniert, weil der Browser eine Datei mit dem Namen ..%2fangular%2fangular.js
lädt, die sich unter https://example.com/scripts/react/
befindet, was mit CSP konform ist.
∑, sie werden es dekodieren und effektiv https://example.com/scripts/react/../angular/angular.js
anfordern, was gleichwertig ist mit https://example.com/scripts/angular/angular.js
.
Durch Ausnutzung dieser Inkonsistenz in der URL-Interpretation zwischen dem Browser und dem Server können die Pfadregeln umgangen werden.
Die Lösung besteht darin, %2f
auf der Serverseite nicht als /
zu behandeln, um eine konsistente Interpretation zwischen dem Browser und dem Server sicherzustellen und dieses Problem zu vermeiden.
Online-Beispiel: https://jsbin.com/werevijewa/edit?html,output
Iframes JS-Ausführung
Iframes in XSS, CSP and SOPfehlende base-uri
Wenn die base-uri-Richtlinie fehlt, können Sie dies ausnutzen, um eine dangling markup injection durchzuführen.
Darüber hinaus, wenn die Seite ein Skript mit einem relativen Pfad lädt (wie <script src="/js/app.js">
) unter Verwendung eines Nonce, können Sie den base tag ausnutzen, um das Skript von Ihrem eigenen Server zu laden und eine XSS zu erreichen.
Wenn die anfällige Seite mit httpS geladen wird, verwenden Sie eine httpS-URL im Basis-Tag.
AngularJS-Ereignisse
Eine spezifische Richtlinie, bekannt als Content Security Policy (CSP), kann JavaScript-Ereignisse einschränken. Dennoch führt AngularJS benutzerdefinierte Ereignisse als Alternative ein. Innerhalb eines Ereignisses stellt AngularJS ein einzigartiges Objekt $event
zur Verfügung, das auf das native Browser-Ereignisobjekt verweist. Dieses $event
-Objekt kann ausgenutzt werden, um die CSP zu umgehen. Bemerkenswerterweise besitzt das $event/event
-Objekt in Chrome ein path
-Attribut, das ein Objektarray enthält, das in der Ausführungskette des Ereignisses beteiligt ist, wobei das window
-Objekt stets am Ende positioniert ist. Diese Struktur ist entscheidend für Sandbox-Umgehungstaktiken.
Indem dieses Array an den orderBy
-Filter weitergeleitet wird, ist es möglich, über es zu iterieren und das terminale Element (das window
-Objekt) zu nutzen, um eine globale Funktion wie alert()
auszulösen. Der unten demonstrierte Codeausschnitt verdeutlicht diesen Prozess:
Dieser Snippet hebt die Verwendung der ng-focus
-Direktive hervor, um das Ereignis auszulösen, wobei $event.path|orderBy
verwendet wird, um das path
-Array zu manipulieren, und das window
-Objekt genutzt wird, um die alert()
-Funktion auszuführen, wodurch document.cookie
offengelegt wird.
Finde andere Angular-Bypässe in https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
AngularJS und whitelisted Domain
Eine CSP-Richtlinie, die Domains für das Laden von Skripten in einer Angular JS-Anwendung auf die Whitelist setzt, kann durch die Ausführung von Callback-Funktionen und bestimmten anfälligen Klassen umgangen werden. Weitere Informationen zu dieser Technik finden Sie in einem detaillierten Leitfaden, der in diesem git repository verfügbar ist.
Funktionierende Payloads:
Andere JSONP beliebige Ausführung Endpunkte können hier gefunden werden (einige von ihnen wurden gelöscht oder behoben)
Umgehung durch Umleitung
Was passiert, wenn CSP auf serverseitige Umleitungen trifft? Wenn die Umleitung zu einem anderen Ursprung führt, der nicht erlaubt ist, wird sie dennoch fehlschlagen.
Laut der Beschreibung in CSP spec 4.2.2.3. Pfade und Umleitungen kann die Umleitung, wenn sie zu einem anderen Pfad führt, die ursprünglichen Einschränkungen umgehen.
Hier ist ein Beispiel:
Wenn CSP auf https://www.google.com/a/b/c/d
gesetzt ist, werden sowohl die Skripte /test
als auch /a/test
von CSP blockiert.
Die endgültige http://localhost:5555/301
wird jedoch serverseitig auf https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//
umgeleitet. Da es sich um eine Umleitung handelt, wird der Pfad nicht berücksichtigt, und das Skript kann geladen werden, wodurch die Pfadbeschränkung umgangen wird.
Mit dieser Umleitung wird selbst dann, wenn der Pfad vollständig angegeben ist, weiterhin umgangen.
Daher ist die beste Lösung, sicherzustellen, dass die Website keine offenen Umleitungsanfälligkeiten hat und dass es keine Domains gibt, die in den CSP-Regeln ausgenutzt werden können.
Bypass CSP mit schwebendem Markup
Lies wie hier.
'unsafe-inline'; img-src *; über XSS
'unsafe-inline'
bedeutet, dass Sie jeden Skript im Code ausführen können (XSS kann Code ausführen) und img-src *
bedeutet, dass Sie auf der Webseite jedes Bild aus jeder Quelle verwenden können.
Sie können diese CSP umgehen, indem Sie die Daten über Bilder exfiltrieren (in diesem Fall missbraucht das XSS eine CSRF, bei der eine vom Bot zugängliche Seite eine SQLi enthält, und extrahiert das Flag über ein Bild):
From: https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle
Sie könnten auch diese Konfiguration missbrauchen, um JavaScript-Code, der in ein Bild eingefügt ist, zu laden. Wenn die Seite beispielsweise das Laden von Bildern von Twitter erlaubt. Sie könnten ein spezielles Bild erstellen, es auf Twitter hochladen und die "unsafe-inline" ausnutzen, um einen JS-Code (wie bei einem regulären XSS) auszuführen, der das Bild lädt, den JS daraus extrahiert und ausführt: https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/
Mit Service Workern
Die Funktion importScripts
von Service Workern ist nicht durch CSP eingeschränkt:
Policy Injection
Forschung: https://portswigger.net/research/bypassing-csp-with-policy-injection
Chrome
Wenn ein Parameter, der von Ihnen gesendet wird, in die Deklaration der Richtlinie eingefügt wird, könnten Sie die Richtlinie auf eine Weise ändern, die sie nutzlos macht. Sie könnten Script 'unsafe-inline' mit einem dieser Umgehungen erlauben:
Weil diese Direktive bestehende script-src-Direktiven überschreibt. Ein Beispiel finden Sie hier: 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
In Edge ist es viel einfacher. Wenn Sie in der CSP nur dies hinzufügen können: ;_
Edge würde die gesamte Richtlinie fallen lassen.
Beispiel: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E
img-src *; via XSS (iframe) - Zeitangriff
Beachten Sie das Fehlen der Direktive 'unsafe-inline'
Diesmal können Sie das Opfer dazu bringen, eine Seite in Ihrer Kontrolle über XSS mit einem <iframe
zu laden. Diesmal werden Sie das Opfer dazu bringen, auf die Seite zuzugreifen, von der Sie Informationen extrahieren möchten (CSRF). Sie können nicht auf den Inhalt der Seite zugreifen, aber wenn Sie irgendwie die Zeit kontrollieren können, die die Seite zum Laden benötigt, können Sie die Informationen extrahieren, die Sie benötigen.
Diesmal wird eine Flagge extrahiert, wann immer ein Zeichen korrekt erraten wird. Über SQLi benötigt die Antwort mehr Zeit aufgrund der Schlaf-Funktion. Dann werden Sie in der Lage sein, die Flagge zu extrahieren:
Via Bookmarklets
Dieser Angriff würde einige soziale Ingenieurkunst erfordern, bei der der Angreifer den Benutzer überzeugt, einen Link über das Lesezeichen des Browsers zu ziehen und abzulegen. Dieses Lesezeichen würde bösartigen JavaScript-Code enthalten, der beim Ziehen und Ablegen oder Klicken im Kontext des aktuellen Webfensters ausgeführt wird, CSP umgeht und es ermöglicht, sensible Informationen wie Cookies oder Tokens zu stehlen.
Für weitere Informationen prüfen Sie den ursprünglichen Bericht hier.
CSP-Bypass durch Einschränkung von CSP
In diesem CTF-Bericht wird CSP umgangen, indem in ein erlaubtes iframe eine restriktivere CSP injiziert wird, die das Laden einer bestimmten JS-Datei verbietet, die dann über Prototype Pollution oder DOM Clobbering es ermöglichte, ein anderes Skript zu missbrauchen, um ein beliebiges Skript zu laden.
Sie können eine CSP eines Iframes mit dem csp
-Attribut einschränken:
In diesem CTF-Bericht war es möglich, über HTML-Injection eine CSP weiter zu beschränken, sodass ein Skript, das CSTI verhinderte, deaktiviert wurde und daher die Schwachstelle ausnutzbar wurde. CSP kann restriktiver gestaltet werden, indem HTML-Meta-Tags verwendet werden und Inline-Skripte können deaktiviert werden, indem der Eintrag entfernt wird, der ihren Nonce zulässt, und spezifische Inline-Skripte über sha aktiviert werden:
JS-Exfiltration mit Content-Security-Policy-Report-Only
Wenn es dir gelingt, den Server dazu zu bringen, mit dem Header Content-Security-Policy-Report-Only
zu antworten, der einen von dir kontrollierten Wert hat (vielleicht wegen eines CRLF), könntest du ihn auf deinen Server verweisen lassen und wenn du den JS-Inhalt, den du exfiltrieren möchtest, mit <script>
umschließt und da höchstwahrscheinlich unsafe-inline
von der CSP nicht erlaubt ist, wird dies einen CSP-Fehler auslösen und ein Teil des Skripts (das die sensiblen Informationen enthält) wird vom Content-Security-Policy-Report-Only
an den Server gesendet.
Für ein Beispiel siehe diesen CTF-Bericht.
Leaking Information with CSP and Iframe
Ein
iframe
wird erstellt, der auf eine URL zeigt (nennen wir siehttps://example.redirect.com
), die von CSP erlaubt ist.Diese URL leitet dann zu einer geheimen URL weiter (z. B.
https://usersecret.example2.com
), die nicht erlaubt ist von CSP.Durch das Abhören des
securitypolicyviolation
-Ereignisses kann man dieblockedURI
-Eigenschaft erfassen. Diese Eigenschaft offenbart die Domain der blockierten URI und leakt die geheime Domain, zu der die ursprüngliche URL weitergeleitet wurde.
Es ist interessant zu beachten, dass Browser wie Chrome und Firefox unterschiedliche Verhaltensweisen im Umgang mit iframes in Bezug auf CSP haben, was zu potenziellem Leck von sensiblen Informationen aufgrund undefinierten Verhaltens führen kann.
Eine weitere Technik besteht darin, die CSP selbst auszunutzen, um die geheime Subdomain abzuleiten. Diese Methode basiert auf einem binären Suchalgorithmus und der Anpassung der CSP, um spezifische Domains einzuschließen, die absichtlich blockiert sind. Wenn die geheime Subdomain aus unbekannten Zeichen besteht, kann man iterativ verschiedene Subdomains testen, indem man die CSP-Direktive ändert, um diese Subdomains zu blockieren oder zuzulassen. Hier ist ein Snippet, das zeigt, wie die CSP eingerichtet werden könnte, um diese Methode zu erleichtern:
Durch die Überwachung, welche Anfragen von der CSP blockiert oder erlaubt werden, kann man die möglichen Zeichen im geheimen Subdomain eingrenzen und schließlich die vollständige URL aufdecken.
Beide Methoden nutzen die Nuancen der CSP-Implementierung und -Verhalten in Browsern aus und zeigen, wie scheinbar sichere Richtlinien versehentlich sensible Informationen preisgeben können.
Trick von hier.
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F365789996-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FoC7kdpmNTJZIcPU2vQzG%252Fuploads%252Fgit-blob-7ebaebfa37dac753bd916c91429befb49dfd6309%252Fimage%2520%28380%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=bdfdcda4&sv=1)
Tritt dem HackenProof Discord Server bei, um mit erfahrenen Hackern und Bug-Bounty-Jägern zu kommunizieren!
Hacking Insights Engagieren Sie sich mit Inhalten, die in die Aufregung und Herausforderungen des Hackens eintauchen
Echtzeit-Hack-Nachrichten Bleiben Sie auf dem Laufenden mit der schnelllebigen Hack-Welt durch Echtzeit-Nachrichten und Einblicke
Neueste Ankündigungen Bleiben Sie informiert über die neuesten Bug-Bounties, die gestartet werden, und wichtige Plattform-Updates
Treten Sie uns bei Discord und beginnen Sie noch heute mit den besten Hackern zusammenzuarbeiten!
Unsichere Technologien zum Umgehen von CSP
PHP-Fehler bei zu vielen Parametern
Laut der letzten Technik, die in diesem Video kommentiert wurde, führt das Senden von zu vielen Parametern (1001 GET-Parameter, obwohl man es auch mit POST-Parametern und mehr als 20 Dateien tun kann) dazu, dass jeder definierte header()
im PHP-Webcode nicht gesendet wird, aufgrund des Fehlers, den dies auslösen wird.
PHP-Antwortpufferüberlastung
PHP ist bekannt dafür, die Antwort standardmäßig auf 4096 Bytes zu puffern. Daher, wenn PHP eine Warnung anzeigt, wird die Antwort gesendet, bevor der CSP-Header gesendet wird, was dazu führt, dass der Header ignoriert wird. Die Technik besteht dann im Wesentlichen darin, den Antwortpuffer mit Warnungen zu füllen, sodass der CSP-Header nicht gesendet wird.
Idee von diesem Writeup.
Fehlerseite umschreiben
Laut diesem Writeup scheint es möglich gewesen zu sein, einen CSP-Schutz zu umgehen, indem eine Fehlerseite (möglicherweise ohne CSP) geladen und deren Inhalt umgeschrieben wurde.
SOME + 'self' + wordpress
SOME ist eine Technik, die ein XSS (oder stark eingeschränktes XSS) in einem Endpunkt einer Seite ausnutzt, um andere Endpunkte derselben Herkunft zu missbrauchen. Dies geschieht, indem der anfällige Endpunkt von einer Angreiferseite geladen und dann die Angreiferseite auf den echten Endpunkt derselben Herkunft, den man missbrauchen möchte, aktualisiert wird. Auf diese Weise kann der anfällige Endpunkt das opener
-Objekt im Payload verwenden, um auf das DOM des echten Endpunkts, den man missbrauchen möchte, zuzugreifen. Für weitere Informationen siehe:
Darüber hinaus hat wordpress einen JSONP-Endpunkt in /wp-json/wp/v2/users/1?_jsonp=data
, der die Daten im Output reflektiert (mit der Einschränkung auf Buchstaben, Zahlen und Punkte).
Ein Angreifer kann diesen Endpunkt ausnutzen, um einen SOME-Angriff gegen WordPress zu generieren und ihn in <script s
rc=/wp-json/wp/v2/users/1?_jsonp=some_attack></script>
einzubetten. Beachte, dass dieses Script geladen wird, weil es von 'self' erlaubt ist. Darüber hinaus, und weil WordPress installiert ist, könnte ein Angreifer den SOME-Angriff über den anfälligen Callback-Endpunkt ausnutzen, der die CSP umgeht, um einem Benutzer mehr Privilegien zu geben, ein neues Plugin zu installieren...
Für weitere Informationen darüber, wie man diesen Angriff durchführt, siehe https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/
CSP Exfiltration Bypasses
Wenn es eine strenge CSP gibt, die es dir nicht erlaubt, mit externen Servern zu interagieren, gibt es einige Dinge, die du immer tun kannst, um die Informationen zu exfiltrieren.
Location
Du könntest einfach die Location aktualisieren, um die geheimen Informationen an den Server des Angreifers zu senden:
Meta-Tag
Sie könnten umleiten, indem Sie einen Meta-Tag injizieren (dies ist nur eine Umleitung, dies wird keinen Inhalt leaken)
DNS Prefetch
Um Seiten schneller zu laden, werden Browser Hostnamen in IP-Adressen vorauflösen und sie für die spätere Verwendung zwischenspeichern.
Sie können einen Browser anweisen, einen Hostnamen vorab aufzulösen mit: <link rel="dns-prefetch" href="something.com">
Sie könnten dieses Verhalten missbrauchen, um sensible Informationen über DNS-Anfragen zu exfiltrieren:
Eine andere Möglichkeit:
Um dies zu vermeiden, kann der Server den HTTP-Header senden:
Offensichtlich funktioniert diese Technik nicht in headless-Browsern (Bots)
WebRTC
Auf mehreren Seiten kann man lesen, dass WebRTC die connect-src
-Richtlinie der CSP nicht überprüft.
Tatsächlich kann man Informationen mit einer DNS-Anfrage leaken. Schau dir diesen Code an:
Eine weitere Option:
Überprüfung von CSP-Richtlinien online
Automatisches Erstellen von CSP
https://csper.io/docs/generating-content-security-policy
Referenzen
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F365789996-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FoC7kdpmNTJZIcPU2vQzG%252Fuploads%252Fgit-blob-7ebaebfa37dac753bd916c91429befb49dfd6309%252Fimage%2520%28380%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=bdfdcda4&sv=1)
Tritt dem HackenProof Discord Server bei, um mit erfahrenen Hackern und Bug-Bounty-Jägern zu kommunizieren!
Hacking Einblicke Engagiere dich mit Inhalten, die in den Nervenkitzel und die Herausforderungen des Hackens eintauchen
Echtzeit-Hack-Nachrichten Bleibe auf dem Laufenden über die schnelllebige Welt des Hackens durch Echtzeitnachrichten und Einblicke
Neueste Ankündigungen Bleibe informiert über die neuesten Bug-Bounties und wichtige Plattform-Updates
Tritt uns bei Discord und beginne noch heute mit den besten Hackern zusammenzuarbeiten!
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lerne & übe GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated