From 3053d78cd61eb2fb925c72092410b5087b295424 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 19 Aug 2025 20:32:14 +0000 Subject: [PATCH] Translated ['src/pentesting-web/xss-cross-site-scripting/iframes-in-xss- --- .../iframes-in-xss-and-csp.md | 80 +++++++++++++++---- 1 file changed, 65 insertions(+), 15 deletions(-) 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 8f2fe8e1d..bc308888e 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 @@ -4,7 +4,7 @@ ## Iframes w XSS -Istnieją 3 sposoby wskazania zawartości strony w iframe: +Istnieją 3 sposoby na wskazanie zawartości strony w iframie: - Poprzez `src` wskazujący URL (URL może być cross origin lub same origin) - Poprzez `src` wskazujący zawartość za pomocą protokołu `data:` @@ -45,7 +45,7 @@ var secret = "child secret" alert(parent.secret) ``` -Jeśli uzyskasz dostęp do poprzedniego html za pomocą serwera http (takiego jak `python3 -m http.server`), zauważysz, że wszystkie skrypty będą wykonywane (ponieważ nie ma CSP, które by temu zapobiegało). **Rodzic nie będzie mógł uzyskać dostępu do zmiennej `secret` wewnątrz żadnego iframe** i **tylko iframes if2 i if3 (które są uważane za tej samej witryny) mogą uzyskać dostęp do secret** w oryginalnym oknie.\ +Jeśli uzyskasz dostęp do poprzedniego html za pomocą serwera http (takiego jak `python3 -m http.server`), zauważysz, że wszystkie skrypty będą wykonywane (ponieważ nie ma CSP, które by temu zapobiegało). **Rodzic nie będzie mógł uzyskać dostępu do zmiennej `secret` wewnątrz żadnego iframe** i **tylko iframes if2 i if3 (które są uważane za tej samej witryny) mogą uzyskać dostęp do sekretu** w oryginalnym oknie.\ Zauważ, że if4 jest uważany za mający `null` origin. ### Iframes z CSP @@ -61,7 +61,7 @@ Dlatego możliwe jest obejście CSP strony za pomocą: +content="script-src 'sha256-iF/bMbiFXal+AAl9tF8N6+KagNWdMlnhLqWkjAocLsk'" /> " if __name__ == "__main__": app.run() ``` -### Inne ładunki znalezione w dziczy +#### Nowe (2023-2025) techniki omijania CSP z użyciem iframe + +Społeczność badawcza nadal odkrywa kreatywne sposoby wykorzystywania iframe do pokonywania restrykcyjnych polityk. Poniżej znajdują się najbardziej znaczące techniki opublikowane w ciągu ostatnich kilku lat: + +* **Dangling-markup / named-iframe data-exfiltration (PortSwigger 2023)** – Gdy aplikacja odzwierciedla HTML, ale silny CSP blokuje wykonanie skryptów, można nadal wyciekować wrażliwe tokeny, wstrzykując *dangling* ` + + ``` ### Credentialless iframes -Jak wyjaśniono w [tym artykule](https://blog.slonser.info/posts/make-self-xss-great-again/), flaga `credentialless` w iframe jest używana do ładowania strony wewnątrz iframe bez wysyłania poświadczeń w żądaniu, jednocześnie zachowując politykę tego samego pochodzenia (SOP) załadowanej strony w iframe. +Jak wyjaśniono w [tym artykule](https://blog.slonser.info/posts/make-self-xss-great-again/), flaga `credentialless` w iframe jest używana do ładowania strony wewnątrz iframe bez wysyłania poświadczeń w żądaniu, zachowując jednocześnie politykę tego samego pochodzenia (SOP) ładowanej strony w iframe. -To pozwala iframe na dostęp do wrażliwych informacji z innego iframe w tym samym SOP załadowanym na stronie nadrzędnej: +Od **Chrome 110 (luty 2023) funkcja jest włączona domyślnie** i specyfikacja jest standaryzowana w przeglądarkach pod nazwą *anonymous iframe*. MDN opisuje to jako: „mechanizm do ładowania iframe'ów stron trzecich w nowej, efemerycznej partycji pamięci, aby żadne pliki cookie, localStorage ani IndexedDB nie były dzielone z rzeczywistym pochodzeniem”. Konsekwencje dla atakujących i obrońców: + +* Skrypty w różnych iframe'ach bez poświadczeń **wciąż dzielą to samo pochodzenie na najwyższym poziomie** i mogą swobodnie wchodzić w interakcje za pośrednictwem DOM, co czyni ataki multi-iframe self-XSS wykonalnymi (zobacz PoC poniżej). +* Ponieważ sieć jest **pozbawiona poświadczeń**, każde żądanie wewnątrz iframe działa efektywnie jako sesja nieautoryzowana – punkty końcowe chronione przed CSRF zazwyczaj zawodzą, ale publiczne strony, które można wyciekować za pośrednictwem DOM, wciąż są w zasięgu. +* Wyskakujące okna generowane z iframe'a bez poświadczeń otrzymują domyślnie `rel="noopener"`, co łamie niektóre przepływy OAuth. ```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 ``` - Przykład exploita: Self-XSS + CSRF W tym ataku, atakujący przygotowuje złośliwą stronę internetową z 2 iframe'ami: -- Iframe, który ładuje stronę ofiary z flagą `credentialless` z CSRF, który wywołuje XSS (Wyobraź sobie Self-XSS w nazwie użytkownika): +- Iframe, który ładuje stronę ofiary z flagą `credentialless` z CSRF, która wywołuje XSS (Wyobraź sobie Self-XSS w nazwie użytkownika): ```html @@ -201,4 +245,10 @@ Sprawdź następujące strony: ../postmessage-vulnerabilities/steal-postmessage-modifying-iframe-location.md {{#endref}} + + +## Odniesienia + +* [PortSwigger Research – Wykorzystanie przechwytywania formularzy do obejścia CSP (marzec 2024)](https://portswigger.net/research/using-form-hijacking-to-bypass-csp) +* [Chrome Developers – Iframe bez poświadczeń: Łatwe osadzanie iframe w środowiskach COEP (luty 2023)](https://developer.chrome.com/blog/iframe-credentialless) {{#include ../../banners/hacktricks-training.md}}