FYI: CSS-only tracking [moot], CSS Injection [use CSS Exfil Protection]

[Thorin-Oakenpants]

snip

[Atavic]

Same for me.

[overdodactyl]

I'm glad you posted this update Pants...I was sitting here trying to figure out what could have spoofed your results haha.

I am trying to work out what is protecting me from the css detection for each one.

I'm curious of this as well, as the test page successfully picks up my hovering, for example.

Do you have css from crookedss.bplaced.net blocked via uMatrix? This is the only way I could prevent it, but that seems like cheating in this case :)

[Atavic]

Huh, I don't have Calibri font BTW

[overdodactyl]

Not sure if cookies are required to allow the reporting side - I enabled them in my main FF and still didn't get picked up.

Cookies are needed...I turned them off and nothing got reported

[Atavic]

The test page hacks a .php call from the .css (actually the main.css invokes screen.css and that invokes the php call).

/* 1406 should block the @font-face call in screen.css

[overdodactyl]

Thanks for testing!

I am not sure if that means it is not reported (but still detected)

I would have to imagine it's only the reporting that's getting effected here, not the ability to track what's going on.

---

On the cookie note (totally un-related to the css tracking)...with FPI and extensions now being able to handle cookies in isolation, do you think it's worth considering allowing first-party cookies by default? Some fingerprinting test sites indicate blocking all cookies reveals a decent amount of info:

Panopticlick:

First-party cookies allowed:

• 0.2 bits of identifying info, 1 in 1.15 browsers have this value

All cookies blocked:

• 2.97 bits of identifying info, 1 in 7.81 browsers have this value

I recently switched to allowing first party cookies + FPI + CAD to delete non-white listed cookies on tab close...not sure if that was a wise move though haha

[overdodactyl]

Just glancing at the comments in gorhill's issues it doesn't sound like there can be much done about this either. I agree though, the information that could be gathered from this isn't that worrisome.

---

Thanks for the insight on the cookies! It appears I severely underestimated the consequences of turning them back on haha. I didn't realize how tied into other storage it was (haven't done my due diligence in looking into local stroage/IDB yet).

I've taken your advice, deleted the sqlite db, and blocked cookies again.

I would consider allowing 1st party by default ONLY when sanitize is fixed, and storage manager is fixed, and extensions can clean ALL persistent storage types by host AND by time range.

Perhaps we can re-visit this way way down the road then haha.

Really do appreciate the help though!

[overdodactyl]

As for the FP'ing items: the only one that I care about is the font. Is this a new way to load system fonts?

This method wouldn't be terribly informative though, would it be? The css approach only seems to tell you about the presence of a generic font family, nothing more specific. Or am I misunderstanding?

[Atavic]

Yes, it has only one entry called Calibri.

[overdodactyl]

Thanks!

[overdodactyl]

That sounds like more of a mess than I'm ready to try and sort out 😬

[theWalkingDuck]

I'm still intrigued as to WHY the external site links require a cookie.

You're sending a hidden request when you click that link. (see the uMatrix logger)

The link element becomes active when you click it and that fires a request to
http://crookedss.bplaced.net/track.php?action=link1_clicked
The cookie is needed for this (hidden) request not for the external link.

(the :active selector acts like a JavaScript onclick event)

#link1:active {
      content: url("track.php?action=link1_clicked");
}

[crssi]

Isn’t cookies here just for simplifying demo? Server knows when you have clicked/howered/whatever, but has to bind it to session/user somehow. In this case the cookie it is but instead of cookie there could be also somesort of url tracking parameter or other means of FPing. IDK, just thinking out loud. ;)

[earthlng]

Server knows when you have clicked/howered/whatever, but has to bind it to session/user somehow.

this.
It uses PHP sessions to store the information on the server and the cookie contains the ID that identifies your session.

[crssi]

^^That is what I meant. IMO: Since its just POC demo, the user ID is simplified over cookies.

[Atavic]

CSP is overridden here by pure browser's flaws. Most cases involve 3rd parties, but coredump link below says that it can happen on a 1st party site, via non-secure requests.

The limits of exfiltration defenses, see 2.6. Addendum

Following quote is from an article about Clickjacking, but talks about these CSS Injections:

By allowing a page to be framed, it is possible to perform multiple POST requests to an application across origins, which can for example be used in multi-stage CSRF attacks or in the exploitation of CSS injections.

Exploitation of other vulnerabilities via Framing

It ends with three different approaches to defend against Clickjacking

Content Security Policy (CSP)
X-Frame-Options (HTTP Header)
Frame-Breaker Script (JavaScript)

Related: #319 (comment)

[grauenwolfe]

all the below from @grauenwolfe in the sticky extensions issue

Yeah, I mentioned this in sticky:extensions a few days ago, just now getting back to see the follow-up. Anyway, the more I looked into it I suspect that it isn't too great of a threat, not just yet, if ever. Most of the testing scenarios were tailor made, relying on specific and "one-in-a-million" type situations.

However, it is there and it can be done, and possibly expanded upon in the future. Not basing that on anything specific other than the natural swing of things.

No problem if you feel it should be removed from the sticky:extensions list until it becomes a more pressing threat.

[earthlng]

//github.com/mlgualtieri/CSS-Exfil-Protection/pulls

[overdodactyl]

but all I want to know is how to minimize the threat against this - eg blocking 3rd party requests

Blocking 1st party images via uM works in this case

[crssi]

^^Why didn't you say: not browsing the web works in this case 😄

[overdodactyl]

Because blocking first party images from sites you don't trust or where they aren't needed is actually a reasonable, and arguably a worth while, approach to take.

Take Reddit as another example. The only first party image it has is a tracking pixel:

reddit.com/static/pixel.png

[crssi]

I don't understand this tracking pixel. Is for everyone different color, or how the tracking works?

[Atavic]

reddit-archive/reddit@3ddf15d

Creative Manipulation of HSTS Policy Store

Since an HSTS Host may select its own host name and subdomains thereof, and this information is cached in the HSTS Policy store of conforming UAs, it is possible for those who control one or more HSTS Hosts to encode information into domain names they control and cause such UAs to cache this information as a matter of course in the process of noting the HSTS Host. This information can be retrieved by other hosts through cleverly constructed and loaded web resources, causing the UA to send queries to (variations of) the encoded domain names. Such queries can reveal whether the UA had previously visited the original HSTS Host (and subdomains). Such a technique could potentially be abused as yet another form of "web tracking" [WebTracking].

See: #102 (comment) #363

[claustromaniac]

I don't understand this tracking pixel. Is for everyone different color, or how the tracking works?

ETags, probably.