I've been thinking about proposing some updates to the "Root cause" section, but I'm having some trouble understanding the main points it tries to convey. Basically, it starts by describing how XS-leaks are inherent to the design of the web (which makes sense), but then it switches to cover defenses and tries to propose a categorization of XS-leaks, which aren't directly related to the root causes.

I think the few initial sentences about how XS-leaks are caused by the design of the web are already covered by the Overview section above, so they may be redundant and we could remove them here.

If we do so, maybe we could rename this section to something like "Attacks and Defenses"? Then, the bullet points at the end of the section could form the attack part (and we could link to some more pages about individual attacks), and the second half of the first paragraph ("For this reason, browsers are now implementing various Defense Mechanisms") could follow with a link to the high-level defense article.

This way we'd also give the reader a better flow for exploring the rest of the wiki.

Currently code from a embed has to be copy and pasted on to a safe origin for testing.

Maybe there should be a article about this.

• https://lcamtuf.blogspot.com/2016/08/css-mix-blend-mode-is-bad-for-keeping.html (Getting History from whack-a-mole)
• https://ronmasas.com/posts/the-human-side-channel (Detected if a user liked a page, exposing email address)

Two different versions of the website.
Maybe xsleaks.com should redirect to xsleaks.dev

https://gohugo.io/content-management/multilingual
I think this would allow for better accessibility.

I can try to move the strings to a English toml file (not sure if wanted)

It seems to have been used here https://github.com/xsleaks/xsleaks/blob/master/examples/cache-api/api.html however I cant see it on https://xsleaks.com/

https://developer.mozilla.org/en-US/docs/Web/API/AbortController

It can be used for:

• Checking if a resource is cached.
• Purging a resource from cache.

Example:

async function ifCached(url, purge = false) {
    var state = true;
    var controller = new AbortController();
    var signal = controller.signal;
    var timeout = await setTimeout(_ => { // Stop request after max
        controller.abort();
        state = false;
    }, 9);
    try {
        let options = {mode: "no-cors", credentials: "include", signal};
        if(purge) options.cache = "reload";
        await fetch(url, options);
    } catch (err) {
        // Website blocked by client
        return false
    }
    clearTimeout(timeout);
    return state;
}

• - Standardize markdown code in all the articles. Some articles highlight some things which are not highlighted in other articles.
• - Change the language of "in discussion draft" to the official names: Living Standard, Working Draft, Candidate Recommendation, Proposed Recommendation, ...
• - Discuss if ToCs are useful
• - Change Browser Intrinsic to Browser Default
• - Remove Navigate Away expression from articles (window.open)
• - Add hyperlink in defense tables with * and (if strict)
• - These examples should be consistent across all articles (Case Scenarios)
• - Create experiments section
• - Add a nice things section to mention stuff like same-site cookies default rollout, same-site cookies bypasses, and other interesting stuff related to XS-Leaks, CTF challenges with XS-Leaks
• - Change Experiments section weight, so the section stays in the bottom.
• - Change Why is this a problem? and Case Scenarios Titles
• - Uniform levels in markdown titles. Check all the articles
• - Add a LICENSE
• - Document weight and hugo-book used stuff
• - Remove xsleaks.github.io repo and point the domain directly to the wiki repo
• - Standardize i.e and e.g
• - Add Chris Evans reference in Network Timing attacks
• - Change timeless timing attacks to ? in fetch metadata, and X in cross window COOP
• - Fix js execution timing defense table
• - Create a Hybrid Timing Attack section
• - Clarify safari partitioned cache is not part of ITP, but part of https://webkit.org/tracking-prevention/
• - Introductory Articles
• - Change the intros
• - Move XS-Search weight to the top
• - Add 🔗 in defenses that need to be applied together to full mitigate an XS-Leak
• - Switch requirement color (green) with current positive (blue) color?

Even though CSS injections in general are not considered XS-Leaks directly, there are some cross-site techniques to smuggle data outside via CSS only.

Maybe it would make sense to create a one section called CSS Injection and bring all the known techniques there. We have mentioned about CSS injection in execution timing: https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#css-injections

#9 (comment) states javascript execution can mess with this measurement. While true, the network timing is always there.

My take on this is that javascript execution is despicable in most of the cases so classification is acceptable.

Can be used to detect browser activity,
Allows more ways to leak data from other origins.

let old;
for(;;) {
let start = performance.now();
let time = performance.now() - start;
if (time - old > 0.4) console.log(time);
old = time;
}

Has been used for keystroke timing attacks using "Interrupt-timing" https://www.misc0110.net/web/files/keystroke_js_slides.pdf

In Navigations article we mention History.pushState as something that can affect History.length. While this is true, it's not really related to navigations. This was not changed because we would have to create an article only for 1 sentence which seems a bit too much at this stage of the project.

So, I think this should be revisited in the future along with other research for the History article.

Nowadays (not sure since when), when you download something in Chrome the viewport dimensions aren't affected (instead the download "chip" near the URL bar shows an animation.

However, as of today, Vivaldi does show a downloads menu on the left which seems to affect the viewport (and triggers a new responsive layout "breakpoint"):

So it's probably better to say "some Chromium browsers".

It seems like cache partitioning is enabled on chrome and firefox now.
This means that cache probing isnt possible anymore right?
Which means https://github.com/xsleaks/wiki/blob/master/content/docs/attacks/cache-probing.md needs updating?

ref:
https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning
https://developer.chrome.com/blog/http-cache-partitioning/

Hi,

the href in the link below is redirecting to a 404 (https://xsleaks.com/docs/attacks/browser-features/corb/ ).

The file with the problem: https://github.com/xsleaks/wiki/blob/master/content/docs/attacks/corb.md

XSS Filters and in particular XSSAuditor are one of the most known XS-Leaks out there. Due to so many issues it was removed from Chromium and Edge.

Ideas:

• The first wiki has good examples
• We could also present the story behind deprecation. Present the multiple issues that were fixed and the ones that remained WontFixed (XS-Leaks). I think we could also analyse the efficiency of these protections since XSSAuditor always had tons of bypasses (efficiency V.s introduced problems).
• This was a learned lessons for browsers (also regarding XS-Leaks)
• Safari still runs an XSS Auditor? Maybe it would be relevant to present what is Safari doing, and what can be done regarding XS-Leaks exploitation.
• Fixed XSSAuditor XS-Leaks: Ref1, Ref2, Ref3, Ref4, Ref5

During the work we did for my master thesis at University of Pavia, we discovered a side channel that relies on the loading time of an image, but this is not a mainstrem timing xs-leak since timers are not used:

It is possible to perform cache probing through the complete property of image elements. This property, as the name said, returns a boolean value which tells us if the related image has complete the load or not. The conditions to satisfy to get a complete load of the image are shown in the complete property MDN web doc. Under the assumption that an attacker is interested in knowing if a specific image is present in the victim’s browser cache memory, then this property can be exploited:

• first of all define a new Image element,
• assign to the new image element the source of the image of interest,
• immediately after the source assignment check for the completeness of the image through the complete property.

function load_and_check(url){
	var img = new Image();
	img.src = 'target_image.jpg';
	console.log(img.complete);
} 

Now what happens is that take place a time-challenge between the loading of the image and the execution of the imageElement.complete JavaScript instruction. The possible outputs are, of course, two:

• If imageElement.complete returns True: the image was completely loaded before the check of the completeness
• If imageElement.complete returns False: the image was not completely loaded before the check of the completeness

Now, under the assumption that the load of an image from browser cache memory will take a time (usually few milliseconds) comparable with the JavaScript execution of the imageElement.complete check while the download of an image from a remote server will take much more (usually hundreds) milliseconds then it means that if the check returns True, then FOR SURE the image was in browser cache memory. Unfortunately this method is not so reliable on the contrary: if the check returns False then it is not sure that the image wasn’t in cache, anyway there are some ways to make the attack more reliable under this aspect.

• Add a nice things section to mention stuff like same-site cookies default rollout, same-site cookies bypasses, and other interesting stuff related to XS-Leaks, CTF challenges with XS-Leaks

media.webkitVideoDecodedByteCount and media.webkitAudioDecodedByteCount seem to provide the byte count of a cross origin video after using media.play() not sure if that could be used in a attack still exists in chrome despite having a report from 2016 https://bugs.chromium.org/p/chromium/issues/detail?id=632380

The following can detect if a resource is of the type video, audio or image.

async function getType(url) {
    // Detect if resource is audio or video
    let media = document.createElement("video");
    media.src = url;
    await new Promise(r=>setTimeout(r,50));
    if (media.videoWidth) {
    return "video";
    } else if (media.duration) {
    return "audio"
    }
    // Detect if resource is an image
    let image = new Image();
    image.src = url;
    await new Promise(r=>setTimeout(r,50));
    if (image.width) return "image";
}

What do you think @terjanq ?

List of interesting topics about XS-Leaks that might be a good starting point to someone interested in researching new attacks/defenses/bypasses.

• change in frames could be used to detect browser's error pages
• first iframe appearance could be a nice indicator when the page loaded most of its components

https://twitter.com/garethheyes/status/1335194323693019136

I discussed this section with @manuelvsousa here is a brief summary:

• The XS-Leak here is cross-origin timing not CSS Selector injection
• CSS Selector is a great example of costly operation, rather than XS-Leak itself, and which can be detected cross-origin
• While Site-Isolation will protect some of the timing techniques, it can still be detected cross-site using other XS-Leaks, for example:
  • performance drops
  • onload events inside an iframe

As a suggestion for the fix:

• Move the CSS Selectors Short-circuit Timing to Examples section
• Specify the exact timing that the article talks about, since this is the most important part of the article (not what is possible to leak, but how!)

As a suggestion for improvements:

• The mentioned CSS Selector injection trick shares the same principle as Blind Regular Expression Injection Attack, both can become very costly depending on the user information, and both can be detected cross-origin. It would be really nice to provide it as an example since searches that allow Regular Expression are not that uncommon.
• I invented a technique for timing costly operations per origin, that bypasses Same-Site Isolation Policy. The principle of the attack is:
  • Load an origin A with a costly operation in a new tab/iframe.
  • Wait for the page to start expensive calculation via timeout
  • Try to load the origin A inside an iframe
  • Because of how the calculations are performed, the framed origin A will only start loading when the blocking calculation finishes. Hence, the malicious website can watch for the onload event on the iframe, regardless of X-Frames-Options header that will not affect the attack.
  • To prevent against the technique, the website must combine XFO with COOP

Proof of concept for measuring google.com domain

Originally posted by @terjanq in #12 (comment)

I've just published a blog post about a technique that allows an active network attacker to observe, from an insecure Web origin, the presence or absence of some Secure cookie that may have been set by the origin’s secure counterpart. Note: It requires a MitM.

Would it make sense to mention this technique somewhere on the wiki? If so, I'm not sure which section...

Looks like hint boxes in Contribution section are broken.

It allows for cache detection and if the server has the Timing-Allow-Origin header it can also get the transferSize.
I think this could be used as an alternative to performance.now for network timings.

async function ifCached(url) {
    await fetch(url, {mode: "no-cors"});
    // Wait for request to be added to performance.getEntries();
    await new Promise(r => setTimeout(r, 1000));
    // Get last added timings
    let res = performance.getEntries().pop();
    console.log("Request duration: " + res.duration);
    console.log("Total:" + res.responseEnd);
    // Check if is 304
    if (res.encodedBodySize > 0 && res.transferSize > 0 && res.transferSize < res.encodedBodySize) return true
    if (res.transferSize > 0) return false;
    if (res.decodedBodySize > 0) return true;
    // Use duration if theirs no Timing-Allow-Origin header
    return res.duration < 10;
}

This was used for an old version of ifCached I saw information about it at https://nicj.net/resourcetiming-in-practice/
It does not seems to work well with https://example.com but worked fine with images maybe res.responseEnd could be used instead.

STR:

1. go to https://xsleaks.dev/docs/attacks/navigations/, navigate to bottom
2. click "Edit this article"
3. Click "Fork this repository" (assuming you don't already have one)

Expected: it forks, you send in a PR, everyone loves you
Actual: GitHub returns 422 response

If you look at the URL generated by

https://github.com/xsleaks/wiki/edit/master/content//docs/attacks/navigations.md

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

It seems powerful since it allows for timing attacks even when theirs CSRF protection.
And theirs limits that only affect one host allowing for better precision and tracking such as

• https://source.chromium.org/chromium/chromium/src/+/master:net/socket/client_socket_pool_manager.cc;l=43
• https://source.chromium.org/chromium/chromium/src/+/main:net/spdy/spdy_session.h;l=79 (maybe)

It would even be possible to exclude resources just by caching them.

In PR #16 we introduced motivations for a Defensive Design Article where we believe, this particular article should be the result of a community effort from both companies (which fix these bugs) and researchers (which get reported bugs fixed).

Here some of the ideas for this article:

• The way applications they use iframes to display information based on a user query (search system)
• How applications use Fetch Metadata with Vary headers to prevent cache probing attacks and what problems might occur with improper deployments. Are there any drawbacks of deploying this?
• How to ensure all application endpoints implement certain Headers to have the same behavior across different states.
• Quick strategies to mitigate reported XS-Leaks, as a short-term solution before deploying web platform security features.

This leak reflects how deep XS-Leaks can go. It shows how attackers can influence an Anti Virus Software in dealing with a web server (and user data) with cross-site requests. One could trick the software (abusing the defender's js engine) to make the server return a certain status code based on user input (and data storage), allowing certain secret data to be leaked.

References:

• Slides: https://westerns.tokyo/wctf2019-gtf/wctf2019-gtf-slides.pdf
• Slides 2 (more stuff): https://speakerdeck.com/icchy/lets-make-windows-defender-angry-antivirus-can-be-an-oracle?slide=4
• Live presentation: https://www.youtube.com/watch?v=mt4QTIcu4hk

We excluded a group of Leaks that abuse certain discrepancies in dynamic JS/CSS Resources and properties of Images. Some of these attacks are:

• Detect a a CSS resource changed in two different states Ref 1, Ref 2
• Check the height and width of an image in two different states Ref 1
• Check JS file changes in two different states (global vars, mutations) Ref 1, Ref 2
• Same for media/audio files

Although there is no formal definition of XS-Leaks to exclude a vulnerability that actually leaks something cross-site, I believe it's debatable whether these leaks should be included in this wiki. Mostly, as their primary characteristic if pretty much the same as XSSI and differ (in the principle) from most of the XS-Leaks in this wiki, which in a way circumvent the Same-Origin Policy.

Some things to think about:

• In this scenario attackers don't have direct access to secrets (like in simple XSSI?), they can, however, infer them based on the contents they legitimately can access. In these cases, the SOP is relaxed (as intended).
• Can we see XS-Leaks as a group of vulnerabilities whose principle diverged from common vulnerabilities? Is the circumvention of the SOP a thing they all have in common?

The defense perspective has mostly two outcomes:

• Applications completely stop the delivery of dynamic JS/CSS/Img
• Applications limit who has access to such resources (which origins). The only solution that might really help here is Fetch-Metadata.

My final conclusion is: I would say that their principle is the same as XSSI (they are XSSI vulnerabilities), and since XSSI have their own league, it seems redundant to drag them here.

Some XS-Leaks are not state-dependent and can be used to leak information about internal networks, for example, with port scanning

The wiki currently focuses on web applications and their behaviors based on user information which is strictly connected with user sessions (cookies). The wiki could have a dedicated spot to address a different perspective around XS-Leaks.

Feel free to share any ideas about this.

Listing all the contributors to the wiki as separate bullets adds a fair amount of vertical space to the introduction and makes it seem a little more daunting to read. It's also likely to not scale well as the wiki gets edits from more users -- I can see a world where the majority of the introduction is taken up by the list of contributors :)

I'd suggest either splitting the contributors page to a separate article, or, as a stop-gap, convert the current two bulleted lists into sentences with a comma-separated list of names.

ifCached does not work for me on chrome.

Window navigation timings could be used as an alternative however there less convenient.
It would be nice if the opener was checked but not sure that would be practical.

Create window

checker = open("about:blank");

Example usage

await ifCached_window("https://example.org");

async function ifCached_window(url) {
  return new Promise(resolve => {
    checker.location = url;
    setTimeout(() => {
      try {
        if (checker.location.href !== "about:blank") {
          // Origin has changed
          resolve(true);
        }
      } catch {
        // No permission for origin
        resolve(true);
      }
      resolve(false);
      checker.location = "about:blank";
    }, 35);
  });
}

@terjanq

as websites became more secure against more traditional classes of vulnerabilities

Bold statement! I have doubts about this, but my question is: considering it's true was this what really brought more attention to XS-Leaks? I disagree. I think it was the possibility of leaking information with higher precision originated from the cat-mouse game between researchers and browsers regarding the patches of dozens of bypasses in features like XSSAuditor. This was great since previous works were mostly academic, and time related. This sentence also starts with a reference from 2015, and when I read this it seems the XS-Leaks era started after XS-Search. I just wanted to say there are a lot of work prior that time:

• https://dl.acm.org/doi/10.1145/352600.352606
• https://dl.acm.org/doi/10.1145/1135777.1135884
• https://scarybeastsecurity.blogspot.com/2009/12/cross-domain-search-timing.html
• https://dl.acm.org/doi/10.1145/2810103.2813708
• https://dl.acm.org/doi/10.1145/2810103.2813632

The text is great but I would rephrase this a bit. I find relevant to mention that we started from timing attacks (refer our own article?), then we found techniques to increase the impact of timing attacks (XS-Search), then covert channels (frame counting, etc) and finally we kept evolving to more accurate and esoteric bugs.

Originally posted by @manuelvsousa in #37 (comment)

During the work we did for a master thesis in collaboration with my company and the University of Pavia, we discovered this interesting side channel due to a misconfiguration in ACAO header:

Origin reflection is a behaviour in which a gobally accessible resource is provided with a Access-Control-Allow-Orign (ACAO) header value that reflects the origin which initialized the request insted of respond with the wildcard *. This can be considered as a CORS misconfiguration even if some backend frameworks such as Python Flask and Ruby on Rails promote origin reflection as a default behaviour for a globally accessible API. What happens is that, under the assumption of a resource hosted on target.com, when it is visualized from target.com itself then it is provided with “Access-Control-Allow-Origin: target.com” header. What is important is that this information is stored toghether with the resource in browser cache memory. Now, following the same concepts, if a third-party website called attacker.com fetches the same resource two possible ways can be followed:

• The resource was never seen before: the resource will be fetched and served and stored toghether with “Access-Control-Allow-Origin: attacker.com” header.
• The resource was already visualized by the victim: it will generate a cache hit, so it will be found in browser cache memory but it will also generate a CORS error due to the ACAO header value mismatch with the requesting origin.

This method provides a highly reliable way to make cache probing since it exploits error events which do not suffer from network performances. The best way to mitigate this is to avoid origin reflection and use the wildcard * for globally accessible resources.

Size Leaks are very important XS-Leaks. They are often addressed in the browser when researchers find exact ways to leak the size. Some mechanisms that still work:

• Cache Timing (Original Ref) can be used to predict the size of a request.

Fixed, but relevant works (we should document them):

• Flash Size Leaks. Flash is going to be removed by the end of the year Ref1, Ref2 (currently is under strict user permissions)
• Attackers could abuse the way browsers use cache limits (Ref1 & Ref2) to predict the size of a resource using Cache API (Ref1 & Ref2). Browsers fixed this issue by adding random noise (Ref1-Chrome & Ref2-Firefox)
• Video and Audio Parsing. This also involves CORB and CORP.
• HEIST. I believe the fix was the same as the one in cache limits Ref1 & Ref2)

Hi!
I was reading some more about some fun attacks (having much fun reading all of it) and I noticed that https://xsleaks.dev/docs/attacks/id-attribute/ states that framing protections won't defend against the ID attribute XS-Leak.

https://xsleaks.dev/docs/attacks/experiments/portals/ explains more about this, but Im missing a link between these 2 pages. As a reader, it would be very nice to learn about this bypass right after reading in the first link that XFO wont protect against this type of leak.

The XS-Leak described in the main example has the drawback of requiring cookies to be present on cross-site resource loads, and at this point both Safari and Chrome don't attach cookies by default.

It could be nice to use an example that works by default in most browsers, but I'm not sure what that could be, because we still want it to be simple and illustrative. Maybe something with a popup?