Discovered a cookie-persisted version of this at a large multi-national (Global Fortune 100). It affected almost all of their SSO pages. They all had multiple XSS issues, and then they read from a cookie and then wrote that value to the page inside some Javascript(!), so I was able to persist the XSS on the user's machine indefinitely (until they cleared their cookies).
The result was the ability to capture user credentials at any of their login portals, and the "infection" mechanism would have just been the victim clicking on a link to one of their login portals.
The company has a bug bounty that awards "schwag", which I knew going in. So now I have two of the same really dumb t-shirts.
- quote: The most challenging pattern in our dataset consists of scenarios in which applications use the persistence mechanisms to deliberately store HTML or JavaScript code, e.g., for client-side caching purposes. In this setting, the attacker is able to completely overwrite the contents of the corresponding storage entry with their own code. We could identify in several cases these flaws are actually introduced by third-party libraries, among them CloudFlare and Criteo.
Isn't "do not trust localStorage" another variant of "do not trust the client"?
Taking client-controlled storage and inserting it unsafely into the DOM sounds like a bad idea, although it's not something that is popularly discussed as a trust boundary so awareness is key (this article is a great example).
Exactly so. The use case of Local Storage is usually “application cache.” When you’re building out features, it may not even be obvious that you’re injecting application state _that originated in localStorage_ into the DOM. That’s why this is such an easy problem to fall into.
The proposed solution, to use the ServiceWorker as a trusted cache, is OK when you own the entire origin. Unfortunately, for 3rd parties this is not an option. There can be only one global ServiceWorker per document/scope. Clobbering the global one by a third party would be unwelcome by page owners, and there's no standard for graceful cooperation here.
Just because some users do insecure things doesn't mean that I get to do insecure things as a developer. They can choose to take security risks with their data. I cannot choose that for them.
Not true. With expanded permissions (like access to all browser tabs), you will be subject to a full code review. I've had to wait anywhere from 2-5 business days before a draft extension was allowed to be published.
The result was the ability to capture user credentials at any of their login portals, and the "infection" mechanism would have just been the victim clicking on a link to one of their login portals.
The company has a bug bounty that awards "schwag", which I knew going in. So now I have two of the same really dumb t-shirts.