miketaylr
commented
4 weeks ago Ah very interesting! (and now you can tell I only skimmed the article before I shared it with you 🙈).
I think we might want to drop this filtering and consider also navigations that resulted in an error as eligible for :visited styling.
This sounds reasonable to me - I wonder what the tradeoffs are (if any).
Context: https://jorianwoltjer.com/blog/p/hacking/xs-leaking-flags-with-css-a-ctfd-0day
This issue is somewhat separate from the privacy leaks that we've been thinking of, but it's an interesting gap in the security properties of partitioning so I want to make sure we think about solutions.
In a nutshell, links are styled as visited only if a navigation resulted in a 2xx HTTP status code, and are not styled as visited if the navigation received a 4xx error response. This means that
evil.comcan navigate to arbitrary URLs onvictim.comand only those URLs that resulted in a successful navigation will be highlighted as visited. Then, based on which links are styled as visited,evil.comcan know which resources onvictim.comexist and can be accessed by the user (which is sensitive information because servers frequently have access control mechanisms that allow a given user to access resources such asvictim.com/[username]/data.json, but deny access to everyone else).The reason partitioning doesn't solve this is that evil.com is the entity that navigates to the chosen URLs (which can be done in a hidden popup and repeated many times). The links will then be styled as visited on evil.com, meaning that evil.com will be able to read their styling using the usual leaks. The root cause of the problem is that we're filtering entries with 4xx response codes from the visited table, which leaks the status code for cross-origin endpoints. I think we might want to drop this filtering and consider also navigations that resulted in an error as eligible for :visited styling.
/cc @terjanq @miketaylr