Bypassing SOP with Iframes - 1
Last updated
Last updated
AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE) GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE)
이 도전 과제는 NDevTK와 Terjanq가 만든 것으로, 코드에서 XSS를 악용해야 합니다.
주요 문제는 메인 페이지가 data.body
를 전송하기 위해 DomPurify를 사용한다는 것입니다. 따라서 해당 코드에 자신의 HTML 데이터를 전송하려면 e.origin !== window.origin
을 우회해야 합니다.
그들이 제안하는 해결책을 살펴보겠습니다.
//example.org
가 샌드박스 iframe에 포함되면 페이지의 출처는 **null
**이 됩니다. 즉, **window.origin === null
**입니다. 따라서 <iframe sandbox="allow-scripts" src="https://so-xss.terjanq.me/iframe.php">
를 통해 iframe을 포함시키기만 하면 null
출처를 강제할 수 있습니다.
페이지가 포함 가능하다면 그 방법으로 보호를 우회할 수 있습니다 (쿠키는 SameSite=None
으로 설정해야 할 수도 있습니다).
덜 알려진 사실은 샌드박스 값 allow-popups
가 설정되면 열린 팝업이 모든 샌드박스 속성을 상속받는다는 것입니다. allow-popups-to-escape-sandbox
가 설정되지 않는 한 말이죠.
따라서 null 출처에서 팝업을 열면 팝업 내부의 **window.origin
**도 **null
**이 됩니다.
따라서 이 챌린지에서는 iframe을 생성하고, 취약한 XSS 코드 핸들러가 있는 페이지(/iframe.php
)로 팝업을 열 수 있습니다. window.origin === e.origin
이므로 두 값이 모두 null
이기 때문에 XSS를 악용할 페이로드를 전송할 수 있습니다.
그 페이로드는 식별자를 가져와서 XSS를 상위 페이지(팝업을 연 페이지)로 전송할 것입니다. 그 페이지는 취약한 /iframe.php
로 위치를 변경할 것입니다. 식별자가 알려져 있기 때문에 window.origin === e.origin
조건이 만족되지 않아도 상관없습니다 (기억하세요, 출처는 출처가 null
인 iframe의 팝업입니다) 왜냐하면 data.identifier === identifier
이기 때문입니다. 그러면 XSS가 다시 트리거됩니다, 이번에는 올바른 출처에서.
AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE) GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE)