Re: [ServiceWorker] "no-cors" CSS SOP violation (#719)

I don't think we should prevent requests coming from a no-cors stylesheet from going through a SW.

Yes. I understand that this exposes data that isn't currently exposed. And yes, I understand that there is some security risk involved in that. But I don't think that automatically means that we must not do this.

In short, I think the question is more complex and nuanced than that.

Currently, if I host a file on a webserver and serve it with a "text/css" mimetype, *a lot* of the data in that file can be read by third parties.

A third party can link to that stylesheet, create an element which matches one of the rules in the stylesheet, and then use getComputedStyle to figure out the properties that were set by the rule, and what those properties were set to.

You can relatively easily use a dictionary to scan probable class names to extract all rules that simply match on a class. You can even scan all possible ascii-classnames shorter than N characters.

That means, that as an author, if I put a text/css resource on a webserver, I already need to count on that most of the bytes in that file is readable by third parties.

It's also not as simple as "exposing more data" == "less safe for developers".

Trying to send developers the message that "these here bytes are leaked, but these other bytes, in the @import rule, those are safe, feel free to put sensitive data in those URLs" is a significantly more complex than saying "the contents of the stylesheet can be read by third parties. Don't put sensitive data in stylesheets". Such complexity often leads to security bugs.

For example, the fact that background-image URL isn't exposed to a SW might make developers think that the URL is protected, when in fact .getComputedStyle leaks the very same information. I.e. it is very easy for developers to get a false sense of security. This is also made worse by the fact that developers can legitimately claim that some urls, like @import, are in fact safe.

Then there is of course the problem that the implementation complexity will most likely lead to a few security bugs here and there. We had a recent example of this where a developer had seen that CORS says that only certain values can be sent in the Content-Type header without triggering a preflight. So the developer built CSRF-protection by checking for a particular content type. However it turned out that different browsers apply slightly different rules to Content-Type parsing leading to the ability for an attacker to send a cross-site request in some browsers with a Content-Type that this website didn't expect.

The Content-Type rule in CORS is my fault. I think it was a bad decision and it has lead to security problems.

What we're talking about here is orders of magnitude more complex, and so I feel quite confident that it will lead to orders of magnitude more problems. Both security problems and other problems.

And yes, I am aware that we block access to the CSSOM for cross-origin stylesheets that weren't fetched with CORS. But that was added because at the time we didn't have the restriction that the stylesheet had to be served as "text/css". The attacks that we saw was due to websites pointing <link rel=stylesheet> at cross-origin HTML files, and then took advantage of the lax CSS parsing rules to extract information from the HTML.

So, all in all, I think the cost here is quite high to browser developers, as can be seen by all the edge cases that are being debated. I agree that there is some security value to developers, but I also think there is a very real security risk to developers (in addition to the cost of not being able to intercept CDN hosted stylesheet resources).

And again, I realize that more information is being exposed here. If your counter argument is simply that that means that we have to block these intercepts, then you might want to reread this comment.

I think we would be better served giving developers a real security tool here. I know that @annevk had a proposal some time back for a header which blocked cross-site reads of resources like images/stylesheets/scripts. Implementing something like that seems like a better way to protect the data debated here.

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/719#issuecomment-150665556