Bypassing SOP with Iframes - 1
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
W tym wyzwaniu stworzonym przez NDevTK i Terjanq musisz wykorzystać XSS w zakodowanym
Głównym problemem jest to, że główna strona używa DomPurify do wysyłania data.body
, więc aby wysłać własne dane html do tego kodu, musisz obejść e.origin !== window.origin
.
Zobaczmy proponowane rozwiązanie.
Kiedy //example.org
jest osadzone w sandboxed iframe, to origin strony będzie null
, tzn. window.origin === null
. Więc po prostu osadzając iframe za pomocą <iframe sandbox="allow-scripts" src="https://so-xss.terjanq.me/iframe.php">
możemy wymusić null
origin.
Jeśli strona była osadzalna, mogłeś obejść tę ochronę w ten sposób (ciasteczka mogą również musieć być ustawione na SameSite=None
).
Mniej znanym faktem jest to, że gdy wartość sandbox allow-popups
jest ustawiona, to otwarte okno popup będzie dziedziczyć wszystkie atrybuty sandbox chyba, że allow-popups-to-escape-sandbox
jest ustawione.
Więc otwierając popup z null origin spowoduje, że window.origin
wewnątrz popupu również będzie null
.
Dlatego, dla tego wyzwania, można utworzyć iframe, otworzyć popup do strony z podatnym na XSS kodem (/iframe.php
), ponieważ window.origin === e.origin
ponieważ oba są null
, możliwe jest wysłanie ładunku, który wykorzysta XSS.
Ten ładunek uzyska identyfikator i wyśle XSS z powrotem do głównej strony (strony, która otworzyła popup), która zmieni lokalizację na podatne /iframe.php
. Ponieważ identyfikator jest znany, nie ma znaczenia, że warunek window.origin === e.origin
nie jest spełniony (pamiętaj, że origin to popup z iframe, który ma origin null
) ponieważ data.identifier === identifier
. Wtedy XSS zostanie ponownie uruchomione, tym razem w poprawnym origin.
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)