15 comments

[ 2.1 ms ] story [ 42.9 ms ] thread
Wow, so someone thinks XSS matters anymore. How quaint. I, too, remember 2008. Meanwhile, in the current year, we have the Chrome Web Store where thinly veiled de facto UXSS data harvesting plugins pretending to be innocent useful tools are installed by tens of millions of gullible people for whom these insidious hacking vectors are normalized, and no one cares even after their passwords and credit cards have been sent to a C&C server in Tel Aviv.
Does Google not review the extenstions? Or is it using just some automated easily gameable review system?
AFAIK there's no review system, unlike firefox addons.
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.
There is no review system. There is a brief delay in publishing but only due to some sort of automated process. Not that it would matter if they reviewed it, since it’s easy to obfuscate things. I knew “someone” with a Chrome extension that had over 80k users and it would hijack the users’ reddit accounts to silently issue spaced out fake upvotes via commands issued by a C&C server. The users were being utilized as vote bots to force things to the front page. This went on for over a year and only stopped because the person lost interest in doing it.

Any popular extension that asks for access to all site data can and will do terrible things without telling you. They can and will embed secret scripts in all your sites that do whatever they want. In 2008 we called this UXSS, now we call it a feature. The Hola bot net fiasco is a good example of this. Popular extensions like Grammarly are obviously doing something incredibly shady too, how else can a free spell checker afford a massive polished ad campaign and earn tens of millions of dollars. It’s okay though, they won’t get in trouble because a short phrase on page 1273 of their EULA grants them permission to do so.

Anyone saying the solution is to pay close attention to the permissions dialog and refuse to install anything asking for full access to all sites is likely on the spectrum and has no clue how 99% of ordinary people think or act.

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.
Use one XSS, like reflected URL parameter, to store the code to localStorage for locally persisted XSS. Looks like fun.
Highlights, to me:

- do not trust localStorage

- 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.
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.

You have two tee shirts and some random dude on hacker news eternal gratitude — me.
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.