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 strona główna 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 rozwiązanie, które proponują.
Gdy //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 możliwa do osadzenia, można by 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 sandboxu, chyba że allow-popups-to-escape-sandbox
jest ustawione.
Zatem otwierając popup z null origin, window.origin
wewnątrz popupu również będzie null
.
Dlatego, w tym wyzwaniu, 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 strony głównej (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)