Blocking main page to steal postmessage

Support HackTricks

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:

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.

Support HackTricks

Last updated