<summary><strong>Erlernen Sie AWS-Hacking von Grund auf mit</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merch**](https://peass.creator-spring.com)
* Entdecken Sie [**The PEASS Family**](https://opensea.io/collection/the-peass-family), unsere Sammlung exklusiver [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.
Treten Sie dem [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) Server bei, um mit erfahrenen Hackern und Bug-Bounty-Jägern zu kommunizieren!
Content Security Policy (CSP) wird als Browser-Technologie anerkannt, die hauptsächlich darauf abzielt, **vor Angriffen wie Cross-Site-Scripting (XSS) zu schützen**. Es 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 Einbeziehung von **Meta-Elementen in die HTML-Seite**. Nach dieser Richtlinie setzen Browser diese Bestimmungen proaktiv durch und blockieren sofort alle festgestellten Verstöße.
*`Content-Security-Policy-Report-Only`: Wird zur Überwachung verwendet; meldet Verstöße, ohne sie zu blockieren. Ideal für Tests in Vorproduktionsumgebungen.
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:
* **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.
* **frame-ancestors**: Legt fest, welche Quellen die aktuelle Seite einbetten können, gilt für Elemente wie `<frame>`, `<iframe>`, `<object>`, `<embed>` und `<applet>`.
*`'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 scripts with a specific sha256 hash.
*`'strict-dynamic'`: Ermöglicht das Laden von Skripten aus jeder Quelle, wenn sie durch eine Nonce oder einen 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 aus sicheren Ursprüngen laden).
*`'strict-origin-when-cross-origin'`: Sendet vollständige URLs bei der Durchführung von gleichen Ursprungsanfragen, sendet jedoch nur den Ursprung, wenn die Anfrage über Ursprünge hinweg erfolgt.
*`'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.
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**.
Darüber hinaus, selbst wenn Sie einen **JS-Code innerhalb** einer Datei hochladen könnten, die von dem Server akzeptierte Erweiterung hat (wie 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, das ein Bild sein sollte, **ablehnen**. "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/\*** dafür bereitstellt.
Von hier aus, wenn Sie ein XSS und einen Dateiupload finden und es schaffen, 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 ([hier einige Polyglott-Beispiele](https://github.com/Polydet/polyglot-database)).
#### Payloads mit Angular + einer Bibliothek mit Funktionen, die das `window`-Objekt zurückgeben ([siehe diesen Beitrag](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
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**.
Laut [**diesem CTF-Writeup**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?\_x\_tr\_sl=es&\_x\_tr\_tl=en&\_x\_tr\_hl=es&\_x\_tr\_pto=wapp#noteninja-3-solves) kann [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) innerhalb einer CSP missbraucht werden, um beliebigen JS-Code auszuführen und die CSP zu umgehen:
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:
Die gleiche Schwachstelle tritt auf, wenn der **vertrauenswürdige Endpunkt eine offene Weiterleitung enthält**, da Weiterleitungen als vertrauenswürdig angesehen werden, wenn der ursprüngliche Endpunkt vertrauenswürdig ist.
Wie in dem [folgenden Beitrag](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses) beschrieben, können viele Drittanbieter-Domains, die möglicherweise irgendwo in der CSP zugelassen sind, missbraucht werden, um Daten auszuleiten oder JavaScript-Code auszuführen. Einige dieser Drittanbieter sind:
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.
The `script-src 'unsafe-inline'` directive allows the execution of inline scripts. This can be bypassed by injecting a malicious script into a trusted script tag.
Some CSP configurations allow data URIs (`data:`) as a valid source for scripts. This can be exploited by encoding the malicious script into a data URI format and including it in the source of a script tag.
If the CSP policy includes a `nonce` value in the script-src directive, an attacker can bypass it by injecting a script tag with the correct nonce value.
Similarly, if the CSP policy includes a `hash` value in the script-src directive, an attacker can bypass it by calculating the hash of the malicious script and including it in the CSP header.
If the CSP policy restricts worker sources using the `worker-src` directive, an attacker can bypass it by using a Web Worker to load and execute malicious scripts.
Similar to script sources, the `style-src 'unsafe-inline'` directive allows the execution of inline styles. This can be exploited by injecting malicious styles into a trusted style tag.
If the CSP policy restricts network connections using the `connect-src` directive, an attacker can bypass it by abusing allowed endpoints to establish a connection to a malicious server.
#### CSP Bypass using `frame-ancestors` Directive
The `frame-ancestors` directive restricts which websites can embed the current site in a frame. This can be bypassed by using clickjacking techniques to trick users into interacting with a hidden iframe.
1. Erstellen Sie ein Facebook Developer-Konto hier.
2. Erstellen Sie eine neue "Facebook Login"-App und wählen Sie "Website".
3. Gehen Sie zu "Einstellungen -> Grundlegendes" und notieren Sie sich Ihre "App-ID".
4. Auf der Zielseite, von der Sie Daten exfiltrieren möchten, können Sie Daten direkt über das Facebook SDK-Gerät "fbq" durch ein "customEvent" und die Datenpayload exfiltrieren.
5. 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).
6. 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 Developer-Konto des Angreifers zu verweisen und ein benutzerdefiniertes Ereignis wie folgt auszulösen:
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.
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.
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.
Wenn die Direktive **base-uri** fehlt, können Sie sie missbrauchen, um eine [**dangling markup injection**](../dangling-markup-html-scriptless-injection/) durchzuführen.
Darüber hinaus, wenn die **Seite ein Skript mit einem relativen Pfad lädt** (wie `<script src="/js/app.js">`) und einen **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.
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 bietet AngularJS ein einzigartiges Objekt `$event`, das auf das native Browser-Ereignisobjekt verweist. Dieses `$event`-Objekt kann ausgenutzt werden, um die CSP zu umgehen. Insbesondere besitzt das `$event/event`-Objekt in Chrome ein `path`-Attribut, das ein Objektarray enthält, das in die 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 Endelement (das `window`-Objekt) zu nutzen, um eine globale Funktion wie `alert()` auszulösen. Der nachfolgende dargestellte Codeausschnitt erläutert 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**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
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](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22) verfügbar ist.
Andere JSONP beliebige Ausführungsendpunkte können [**hier**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) gefunden werden (einige davon wurden gelöscht oder behoben)
Was passiert, wenn CSP serverseitige Weiterleitung feststellt? Wenn die Weiterleitung zu einem anderen Ursprung führt, der nicht erlaubt ist, schlägt sie dennoch fehl.
Gemäß der Beschreibung in [CSP-Spezifikation 4.2.2.3. Pfade und Weiterleitungen](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects) kann sie jedoch die ursprünglichen Beschränkungen umgehen, wenn die Weiterleitung zu einem anderen Pfad führt.
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.
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.
`'unsafe-inline'` bedeutet, dass Sie beliebigen Code innerhalb des Codes 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 nutzt das XSS einen CSRF aus, bei dem eine vom Bot zugängliche Seite eine SQLi enthält und die Flagge über ein Bild extrahiert):
Sie könnten auch diese Konfiguration missbrauchen, um **JavaScript-Code zu laden, der in ein Bild eingefügt wurde**. Wenn beispielsweise die Seite das Laden von Bildern von Twitter erlaubt, könnten Sie 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/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
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**:
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](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)
Beachten Sie das Fehlen der Direktive `'unsafe-inline'`\
Dieses Mal können Sie das Opfer eine Seite in **Ihrer Kontrolle** über **XSS** mit einem `<iframe` laden lassen. 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:
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.
In [**diesem CTF-Bericht**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution) wird die CSP umgangen, indem in einem erlaubten iframe eine restriktivere CSP eingefügt wird, die das Laden einer bestimmten JS-Datei verhindert, die dann über **Prototyp-Verunreinigung** oder **DOM-Überschreibung** erlaubt hat, ein anderes Skript zu missbrauchen, um ein beliebiges Skript zu laden.
In [**diesem CTF-Writeup**](https://github.com/aszx87410/ctf-writeups/issues/48) 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**:
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, deinen Server anzusteuern. 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 sensible Informationen enthält) wird über `Content-Security-Policy-Report-Only` an den Server gesendet.
* Es wird ein `iframe` erstellt, das auf eine URL verweist (nennen wir sie `https://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 Eigenschaft `blockedURI` erfasst werden. Diese Eigenschaft gibt die Domain der blockierten URI preis und gibt 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 haben, 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 spezifische 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 im 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.
Treten Sie dem [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) Server bei, um mit erfahrenen Hackern und Bug-Bounty-Jägern zu kommunizieren!
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.
Aus [**diesem Writeup**](https://blog.ssrf.kr/69) geht hervor, dass es möglich war, eine CSP-Schutzmaßnahme zu umgehen, indem eine Fehlerseite (möglicherweise ohne CSP) geladen und ihr Inhalt umgeschrieben wurde.
SOME ist eine Technik, die einen XSS (oder stark eingeschränkten 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, den 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, der missbraucht werden soll. 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 widerspiegelt (mit der Einschränkung, nur Buchstaben, Zahlen und Punkte zuzulassen).
Ein Angreifer kann diesen Endpunkt missbrauchen, um einen SOME-Angriff gegen WordPress zu starten 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/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)
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 Informationen zu exfiltrieren.
Content Security Policy (CSP) can be bypassed by loading JavaScript from an untrusted CDN that is not whitelisted in the CSP policy. This can be achieved by finding a CDN that allows users to upload arbitrary files and host them.
#### Steps to Bypass CSP using Untrusted CDN:
1. Find an untrusted CDN that allows users to upload files.
2. Upload a JavaScript file containing the payload to the CDN.
3. Craft a payload that performs the desired actions, such as stealing cookies or redirecting users to a malicious site.
4. Include the CDN URL hosting the payload in the `script-src` directive of the CSP policy.
By loading the JavaScript from the untrusted CDN, the CSP policy can be bypassed, allowing the execution of the malicious payload.
Treten Sie dem [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) Server bei, um mit erfahrenen Hackern und Bug-Bounty-Jägern zu kommunizieren!
<summary><strong>Erlernen Sie AWS-Hacking von Null auf Held mit</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Wenn Sie Ihr **Unternehmen in HackTricks beworben sehen möchten** oder **HackTricks als PDF herunterladen möchten**, überprüfen Sie die [**ABONNEMENTPLÄNE**](https://github.com/sponsors/carlospolop)!
* Holen Sie sich das [**offizielle PEASS & HackTricks-Merch**](https://peass.creator-spring.com)
* **Treten Sie der** 💬 [**Discord-Gruppe**](https://discord.gg/hRep4RUj7f) oder der [**Telegram-Gruppe**](https://t.me/peass) bei oder **folgen** Sie uns auf **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die** [**HackTricks**](https://github.com/carlospolop/hacktricks) und [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) GitHub-Repositories einreichen.