The Brave Browser is vulnerable to CSS Exfiltration attempts, may leak PII.

[Peacock365]

Description

The Brave browser is, just like other Chromium-based browsers and Firefox, vulnerable to CSS Exfiltration attempts. This is a very serious privacy threat and should be given the highest priority. Mr. Mike Gualtieri has done research in that area, as described here:

https://www.mike-gualtieri.com/posts/stealing-data-with-css-attack-and-defense

I quote from this link:

"A method is detailed - dubbed CSS Exfil - which can be used to steal targeted data using Cascading Style Sheets (CSS) as an attack vector. Due to the modern web's heavy reliance on CSS, a wide variety of data is potentially at risk, including: usernames, passwords, and sensitive data such as date of birth, social security numbers, and credit card numbers. The technique can also be used to de-anonymize users on dark nets like Tor. Defense methods are discussed for both website operators as well as web users, and a pair of browser extensions are offered which guard against this class of attack."

Everything else is thoroughly explained on the website I just linked to. This is a grave threat to privacy, as it bypasses all of Brave's anti-tracking measures and may lead to people being identified even when using Brave's Tor windows (Well, I know that Brave's Tor windows are not comparable to the actual Tor browser, but still, they shouldn't be as easily bypassed as this).

Mr. Gualtieri has created an extension that fends off such attacks, saying that he hopes that browsers will at one point take care of the leak, rendering his extension redundant:

https://github.com/mlgualtieri/CSS-Exfil-Protection

The code of this extension may be an inspiration for a fix on part of the Brave team. I use the extension in Brave (I also allow it in private windows), and I am no longer vulnerable. That being said, since Brave's Tor windows do not allow for extensions to run, I am once again vulnerable when using Tor windows.

Steps to Reproduce

1. Go to the following website: https://www.mike-gualtieri.com/css-exfil-vulnerability-tester

Actual result:

Brave is vulnerable to CSS Exfiltration attempts.

Expected result:

Brave shouldn't be vulnerable to CSS Exfiltration attempts.

Reproduces how often:

Easily reproduced.

Brave version (brave://version info)

Brave	1.9.76 Chromium: 81.0.4044.138 (Official Build) (64-bit)
Revision	8c6c7ba89cc9453625af54f11fd83179e23450fa-refs/branch-heads/4044@{#999}
OS	macOS Version 10.15.5 (Build 19F96)

I use Brave on macOS, but it is reproducible on all OSes, including Android.

Version/Channel Information:

I use the stable channel, but it is reproducible on all channels.

Other Additional Information:

Is the issue reproducible on the latest version of Chrome?

Yes.

Miscellaneous Information:

Please give this a very high priority, private information may be leaked by Brave despite all of its protective measures, CSS Exfiltration also compromises the anonymity of Brave's Tor windows. It might also be a good idea to contribute any fix you might create to Chromium upstream, and the team behind the Tor browser should perhaps be informed.

[srirambv]

cc: @brave/sec-team

[diracdeltas]

am i understanding correctly that this attack only works if a website has included CSS from a malicious party?

it seems the takeaway here is "3rd party CSS should be treated like 3rd party JS"

[Peacock365]

@diracdeltas

To my understanding, the website can also create such CSS by itself, in order to use it as a reliable tracking method when anything else (classic tracking scripts etc.) fails. But yes, most likely an attacker could insert something like this from outside.

it seems the takeaway here is "3rd party CSS should be treated like 3rd party JS"

The takeaway (IMHO) is that CSS rules must be sanitized (this is what the extension I linked to in my original comment does):

"Each plugin works by pre-processing the CSS which is loaded onto a web page. Inspection and sanitization of each CSSRule is done through the browser's native CSSStyleSheet JavaScript API. If a CSSRule.selectorText is detected that: 1) Parses the value attribute of an element, and 2) If the corresponding CSSRule.cssText includes a call to a remote URL, a new rule is created to override the call to the remote URL.

Some additional processing is required for cross-domain stylesheets, as CSSRule properties are not available. Accessing cross-domain CSSRule properties violates the browser's native CORS Security Policy. To properly sanitize cross-domain stylesheets, a temporary same-origin stylesheet is created, sanitized, and removed. Chrome also requires temporary blocking of some CSS to prevent the loading of cross-domain resources awaiting sanitization. The Firefox implementation had additional complications, but in the end works very similar to the Chrome version.

I've been using various forms of the plugin in my browsers for weeks now and haven't noticed any visible performance hit or glitches when loading pages."

...according to Mr. Gualtieri.

This is what Brave should be doing natively, to avoid data leaks. I am using the extension currently and I don't witness any kind of breakage on any websites, and yes, I am visiting the big ones (eBay, Amazon, Facebook, Google, YouTube... you name it).

[Peacock365]

Here is a link to the relevant code of the extension:

https://github.com/mlgualtieri/CSS-Exfil-Protection/blob/master/chrome/content.js

[Peacock365]

So, was this issue evaluated yet? It's quite a big deal, yet I see relatively little progress here. Any news?

[diracdeltas]

To my understanding, the website can also create such CSS by itself, in order to use it as a reliable tracking method when anything else (classic tracking scripts etc.) fails

cc @pes10k . i think if this is the case this could be included in the fingerprinting protection setting.

[pes10k]

Hello @Peacock365. We appreciate the issue, but we don't think this attack poses significant risk to users, for a couple of reasons:

1. In order for an attacker to inject new CSS rules, they'd need to be able to execute JS on the page. At that point, the user already has access to much more powerful exfiltration options.
2. In cases where JS is blocked, the attacker would be limited to trying to bruteforce / guess possible values for the identifier, making the attack infeasible for non-trival-length values.
3. Brave block 3p. cookies, so, unlike some other browsers, just triggering a network request isn't enough to identify a user.

All that being said, we appreciate the point that powerful CSS selectors carry with them privacy risk that might not be obvious, and so thank you very much for raising the issue!

[Peacock365]

You may want to re-evaluate this in light of this:

w3c/csswg-drafts#5136

[pes10k]

Thanks for the ping @Peacock365 . I don't think the comments in that issue change the analysis here, but I'm glad the WG is considering the issue at least, and i think the points Tab makes in the original issue text are correct.

I also think the points made in w3c/csswg-drafts#5136 (comment) are correct, and that its 1) both worth trying to make "CSS less dangerous than JS" and 2) beyond the scope of what the WG is consdering curently.

Thank you again for the pointer here though. I'll keep my eye on things! Much appreciated