W3C home > Mailing lists > Public > public-css-archive@w3.org > May 2020

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

From: arturjanc via GitHub <sysbot+gh@w3.org>
Date: Sun, 31 May 2020 09:51:12 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-636447864-1590918671-sysbot+gh@w3.org>
A small note that script nonces are already hidden from CSS as a result of https://github.com/whatwg/html/issues/2369 and https://github.com/whatwg/html/pull/2373; my guess is that for sensitive attributes we may need a different approach though.

In general, I'd be very happy with this change (it's strictly security-positive), but I'm not convinced that it's sufficient to safely enable something like `concat()`. Modern applications use a large number of custom attributes and sensitive strings can appear in any attribute, e.g. `data-user-config` can have a JSON object with metadata about the user, including a CSRF token or other secrets. A blocklisting approach for a set of "native" attributes will not cover many instances where sensitive data is available in attributes outside of that list; this will increase the risk for existing applications with such patterns.

It would be helpful to at least consider an alternative allowlist-based approach where by default we permit only certain attributes to be accessed from CSS (e.g. ones that seem likely to be useful for developers, anything with a custom new prefix such as `css-foo`, etc). Such an allowlist could even be arbitrarily extended by application developers via a JavaScript API -- allowing adding custom CSS-accessible attributes in JS wouldn't be any less safe than the status quo, because an attacker with the capability to execute scripts can already obtain any information from the DOM.

GitHub Notification of comment by arturjanc
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5136#issuecomment-636447864 using your GitHub account
Received on Sunday, 31 May 2020 09:51:14 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:07 UTC