Cache Probing through image.complete property about wiki HOT 17 CLOSED

Without a timer it does not seem to be possible to stop a resource getting cached in the process of the check.

from wiki.

It's right, I didn't mentioned it but unfortunately with this method is impossible to repeat the measurement once is performed the first check since the image will be cached. Anyway I believe its full potential is expressed on the one-shot attempt, in particular, if it returns True.

from wiki.

Is there a benefit of using this over https://xsleaks.dev/docs/attacks/cache-probing/

from wiki.

The only additional benefit I can see is the independence from network performances, but at the same time it is less precise... I wanted to propose this as "a different way to do it" not "a better way to do it", with its relative trade-off :)

from wiki.

Now that chrome has cache partitioning I dont know how useful it will be.
For detection it is possible to use window navigation timings however there more annoying as they need window.open

from wiki.

Yes of course. But as far as I know only Chrome has implemented cache partioning. So this could be a further point in convicing to implement it.

@terjanq @arturjanc @sirdarckcat

from wiki.

I have used images for cache detection in the past it seems that they sometimes get blocked as tracking pixels by privacy badger that may have changed now. Anyway it seems to not provide much of a benefit over other options.

from wiki.

Interesting property indeed. Although it seems to be quite equivalent to timing onload/onerror, do you see any advantages for img.completed over these events? Per my testing, it only yields instantly loaded if the resource comes from the memory cache. The disk cache takes much longer to perform. Tweaked the snippet a little bit:

async function load_and_check(url){
	var img = new Image();
	img.src = url;
    await new Promise(r=>setTimeout(r,50));
	return img.complete;
} 

await load_and_check('https://terjanq.me/xss.php?h[Cache-control]=max-age=10&html=123')
// false
await load_and_check('https://terjanq.me/xss.php?h[Cache-control]=max-age=10&html=123')
// true

What's nice about this technique is that it also works for other resources than images.

Images often go to memory cache for faster loads. Here is a comparison between html document and image.

from wiki.

Hi @terjanq thanks for the answer.
I've thinked about it a couple of days, but honestly I've not found particular advantages to use image.complete property instead of onload/onerror events. The only thing I think is peculiar of this method is that timers aren't needed: this could lead to an advantage if will come a moment in which browser vendors decide to change the resolution of the performance.now() return value (such as FireFox already does) in order to try to mitigate different kinds of timing attacks.
Unfortunately the question of memory cache is another limitation of this method. In this days I've thinked also about this point and I come up with "an idea": I did not try to do this, but i believe that the logic of the attack can be overturned. What I mean is: do not try to understand when the resource is loaded from cache (since, as we said, this method will work only with memory cache and not with disk cache), but try to understand when it can not be downloaded from web. I believe that this can be done by enlarging the timeout to a value higher than the time needed for loading from disk memory but smaller than the time needed for the download from web and check if the image.complete property returns false.
Let me know what do you think about it :)

from wiki.

As much as I like the idea, adding this to the wiki would add more content to read while not providing clear advantages over other methods. What we could have done though is to reference it to external article/mdn article near onload/onerror article. Something like: An alternative way could be to use image.complete property.

from wiki.

I agree with you, an entire "paragraph" is too much only for this method. Unfortunately we do not have external articles which explains this method to reference to. Anyway, since there are still differences with the "classical" timing attack, I believe that can be added a couple of additional information to not create confusion in readers. Something like:

An alternative way could be to use image.complete property.

async function load_and_check(url){
	var img = new Image();
	img.src = url;
    await new Promise(r=>setTimeout(r,50));
	return img.complete;
} 

The peculiarity of this method, differently to timing onload/onerror, is the independence from both network performances and JS timer resolution.

I hope this can fit for you.

from wiki.

This attack is network dependent because If the request is completed before the 50ms setTimeout it will return true.
An example of a resource this does not work with is https://http.cat/images/200.jpg
Does img.src = url provide a delay before continuing?

from wiki.

Thanks for the observation, you are right, if the request is completed before the 50ms then of course it will return true. Maybe I was not so clear when I said "independent from network performances": with this sentence I mean that this method do not needs time thereshold to work. The point is that an attacker must choose "the right resource" to exploit this method (I mean a resource with a size which will take some time to be downloaded and much much less time to be loaded from cache). Due to its limits image.complete will not work with 0% failure tolerance with a resource whatever.
About img.src, I'm sorry but I don't know if it deliberately introduce delay.

from wiki.

I think in your code the max time thereshold is 50 after that it if the image has been loaded in time it will return true
There seems to be enough cache checks already:
https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller
https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events
https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources
#102

from wiki.

I am against putting a snippet because it gives more confusion than explanation. It's not clear at all how and why it works, and I had to spend some time myself to learn how this property works, and why if the request goes from the memory it's set to true even though it should not have to, because the next operation should be executed immediately after that. This is a weird race condition on multithread/(processor?) and RAM is fast enough to load it directly.

In my opinion, the technique is nice, but it's overcomplicated for the wiki unless we make a full paragraph about it, which as we all pointed out, does not bring many advantages over other presented techniques. I'd be happy to refer to some external paper or article or provide an explanation in a footnote but be clear about the fact that it's more of a curiosity.

from wiki.

Unfortunately there aren't external paper/article about it to point to at the moment... I wrote about it in my master thesis (no much more than what i wrote here) but university (don't know why) do not provide an on-line catalogue for thesis (they pretend you have to go to library to read them) so there isn't another on-line place where read about it.
For now, if you want, you can add the sentence that "reveals" it, if in the future there will be something more to add, I will provide it.

from wiki.

Im guessing this can be closed now.

from wiki.