Content Security Policy (CSP) Bypass
Treten Sie dem HackenProof Discord Server bei, um mit erfahrenen Hackern und Bug-Bounty-Jägern zu kommunizieren!
Hacking-Einblicke Beschäftigen Sie sich mit Inhalten, die sich mit dem Nervenkitzel und den Herausforderungen des Hackens befassen
Echtzeit-Hack-News Bleiben Sie mit der schnelllebigen Hacking-Welt durch Echtzeitnachrichten und Einblicke auf dem Laufenden
Neueste Ankündigungen Bleiben Sie über die neuesten Bug-Bounties und wichtigen Plattformupdates informiert
Treten Sie uns bei Discord und beginnen Sie noch heute mit der Zusammenarbeit mit Top-Hackern!
Was ist CSP
Content-Security-Policy (CSP) wird als Browser-Technologie anerkannt, die hauptsächlich darauf abzielt, Angriffe wie Cross-Site-Scripting (XSS) abzuschirmen. Sie funktioniert, indem Pfade und Quellen definiert und detailliert werden, aus denen Ressourcen sicher vom Browser geladen werden können. Diese Ressourcen umfassen eine Vielzahl von Elementen wie Bilder, Frames und JavaScript. Beispielsweise könnte eine Richtlinie das Laden und Ausführen von Ressourcen von der gleichen Domäne (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 über Antwortheader oder durch das Einbinden von Meta-Elementen in die HTML-Seite. Nach dieser Richtlinie setzen Browser diese Bestimmungen proaktiv durch und blockieren sofort alle festgestellten Verstöße.
Implementiert über Antwortheader:
Implementiert über Meta-Tag:
Überschriften
CSP kann mithilfe dieser Header durchgesetzt oder überwacht werden:
Content-Security-Policy
: Setzt die CSP durch; der Browser blockiert Verstöße.Content-Security-Policy-Report-Only
: Wird zur Überwachung verwendet; meldet Verstöße, ohne sie zu blockieren. Ideal für Tests in Vorproduktionsumgebungen.
Definieren von Ressourcen
CSP beschränkt die Ursprünge für das Laden von aktiven und passiven Inhalten und steuert 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 Ereignisbehandler oder XSLT-Stylesheets ausgelöst werden.
default-src: Legt eine Standardrichtlinie für das Abrufen von Ressourcen fest, wenn spezifische Abrufanweisungen fehlen.
child-src: Legt erlaubte Ressourcen für Web-Worker und eingebettete Frame-Inhalte fest.
connect-src: Beschränkt URLs, die über Schnittstellen wie fetch, WebSocket, XMLHttpRequest geladen werden können.
frame-src: Beschränkt URLs für Frames.
frame-ancestors: Legt fest, welche Quellen die aktuelle Seite einbetten können, gilt für Elemente wie
<frame>
,<iframe>
,<object>
,<embed>
und<applet>
.img-src: Definiert erlaubte Quellen für Bilder.
font-src: Legt gültige Quellen für über
@font-face
geladene Schriftarten fest.manifest-src: Definiert erlaubte Quellen von Anwendungsmanifestdateien.
media-src: Definiert erlaubte Quellen für das Laden von Mediendateien.
object-src: Definiert erlaubte Quellen für
<object>
,<embed>
und<applet>
-Elemente.base-uri: Legt erlaubte URLs für das Laden mit
<base>
-Elementen fest.form-action: Listet gültige Endpunkte für Formularübermittlungen auf.
plugin-types: Beschränkt die MIME-Typen, die eine Seite aufrufen darf.
upgrade-insecure-requests: Weist Browser an, HTTP-URLs in HTTPS umzuschreiben.
sandbox: Wendet Einschränkungen ähnlich wie das sandbox-Attribut eines
<iframe>
an.report-to: Legt eine Gruppe fest, an die ein Bericht gesendet wird, wenn die Richtlinie verletzt wird.
worker-src: Legt gültige Quellen für Worker-, SharedWorker- oder ServiceWorker-Skripte fest.
prefetch-src: Legt gültige Quellen für Ressourcen fest, die abgerufen oder vorabgerufen werden.
navigate-to: Beschränkt die URLs, zu denen ein Dokument auf beliebige Weise navigieren kann (a, form, window.location, window.open usw.).
Quellen
*
: Erlaubt alle URLs außer denen mit den Schemasdata:
,blob:
,filesystem:
.'self'
: Erlaubt das Laden von der gleichen Domain.'data'
: Erlaubt das Laden von Ressourcen über das Daten-Schema (z. B. Base64-codierte 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-Ereignishandler.'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 Nummer).Wenn die JS-Ausführung eingeschränkt ist, 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, daher ist dies nicht erforderlich), wie in:
'sha256-<hash>'
: Whitelists Skripte mit einem spezifischen sha256-Hash.'strict-dynamic'
: Ermöglicht das Laden von Skripten aus jeder Quelle, wenn sie von einem Nonce oder Hash freigegeben wurden.'host'
: Gibt einen spezifischen Host an, wie z. B.example.com
.https:
: Beschränkt URLs auf die Verwendung von HTTPS.blob:
: Ermöglicht das Laden von Ressourcen aus Blob-URLs (z. B. Blob-URLs, die über JavaScript erstellt wurden).filesystem:
: Ermöglicht das Laden von Ressourcen aus dem Dateisystem.'report-sample'
: Enthält eine Probe des verletzenden Codes im Verstoßbericht (nützlich für die Fehlersuche).'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 der Durchführung von Anfragen mit demselben Ursprung, sendet jedoch nur den Ursprung, wenn die Anfrage kreuzursprünglich ist.'unsafe-allow-redirects'
: Ermöglicht das Laden von Ressourcen, die sofort zu einer anderen Ressource umgeleitet werden. Nicht empfohlen, da dies die Sicherheit beeinträchtigt.
Unsichere CSP-Regeln
'unsafe-inline'
Arbeitslast: "/><script>alert(1);</script>
self + 'unsafe-inline' über Iframes
pageCSP bypass: self + 'unsafe-inline' with Iframes'unsafe-eval'
Dies funktioniert nicht, für weitere Informationen überprüfen Sie dies.
Arbeitslast:
strict-dynamic
Wenn Sie auf irgendeine Weise zulässigen JS-Code erstellen können, der ein neues Skript-Tag im DOM mit Ihrem JS-Code erstellt, wird das neue Skript-Tag aufgrund des zulässigen Skripts ausgeführt.
Wildcard (*)
Arbeitslast:
Fehlen von 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 dieses CSP umgehen:
Arbeitslast:
Jedoch ist es sehr wahrscheinlich, dass der Server die hochgeladene Datei validiert und nur das Hochladen eines bestimmten Dateityps zulässt.
Darüber hinaus, selbst wenn Sie einen JS-Code innerhalb einer Datei hochladen könnten, die von dem Server akzeptiert wird (z. B. script.png), reicht dies nicht aus, da einige Server wie der Apache-Server den MIME-Typ der Datei basierend auf der Erweiterung auswählen und Browser wie Chrome die Ausführung von Javascript-Code in etwas ablehnen werden, das ein Bild sein sollte. "Glücklicherweise" gibt es Fehler. Zum Beispiel habe ich aus einem CTF gelernt, dass Apache die Erweiterung .wave nicht kennt und daher keinen MIME-Typ wie audio/* bereitstellt.
Von hier aus, wenn Sie ein XSS und einen Dateiupload finden und es Ihnen gelingt, eine falsch interpretierte Erweiterung zu finden, könnten Sie versuchen, eine Datei mit dieser Erweiterung und dem Inhalt des Skripts hochzuladen. Oder, wenn der Server das richtige Format der hochgeladenen Datei überprüft, erstellen Sie ein Polyglott (einige Polyglott-Beispiele hier).
Formularaktion
Wenn es nicht möglich ist, JS einzufügen, könnten Sie dennoch versuchen, beispielsweise Anmeldeinformationen zu exfiltrieren, indem Sie eine Formularaktion einfügen (und möglicherweise darauf hoffen, dass Passwort-Manager Passwörter automatisch ausfüllen). Sie finden ein Beispiel in diesem Bericht. Beachten Sie auch, dass default-src
keine Formularaktionen abdeckt.
Endpunkte von Drittanbietern + ('unsafe-eval')
Für einige der folgenden Payloads ist unsafe-eval
nicht einmal erforderlich.
Laden Sie eine verwundbare Version von Angular und führen Sie beliebigen JS-Code aus:
Payloads mit Angular + einer Bibliothek mit Funktionen, die das window
-Objekt zurückgeben (siehe diesen Beitrag):
window
-Objekt zurückgeben (siehe diesen Beitrag):Der Beitrag zeigt, dass Sie alle Bibliotheken von cdn.cloudflare.com
(oder einem anderen erlaubten JS-Bibliotheks-Repository) laden könnten, alle hinzugefügten Funktionen aus jeder Bibliothek ausführen und überprüfen könnten, welche Funktionen aus welchen Bibliotheken das window
-Objekt zurückgeben.
Angular XSS aus einem Klassennamen:
Ausnutzung des Google reCAPTCHA-JS-Codes
Laut diesem CTF-Writeup können Sie https://www.google.com/recaptcha/ innerhalb einer CSP missbrauchen, um beliebigen JS-Code auszuführen und die CSP zu umgehen:
Weitere Payloads aus diesem Artikel:
Ausnutzung von www.google.com für offene Weiterleitungen
Die folgende URL leitet auf example.com weiter (von hier):
Drittanbieter-Endpunkte + JSONP
Die Möglichkeit besteht, Google Apps Script zu missbrauchen, um Informationen auf einer Seite innerhalb von script.google.com zu empfangen. Wie es in diesem Bericht getan wird.
Szenarien wie dieses, bei denen script-src
auf self
und eine bestimmte Domain gesetzt ist, die auf der Whitelist steht, können mithilfe von JSONP umgangen werden. JSONP-Endpunkte ermöglichen unsichere Rückrufmethoden, die es einem Angreifer ermöglichen, XSS auszuführen. Funktionierendes Payload:
JSONBee enthält fertige JSONP-Endpunkte zum Umgehen der CSP verschiedener Websites.
Die gleiche Schwachstelle tritt auf, wenn der vertrauenswürdige Endpunkt eine offene Weiterleitung enthält, da Weiterleitungen vertrauenswürdig sind, wenn der ursprüngliche Endpunkt vertrauenswürdig ist.
Missbräuche durch Dritte
Wie in dem folgenden Beitrag beschrieben, gibt es viele Drittanbieter-Domains, die möglicherweise irgendwo in der CSP zugelassen sind und missbraucht werden können, um Daten auszuleiten oder JavaScript-Code auszuführen. Einige dieser Drittanbieter sind:
Entität | Zugelassene 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 zugelassenen 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 ausleiten oder Code ausführen.
Wenn Sie beispielsweise 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 befolgen Sie diese allgemeinen Schritte:
Erstellen Sie hier ein Facebook Developer-Konto.
Erstellen Sie eine neue "Facebook Login"-App und wählen Sie "Website".
Gehen Sie zu "Einstellungen -> Grundlegendes" und notieren Sie sich Ihre "App-ID".
Auf der Zielseite, von der Sie Daten exfiltrieren möchten, können Sie Daten direkt mithilfe des Facebook SDK-Gadgets "fbq" über ein "customEvent" und die Datenpayload exfiltrieren.
Gehen Sie zu Ihrem App "Event Manager" und wählen Sie die von Ihnen erstellte Anwendung aus (beachten Sie, dass der Event Manager unter einer URL wie dieser zu finden sein könnte: https://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events).
Wählen Sie den Tab "Test Events", um die von "Ihrer" Website gesendeten Ereignisse zu sehen.
Dann führen Sie auf der Opferseite den folgenden Code aus, um das Facebook-Tracking-Pixel zu initialisieren, um auf das Facebook-Entwicklerkonto des Angreifers zu verweisen und ein benutzerdefiniertes Ereignis wie folgt auszulösen:
Umgehung über RPO (Relative Path Overwrite)
Neben der bereits erwähnten Umleitung zur Umgehung von Pfadbeschränkungen gibt es eine weitere Technik namens Relative Path Overwrite (RPO), die auf einigen Servern verwendet werden kann.
Wenn beispielsweise CSP 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 namens ..%2fangular%2fangular.js
unter https://example.com/scripts/react/
lädt, was mit CSP konform ist.
Daher wird es dekodiert und effektiv https://example.com/scripts/react/../angular/angular.js
angefordert, was äquivalent zu https://example.com/scripts/angular/angular.js
ist.
Durch Ausnutzen dieser Inkonsistenz in der URL-Interpretation zwischen Browser und 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 Browser und Server sicherzustellen und dieses Problem zu vermeiden.
Online-Beispiel:https://jsbin.com/werevijewa/edit?html,output
Iframes-JS-Ausführung
pageIframes in XSS, CSP and SOPfehlendes base-uri
Wenn die Direktive base-uri fehlt, können Sie sie missbrauchen, um eine dangling markup injection durchzuführen.
Darüber hinaus, wenn die Seite ein Skript unter Verwendung eines relativen Pfads lädt (wie <script src="/js/app.js">
) und ein Nonce verwendet, können Sie das base tag missbrauchen, um das Skript von Ihrem eigenen Server zu laden und so ein XSS zu erreichen.
Wenn die verwundbare Seite mit httpS geladen wird, verwenden Sie eine httpS-URL im base-tag.
AngularJS Ereignisse
Eine spezifische Richtlinie namens 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
bereit, das auf das native Browser-Ereignisobjekt verweist. Dieses $event
-Objekt kann ausgenutzt werden, um die CSP zu umgehen. Insbesondere besitzt in Chrome das $event/event
-Objekt ein Attribut path
, das ein Objektarray enthält, das in der Ereignisausführungskette verwickelt ist, wobei das window
-Objekt immer am Ende positioniert ist. Diese Struktur ist entscheidend für Sandbox-Escape-Taktiken.
Durch das Weiterleiten dieses Arrays an den orderBy
-Filter ist es möglich, darüber zu iterieren und das Terminalobjekt (das window
-Objekt) zu nutzen, um eine globale Funktion wie alert()
auszulösen. Der nachfolgende dargestellte Codeausschnitt verdeutlicht diesen Prozess:
Dieser Ausschnitt hebt die Verwendung der ng-focus
-Direktive zur Auslösung des Ereignisses hervor, wobei $event.path|orderBy
verwendet wird, um das path
-Array zu manipulieren, und das window
-Objekt genutzt wird, um die alert()
-Funktion auszuführen und somit document.cookie
offenzulegen.
Finden Sie weitere Angular-Bypasses unter https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
AngularJS und whitelistete Domäne
Eine CSP-Richtlinie, die Domains für das Laden von Skripten in einer Angular JS-Anwendung whitelistet, kann durch die Aufruf von Rückruffunktionen und bestimmten anfälligen Klassen umgangen werden. Weitere Informationen zu dieser Technik finden Sie in einem ausführlichen Leitfaden, der in diesem Git-Repository verfügbar ist.
Funktionierende Payloads:
Umgehung durch Weiterleitung
Was passiert, wenn CSP serverseitige Weiterleitung feststellt? Wenn die Weiterleitung zu einem anderen Ursprung führt, der nicht erlaubt ist, schlägt sie fehl.
Gemäß der Beschreibung in CSP-Spezifikation 4.2.2.3. Pfade und Weiterleitungen kann die Weiterleitung jedoch die ursprünglichen Beschränkungen umgehen, wenn sie zu einem anderen Pfad führt.
Hier ist ein Beispiel:
Wenn CSP auf https://www.google.com/a/b/c/d
festgelegt ist, werden sowohl Skripte /test
als auch /a/test
durch CSP blockiert.
Jedoch wird das endgültige http://localhost:5555/301
auf der Serverseite zu 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 geladen, wodurch die Pfadbeschränkung umgangen wird.
Durch diese Umleitung wird selbst bei vollständiger Angabe des Pfads die Sicherheitsmaßnahme umgangen.
Daher ist die beste Lösung sicherzustellen, dass die Website keine offenen Umleitungsanfälligkeiten aufweist und dass es keine Domains gibt, die in den CSP-Regeln ausgenutzt werden können.
Umgehung von CSP mit hängender Markup
Lesen Sie hier, wie es geht.
'unsafe-inline'; img-src *; via XSS
'unsafe-inline'
bedeutet, dass du beliebigen Code innerhalb des Codes ausführen kannst (XSS kann Code ausführen) und img-src *
bedeutet, dass du auf der Webseite jedes Bild aus jeder Quelle verwenden kannst.
Du kannst diese CSP umgehen, indem du die Daten über Bilder exfiltrierst (in diesem Fall nutzt das XSS einen CSRF aus, bei dem eine vom Bot zugängliche Seite ein SQLi enthält und die Flagge über ein Bild extrahiert):
Von: https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle
Sie könnten auch diese Konfiguration missbrauchen, um JavaScript-Code zu laden, der in ein Bild eingefügt wurde. Wenn die Seite beispielsweise das Laden von Bildern von Twitter erlaubt. Sie könnten ein spezielles Bild erstellen, es auf Twitter hochladen und das "unsafe-inline" missbrauchen, um einen JS-Code auszuführen (wie bei einem regulären XSS), 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:
Richtlinieninjektion
Forschung: https://portswigger.net/research/bypassing-csp-with-policy-injection
Chrome
Wenn ein von Ihnen gesendeter Parameter innerhalb der Deklaration der Richtlinie eingefügt wird, könnten Sie die Richtlinie auf eine Weise ändern, die sie nutzlos macht. Sie könnten das Skript 'unsafe-inline' mit einem dieser Umgehungen erlauben:
Da diese Direktive bestehende script-src-Direktiven überschreiben wird. 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
Im Edge ist es viel einfacher. Wenn Sie im CSP nur dies hinzufügen können: ;_
würde Edge die gesamte Richtlinie fallen lassen.
Beispiel: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E
img-src *; über XSS (iframe) - Zeitangriff
Beachten Sie das Fehlen der Direktive 'unsafe-inline'
Dieses Mal können Sie das Opfer dazu bringen, eine Seite unter Ihrer Kontrolle über XSS mit einem <iframe
zu laden. Dieses Mal werden Sie das Opfer dazu bringen, die Seite aufzurufen, von der Sie Informationen extrahieren möchten (CSRF). Sie können nicht auf den Inhalt der Seite zugreifen, aber wenn Sie irgendwie die Ladezeit der Seite kontrollieren können, können Sie die benötigten Informationen extrahieren.
Dieses Mal wird eine Flagge extrahiert, immer wenn ein Zeichen richtig geraten wird über SQLi, dauert die Antwort aufgrund der sleep-Funktion länger. Dann können Sie die Flagge extrahieren:
Über Bookmarklets
Dieser Angriff würde einige soziale Manipulationen implizieren, bei denen der Angreifer den Benutzer überzeugt, einen Link über das Bookmarklet des Browsers zu ziehen und abzulegen. Dieses Bookmarklet würde bösartigen JavaScript-Code enthalten, der beim Ziehen und Ablegen oder Klicken im Kontext des aktuellen Webfensters ausgeführt wird, wodurch die CSP umgangen wird und das Stehlen sensibler Informationen wie Cookies oder Tokens ermöglicht wird.
Für weitere Informationen überprüfen Sie den Originalbericht hier.
CSP-Umgehung durch Beschränkung der CSP
In diesem CTF-Bericht wird die CSP umgangen, indem in einem erlaubten iframe eine restriktivere CSP injiziert wird, die das Laden einer bestimmten JS-Datei verhinderte, die dann über Prototyp-Verunreinigung oder DOM-Überschreibung erlaubte, einen anderen Skript zu missbrauchen, um ein beliebiges Skript zu laden.
Sie können die CSP eines Iframes mit dem csp
-Attribut beschränken:
In diesem CTF-Writeup war es durch HTML-Injection möglich, eine CSP weiter einzuschränken, sodass ein Skript, das CSTI verhindert, deaktiviert wurde und somit die Schwachstelle ausnutzbar wurde. CSP kann durch Verwendung von HTML-Meta-Tags restriktiver gestaltet werden und Inline-Skripte können deaktiviert werden, indem der Eintrag entfernt wird, der ihre 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 mit dem Header Content-Security-Policy-Report-Only
und einem von dir kontrollierten Wert antworten zu lassen (vielleicht aufgrund eines CRLF), könntest du ihn dazu bringen, auf deinen Server zu verweisen. Wenn du den JS-Inhalt, den du exfiltrieren möchtest, mit <script>
umschließt und da unsafe-inline
höchstwahrscheinlich nicht durch die CSP erlaubt ist, wird dies einen CSP-Fehler auslösen und ein Teil des Skripts (der die sensiblen Informationen enthält) wird vom Content-Security-Policy-Report-Only
an den Server gesendet.
Für ein Beispiel siehe dieses CTF-Writeup.
Offenlegung von Informationen mit CSP und Iframe
Es wird ein
iframe
erstellt, das auf eine URL verweist (nennen wir siehttps://example.redirect.com
), die von CSP erlaubt ist.Diese URL leitet dann auf eine geheime URL um (z. B.
https://usersecret.example2.com
), die nicht von CSP erlaubt ist.Durch das Abhören des
securitypolicyviolation
-Ereignisses kann die EigenschaftblockedURI
erfasst werden. Diese Eigenschaft gibt die Domain der blockierten URI preis und gibt somit die geheime Domain preis, zu der die ursprüngliche URL umgeleitet wurde.
Interessant ist, dass Browser wie Chrome und Firefox unterschiedliche Verhaltensweisen beim Umgang mit Iframes im Hinblick auf CSP aufweisen, was zu potenziellen Lecks sensibler Informationen aufgrund undefinierter Verhaltensweisen führen kann.
Eine weitere Technik besteht darin, die CSP selbst auszunutzen, um das geheime Subdomain abzuleiten. Diese Methode basiert auf einem binären Suchalgorithmus und der Anpassung der CSP, um bestimmte Domains einzuschließen, die absichtlich blockiert sind. Wenn das geheime Subdomain beispielsweise aus unbekannten Zeichen besteht, können Sie iterativ verschiedene Subdomains testen, indem Sie die CSP-Richtlinie ändern, um diese Subdomains zu blockieren oder zuzulassen. Hier ist ein Ausschnitt, der zeigt, wie die CSP eingerichtet werden könnte, um diese Methode zu erleichtern:
Durch Überwachung, welche Anfragen vom CSP blockiert oder zugelassen werden, kann man die möglichen Zeichen in der geheimen Subdomain eingrenzen und letztendlich die vollständige URL aufdecken.
Beide Methoden nutzen die Feinheiten der CSP-Implementierung und des Verhaltens in Browsern aus, um zu zeigen, wie scheinbar sichere Richtlinien versehentlich sensible Informationen preisgeben können.
Trick von hier.
Treten Sie dem HackenProof Discord Server bei, um mit erfahrenen Hackern und Bug-Bounty-Jägern zu kommunizieren!
Hacking-Einblicke Beschäftigen Sie sich mit Inhalten, die sich mit dem Nervenkitzel und den Herausforderungen des Hackens befassen
Echtzeit-Hack-News Bleiben Sie mit der schnelllebigen Hacking-Welt durch Echtzeitnachrichten und Einblicke auf dem Laufenden
Neueste Ankündigungen Bleiben Sie über die neuesten Bug-Bounties und wichtige Plattformupdates informiert
Treten Sie uns bei Discord bei und beginnen Sie noch heute mit Top-Hackern zusammenzuarbeiten!
Unsichere Technologien zum Umgehen von CSP
PHP-Antwortpufferüberlastung
PHP ist dafür bekannt, die Antwort standardmäßig auf 4096 Bytes zu puffern. Daher, wenn PHP eine Warnung anzeigt, indem ausreichend Daten in den Warnungen bereitgestellt werden, wird die Antwort vor dem CSP-Header gesendet, was dazu führt, dass der Header ignoriert wird. Dann besteht die Technik im Wesentlichen darin, den Antwortpuffer mit Warnungen zu füllen, damit der CSP-Header nicht gesendet wird.
Idee von diesem Writeup.
Fehlerseite umschreiben
Aus diesem Writeup geht hervor, dass es möglich war, eine CSP-Schutzmaßnahme zu umgehen, indem eine Fehlerseite geladen (möglicherweise ohne CSP) und ihr 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 wird erreicht, indem der verwundbare Endpunkt von einer Angreiferseite geladen und dann die Angreiferseite zum echten Endpunkt in derselben Herkunft aktualisiert wird, die Sie missbrauchen möchten. Auf diese Weise kann der verwundbare Endpunkt das opener
-Objekt im Payload verwenden, um auf den DOM des echten Endpunkts zuzugreifen, um ihn zu missbrauchen. Weitere Informationen finden Sie unter:
Darüber hinaus verfügt wordpress über einen JSONP-Endpunkt unter /wp-json/wp/v2/users/1?_jsonp=data
, der die gesendeten Daten im Ausgabewert reflektiert (mit der Einschränkung auf nur Buchstaben, Zahlen und Punkte).
Ein Angreifer kann diesen Endpunkt missbrauchen, um einen SOME-Angriff gegen WordPress durchzuführen und ihn in <script s
rc=/wp-json/wp/v2/users/1?_jsonp=some_attack></script>
einzubetten. Beachten Sie, dass dieses Skript 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 verwundbaren Callback-Endpunkt missbrauchen, der die CSP umgeht, um einem Benutzer mehr Rechte zu geben, ein neues Plugin zu installieren...
Weitere Informationen dazu, wie dieser Angriff durchgeführt wird, finden Sie unter https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/
CSP-Exfiltration-Bypasses
Wenn eine strenge CSP vorhanden ist, die es Ihnen nicht erlaubt, mit externen Servern zu interagieren, gibt es einige Dinge, die Sie immer tun können, um die Informationen zu exfiltrieren.
Location
Sie könnten einfach den Standort aktualisieren, um dem Server des Angreifers die geheimen Informationen zu senden:
Meta-Tag
Sie könnten eine Weiterleitung durch das Einschleusen eines Meta-Tags erreichen (dies ist lediglich eine Weiterleitung, es wird kein Inhalt preisgegeben)
DNS Prefetch
Um Seiten schneller zu laden, werden Browser Hostnamen in IP-Adressen aufgelöst und zwischengespeichert.
Sie können einem Browser anzeigen, 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:
Content Security Policy (CSP) Bypass
CSP Bypass using script-src 'unsafe-inline'
script-src 'unsafe-inline'
If a website has the following Content Security Policy:
You can bypass it by injecting inline JavaScript code using the unsafe-inline
keyword:
This allows any inline script to be executed on the website, potentially opening it up to cross-site scripting (XSS) attacks.
CSP Bypass using Data URI
Another way to bypass CSP is by using Data URI to load external scripts. For example, if a website has the following CSP:
You can bypass it by encoding the script into a Data URI format and injecting it into the HTML:
This technique can be used to execute arbitrary scripts on the website, bypassing the CSP restrictions.
Um dies zu vermeiden, kann der Server den HTTP-Header senden:
Anscheinend funktioniert diese Technik nicht in headless Browsern (Bots).
WebRTC
Auf mehreren Seiten kann man lesen, dass WebRTC die connect-src
-Richtlinie des CSP nicht überprüft.
Tatsächlich können Informationen durch eine DNS-Anfrage preisgegeben werden. 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
Treten Sie dem HackenProof Discord Server bei, um mit erfahrenen Hackern und Bug-Bounty-Jägern zu kommunizieren!
Hacking Insights Beschäftigen Sie sich mit Inhalten, die sich mit dem Nervenkitzel und den Herausforderungen des Hackens befassen
Echtzeit-Hack-News Bleiben Sie mit der schnelllebigen Hacking-Welt durch Echtzeit-Nachrichten und Einblicke auf dem Laufenden
Neueste Ankündigungen Bleiben Sie über die neuesten Bug-Bounties und wichtige Plattformupdates informiert
Treten Sie uns bei Discord bei und beginnen Sie noch heute mit der Zusammenarbeit mit Top-Hackern!
Last updated