CORS error on Origin Reflection misconfiguration

[Brasco]

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.

[NDevTK]

https://xsleaks.dev/docs/attacks/cache-probing/ used to be reliable and does not use error events but now fails for chrome due to https://github.com/xsleaks/wiki/issues/102 Does your version work with the partitioned cache?

[Brasco]

This is a cache probing technique and for that reason wont work with partitioned cache.

[NDevTK]

https://github.com/xsleaks/wiki/issues/102 seems to still work after the partitioned cache maybe its also possible to get something purged from the cache while staying on the right origin.

[Brasco]

IMHO in #102 you use window.open so requests are done with an other orign henche bypassing cache partitioning. I am trying to figure out if combining window.open technique with this new one could lead in an other cache partitoine bypass...but i am not sure... I will keep you updated.

[Brasco]

no, definetely I think that is not possible because this vulnerabiltiy is based on an error due to cross-origin requests so is not possible to detect this behaviour with a request starting from the same origin...

[NDevTK]

Ok, for purging it seems like it would require the ability to reload a page bypassing cache.

[NDevTK]

Im not responsible for new content being added hopefully this gets seen by https://github.com/orgs/xsleaks/people

[Brasco]

hopefully! thanks maybe I can tag them: @terjanq @arturjanc @sirdarckcat

[arturjanc]

I'd defer to @terjanq but this seems like a useful technique which could at least merit a short paragraph in the cache probing article. Would you be up for sending a PR?

[Brasco]

Yes we have the code ready for the PR!

[terjanq]

This is an interesting vector and surely fits into the wiki. Although this indeed seems kind of mitigated with the partitioned cache rolled out.

[Brasco]

Yes, for sure is mitigated by cache partitioning. But as far as I know only Chrome has implemented cache partioning. So this could be a further point in convicing to implement it.

However if you think it could fit in your wiki let me know if i should somenthing (PR o r whatever ;) )

[NDevTK]

Firefox has a flag to enable it. It does seem like a Access-Control-Allow-Orign header reflecting a different origin maybe unexpected behavior.

[Brasco]

Yes, origin reflection is a misconfiguration. Hovewer still some of the most common web frameworks use it as default. Infact, at the time of our experiments we found out that the the 0.16% of top Alexa web sites have this misconfiguration. Low percentage but still an interesting absolute number.

[terjanq]

However if you think it could fit in your wiki let me know if i should somenthing (PR o r whatever ;) )

Pr would be nice :)

Low percentage but still an interesting absolute number.

I wouldn't care too much about "usefulness" of a technique. This wiki is intended to highlight interesting leaks and misconfiguration of CORS on static resources potentially harmless is a nice showcase of xs-leaks.

[NDevTK]

Can this be closed now since https://github.com/riccardomerlano/wiki/pull/3 was merged?