W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2018

Re: [csswg-drafts] [css-syntax] Consider disallowing NULL code points in stylesheets

From: Simon Sapin via GitHub <sysbot+gh@w3.org>
Date: Mon, 02 Jul 2018 11:12:50 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-401770957-1530529969-sysbot+gh@w3.org>
I believe that an HTTP(S) document would not be allowed to fetch a `file:` URL at all, but I couldn’t find that being specified. Can someone confirm either way?

At least, such a request would be cross-origin. Per https://drafts.csswg.org/cssom/#style-sheet-association, a cross-origin stylesheet is not applied to the document if it does not have an appropriate `Content-Type`.

Same-origin resources are not relevant here since they can be fetched with `XMLHttpRequest` anyway.

So the problem this proposal is trying to solve is: protecting against exfiltration of a cross-origin resource that is not intended to be CSS but still served as `text/css`. Regardless of whether this is a problem worth solving in the first place, we cannot know intentions for sure so at best we can guess with a heuristic.
We could imagine many different heuristics for “might not be intended as CSS syntax”. Using presence of U+0000 seems very arbitrary. What about other control code points? (U+0001 to U+001F except whitespace). Assuming UTF-8 decoding, what about 0xFF bytes? Or other byte sequences that are not well-formed UTF-8 and decoded as U+FFFD at that layer?

For any given heuristic, what is the risk of false positive? Even if there is no useful reason to deliberately make a stylesheet that contains { nulls, controls, 0xFF, ill-formed UTF-8, whatever }, is the reduction of exfiltration risk worth breaking real stylesheets where it happens accidentally?

GitHub Notification of comment by SimonSapin
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2757#issuecomment-401770957 using your GitHub account
Received on Monday, 2 July 2018 11:12:53 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:26:51 UTC