diff --git a/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md b/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md
index f86920420..e65667ae1 100644
--- a/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md
+++ b/src/pentesting-web/xss-cross-site-scripting/iframes-in-xss-and-csp.md
@@ -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
```
-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
@@ -61,7 +61,7 @@ Daarom is dit moontlik om die CSP van 'n bladsy te omseil met:
+content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk'" />
"
if __name__ == "__main__":
app.run()
```
-### Ander Payloads gevind in die natuur
+#### 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* `
+
+
```
### 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
@@ -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}}