Blocking main page to steal postmessage
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)
Згідно з цим Terjanq writeup блоб-документи, створені з нульових джерел, ізольовані для безпеки, що означає, що якщо ви зайняті основною сторінкою, сторінка iframe буде виконана.
В основному, у цьому виклику ізольований iframe виконується і відразу після його завантаження батьківська сторінка надішле пост повідомлення з флагом. Однак, ця комунікація postmessage є вразливою до XSS (iframe може виконувати JS-код).
Отже, мета атакуючого полягає в тому, щоб дозволити батьківській сторінці створити iframe, але перед тим, як батьківська сторінка надішле чутливі дані (флаг), тримати її зайнятою і надіслати payload до iframe. Поки батьківська сторінка зайнята, iframe виконує payload, який буде деяким JS, що слухатиме повідомлення postmessage батьківської сторінки і витікатиме флаг. Нарешті, iframe виконав payload, і батьківська сторінка перестає бути зайнятою, тому надсилає флаг, а payload його витікає.
Але як ви могли б змусити батьківську сторінку бути зайнятою відразу після того, як вона згенерувала iframe і лише поки чекає, щоб iframe був готовий надіслати чутливі дані? В основному, вам потрібно знайти асинхронну дію, яку ви могли б змусити батьківську сторінку виконати. Наприклад, у цьому виклику батьківська сторінка слухала postmessages ось так:
тому було можливо надіслати велике ціле число в postmessage, яке буде перетворено в рядок в цьому порівнянні, що займе деякий час:
І щоб бути точним і надіслати цей postmessage саме після створення iframe, але до того, як він буде готовий приймати дані від батьківського елемента, вам потрібно буде погратися з мілісекундами у setTimeout
.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)