Bypassing SOP with Iframes - 1
SOP-1에서의 Iframes
NDevTK와 Terjanq가 만든 이 도전과제에서는 코드 내 XSS를 악용해야 합니다.
주요 문제는 메인 페이지가 DomPurify를 사용하여 data.body
를 전송하기 때문에 해당 코드로 자체 HTML 데이터를 보내려면 e.origin !== window.origin
을 우회해야 한다는 것입니다.
제안된 해결책을 살펴보겠습니다.
SOP 우회 1 (e.origin === null)
//example.org
이 sandboxed iframe에 포함되면 페이지의 **원본(origin)**은 **null
**이 됩니다. 즉, **window.origin === null
**입니다. 따라서 <iframe sandbox="allow-scripts" src="https://so-xss.terjanq.me/iframe.php">
를 통해 iframe을 포함시키면 null
원본을 강제로 생성할 수 있습니다.
페이지가 포함 가능한 경우에는 이러한 보호를 우회할 수 있습니다 (쿠키도 SameSite=None
으로 설정해야 할 수 있습니다).
SOP 우회 2 (window.origin === null)
잘 알려지지 않은 사실은 sandbox 값으로 allow-popups
가 설정되어 있을 때 열린 팝업은 allow-popups-to-escape-sandbox
가 설정되지 않는 한 모든 sandboxed 속성을 상속받는다는 것입니다.
따라서 null 원본에서 팝업을 열면 팝업 내부의 **window.origin
**도 **null
**이 됩니다.
도전 과제 해결책
따라서 이 도전 과제에서는 iframe을 생성하고, 취약한 XSS 코드 핸들러인 (/iframe.php
) 페이지로 팝업을 열 수 있습니다. window.origin === e.origin
이 가능한 이유는 둘 다 null
이기 때문입니다. 이를 통해 XSS를 악용할 페이로드를 전송할 수 있습니다.
해당 페이로드는 식별자를 가져와 XSS를 다시 상위 페이지 (팝업을 열었던 페이지)로 전송합니다. 이때, 식별자는 알려져 있으므로 window.origin === e.origin
조건이 만족되지 않아도 상관없습니다 (기억하세요, 원본은 iframe의 팝업이며 원본은 **null
**입니다) data.identifier === identifier
입니다. 그런 다음, XSS가 다시 트리거됩니다. 이번에는 올바른 원본에서 발생합니다.
Last updated