Bypassing SOP with Iframes - 1
Iframes in SOP-1
In hierdie uitdaging wat deur NDevTK en Terjanq geskep is, moet jy 'n XSS uitbuiting in die gekodeerde
Die hoofprobleem is dat die hoofbladsy DomPurify gebruik om die data.body
te stuur, sodat jy jou eie html-data na daardie kode kan stuur, moet jy e.origin !== window.origin
omseil.
Kom ons kyk na die oplossing wat hulle voorstel.
SOP-omseiling 1 (e.origin === null)
Wanneer //example.org
in 'n sandboxed iframe ingebed word, sal die bladsy se oorsprong null
wees, m.a.w. window.origin === null
. Deur die iframe in te sluit deur middel van <iframe sandbox="allow-scripts" src="https://so-xss.terjanq.me/iframe.php">
kan ons dus die null
oorsprong afdwing.
As die bladsy ingebed kon word, kon jy daardie beskerming op hierdie manier omseil (koekies moet moontlik ook op SameSite=None
gestel word).
SOP-omseiling 2 (window.origin === null)
Die minder bekende feit is dat wanneer die sandbox-waarde allow-popups
ingestel is, die geopen popup al die sandbox-attribuute sal oorneem, tensy allow-popups-to-escape-sandbox
ingestel is.
Dus, as 'n popup van 'n null oorsprong geopen word, sal window.origin
binne die popup ook null
wees.
Uitdagingoplossing
Daarom kan jy vir hierdie uitdaging 'n iframe skep, 'n popup oopmaak na die bladsy met die kwesbare XSS-kodehanterer (/iframe.php
), omdat beide window.origin === e.origin
is omdat beide null
is, is dit moontlik om 'n lading te stuur wat die XSS sal uitbuit.
Daardie lading sal die identifiseerder kry en 'n XSS terugstuur na die bo-bladsy (die bladsy wat die popup oopmaak), wat die plek sal verander na die kwesbare /iframe.php
. Omdat die identifiseerder bekend is, maak dit nie saak dat die voorwaarde window.origin === e.origin
nie bevredig word (onthou, die oorsprong is die popup van die iframe wat oorsprong null
het) omdat data.identifier === identifier
. Dan sal die XSS weer geaktiveer word, hierdie keer in die korrekte oorsprong.
Last updated