Blokowanie głównej strony w celu kradzieży postmessage

Reading time: 2 minutes

Wygrywanie RC z Iframami

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 główna strona wyśle post wiadomość z flagą.
Jednak ta komunikacja postmessage jest vulnerable to XSS (iframe może wykonać kod JS).

Dlatego celem atakującego jest sprawić, aby główny utworzył iframe, ale przed tym, jak główna strona wyśle wrażliwe dane (flagę), utrzymać ją zajętą i wysłać ładunek do iframe. Gdy główna strona jest zajęta, iframe wykonuje ładunek, który będzie jakimś JS, który będzie nasłuchiwał na wiadomość postmessage głównej i wycieknie flagę.
Na koniec, iframe wykonał ładunek, a główna strona przestaje być zajęta, więc wysyła flagę, a ładunek ją wycieka.

Ale jak możesz sprawić, aby główna strona była zajęta tuż po wygenerowaniu iframe i tylko podczas oczekiwania na gotowość iframe do wysłania wrażliwych danych? W zasadzie musisz znaleźć asynchroniczną akcję, którą możesz sprawić, aby główna wykonała. Na przykład, w tym wyzwaniu główna strona nasłuchiwała na postmessages w ten sposób:

window.addEventListener("message", (e) => {
if (e.data == "blob loaded") {
$("#previewModal").modal()
}
})

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:

const buffer = new Uint8Array(1e7);
win?.postMessage(buffer, '*', [buffer.buffer]);

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.