Bypassing SOP with Iframes - 1
Iframes em SOP-1
Neste desafio criado por NDevTK e Terjanq você precisa explorar um XSS no código.
O principal problema é que a página principal usa o DomPurify para enviar o data.body
, então, para enviar seus próprios dados html para esse código, você precisa burlar e.origin !== window.origin
.
Vamos ver a solução que eles propõem.
Bypass SOP 1 (e.origin === null)
Quando //example.org
é incorporado em um iframe com sandbox, então a origem da página será null
, ou seja, window.origin === null
. Portanto, apenas incorporando o iframe via <iframe sandbox="allow-scripts" src="https://so-xss.terjanq.me/iframe.php">
poderíamos forçar a origem null
.
Se a página fosse incorporável, você poderia burlar essa proteção dessa forma (os cookies também podem precisar ser definidos como SameSite=None
).
Bypass SOP 2 (window.origin === null)
O fato menos conhecido é que quando o valor de sandbox allow-popups
é definido, então o popup aberto irá herdar todos os atributos de sandbox a menos que allow-popups-to-escape-sandbox
seja definido.
Portanto, abrir um popup a partir de uma origem nula fará com que o window.origin
dentro do popup também seja null
.
Solução do Desafio
Portanto, para este desafio, alguém poderia criar um iframe, abrir um popup para a página com o manipulador de código XSS vulnerável (/iframe.php
), como window.origin === e.origin
porque ambos são null
, é possível enviar um payload que irá explorar o XSS.
Esse payload obterá o identificador e enviará um XSS de volta para a página superior (a página que abriu o popup), o que irá alterar a localização para o vulnerável /iframe.php
. Como o identificador é conhecido, não importa que a condição window.origin === e.origin
não seja satisfeita (lembre-se, a origem é o popup do iframe que tem a origem null
) porque data.identifier === identifier
. Então, o XSS será acionado novamente, desta vez na origem correta.
Last updated