Re: [csswg-drafts] [selectors][css-values] Hide "sensitive" attributes from CSS (#5136)

> Is it a goal for CSS that using a stylesheet from an untrusted source is "safe" in some sense?

I think the goal is to walk a fine line of enabling CSS to ship new, useful features, while preventing security regressions due to the increasing expressive powers of stylesheets, especially as they start approaching the capabilities of scripts. Restricting stylesheets' ability to access sensitive data in the DOM seems like a compromise that can allow this to happen, because it reduces the potential damage of loading CSS outside of the application's control.

It's certainly generally true that developers *shouldn't* load arbitrary untrusted CSS, but -- in practice -- since the capabilities of stylesheets are lower than the capabilities of scripts, there are many situations where this can still happen. For example:
- Loading from CDNs: An application may only load scripts from its own origin, but trust a CDN enough to deliver CSS.
- Sanitized HTML: In many cases HTML sanitizers have codepaths to allow styles (often, just for `style` attributes, but sometimes for `<style>` blocks). Some sanitizers are lax and allow the use of any CSS function; this is fine if the worst that can happen is that the style calls `calc()`; less so if it can call `extract-all-attribute-values-and-send-to-evil-dot-com()`.
- Content Security Policy: A lot of CSPs are much stricter about controlling scripts than stylesheets, in part because the ubiquity of `style` attributes makes it very difficult to ship a CSP with a `style-src` without `'unsafe-inline'`. This is okay if injected CSS is limited in its capabilities, but becomes a problem when CSS gains access to arbitrary data on the page.

So it's not really "make untrusted CSS safe to include", but rather "don't make it significantly more unsafe than it currently is".





-- 
GitHub Notification of comment by arturjanc
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5136#issuecomment-674286285 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 14 August 2020 21:49:05 UTC