Bypassing SOP with Iframes - 1
Iframes in SOP-1
इस चुनौती में जो NDevTK और Terjanq द्वारा बनाई गई है, आपको कोड में XSS का लाभ उठाना है
The main problem is that the main page uses DomPurify to send the data.body
, so in order to send your own html data to that code you need to bypass e.origin !== window.origin
.
Let's see the solution they propose.
SOP bypass 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
origin को force कर सकते हैं।
यदि पृष्ठ embeddable होता, तो आप उस सुरक्षा को इस तरह से बायपास कर सकते थे (कुकीज़ को भी SameSite=None
पर सेट करने की आवश्यकता हो सकती है)।
SOP bypass 2 (window.origin === null)
कम ज्ञात तथ्य यह है कि जब sandbox value allow-popups
सेट किया जाता है, तो खुला हुआ पॉपअप सभी sandboxed attributes को inherit करेगा जब तक कि allow-popups-to-escape-sandbox
सेट न किया जाए।
इसलिए, null origin से एक popup खोलने पर पॉपअप के अंदर window.origin
भी null
होगा।
Challenge Solution
इसलिए, इस चुनौती के लिए, कोई iframe create कर सकता है, एक पॉपअप को उस पृष्ठ पर खोल सकता है जिसमें कमजोर XSS कोड हैंडलर (/iframe.php
) है, क्योंकि window.origin === e.origin
क्योंकि दोनों null
हैं, यह संभव है कि एक payload भेजा जाए जो XSS का शोषण करेगा।
वह payload identifier प्राप्त करेगा और XSS को ऊपर के पृष्ठ (पृष्ठ जो पॉपअप खोलता है) पर वापस भेजेगा, जो स्थान को कमजोर /iframe.php
पर बदल देगा। चूंकि पहचानकर्ता ज्ञात है, इसलिए यह मायने नहीं रखता कि शर्त window.origin === e.origin
संतुष्ट नहीं है (याद रखें, origin वह popup है जो iframe से origin null
है) क्योंकि data.identifier === identifier
। फिर, XSS फिर से ट्रिगर होगा, इस बार सही origin में।
Last updated