Blocking main page to steal postmessage
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Winning RCs with Iframes
Zgodnie z tym opisem Terjanq dokumenty blob utworzone z null origins są izolowane dla korzyści bezpieczeństwa, co oznacza, że jeśli utrzymasz główną stronę zajętą, strona iframe zostanie wykonana.
W zasadzie w tym wyzwaniu izolowany iframe jest wykonywany i tuż po jego załadowaniu strona rodzicielska wyśle wiadomość post z flagą. Jednak ta komunikacja postmessage jest vulnerable to XSS (iframe może wykonywać kod JS).
Dlatego celem atakującego jest sprawić, aby rodzic utworzył iframe, ale przed tym, jak rodzic wyśle wrażliwe dane (flag), utrzymać go zajętym i wysłać ładunek do iframe. Gdy rodzic jest zajęty, iframe wykonuje ładunek, który będzie jakimś JS, który będzie nasłuchiwał na wiadomość postmessage rodzica i wycieknie flagę. Na koniec, iframe wykonał ładunek, a strona rodzicielska przestaje być zajęta, więc wysyła flagę, a ładunek ją wycieka.
Ale jak możesz sprawić, aby rodzic był zajęty tuż po tym, jak wygenerował iframe i tylko podczas gdy czeka na gotowość iframe do wysłania wrażliwych danych? W zasadzie musisz znaleźć asynchroniczną akcję, którą możesz sprawić, aby rodzic wykonał. Na przykład, w tym wyzwaniu rodzic nasłuchiwał na postmessages w ten sposób:
więc możliwe było wysłanie dużej liczby całkowitej w postmessage, która zostanie przekonwertowana na ciąg w tym porównaniu, co zajmie trochę czasu:
Aby być precyzyjnym i wysłać ten postmessage tuż po utworzeniu iframe, ale przed tym, jak będzie gotowy do odbioru danych od rodzica, będziesz musiał bawić się milisekundami w setTimeout
.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated