3rd party CSS, Font, XHR, IMG and JS reveals your browsing site by request header 'Origin' attribute

[crssi]

Most 3rd party CSS, Font and JS reveals you browsing site by request header Origin attribute.
I know that a lot of you block fonts by default and JS sometimes or most the times, but most of you do not block CSS.
So it might be of your interest to remove Origin attribute from request header for CSS and Font.
JS (and XHRs too) can be covered by good uBO blocklists.

You can use Header Editor web extension to remove those.
Rule type: Modify the request header
Match type: All
Execute type: Custom function
Code:

if (detail.type === 'font' || detail.type === 'stylesheet' || detail.type === 'image') {
	for (const header of val) {
		if (header.name.toLowerCase() === 'origin') {
			header.value = '';
			break;
		}
	}
}

We need an additional rule to work in pair with upper script:
Rule type: Modify the response header
Match type: All
Execute type: Custom function
Code:

if (detail.type == 'font' || detail.type == 'stylesheet' || detail.type === 'image') {
	for (const header of val) {
		if (header.name.toLowerCase() == 'access-control-allow-origin') {
			if (header.value == "null") { header.value = detail.originUrl.split('/', 3).join('/'); }
			return;
		}
	}
	val.push({'name': 'Access-Control-Allow-Origin', 'value': detail.originUrl.split('/', 3).join('/')});
}

What I don't know is, how much this action could add to unique fingerprint in a real world.

From logging traffic in a week of browsing, I could not find single case where Origin attribute would be used in XHR requests to the addresses of the different owner as the browsing site is.

This issue is a follow up of #506

[earthlng]

but most of you do not block CSS.

that's because the number of sites that use someone else's CSS is slim to none (except for google fonts and as you already noticed in most or all cases those don't leak origin). So in that sense origin doesn't leak anything that the CDN doesn't already know anyway, namely that a certain CSS belongs to a certain site. But regardless of that I personally only allow 1st party css by default anyway.

CORS are always XHR as far as I know

github uses <link crossorigin="anonymous" media="all" integrity="sha512..." rel="stylesheet" href="https://....css"> and AFAIK that's CORS as well so it's not just XHR.

That being said, I'd expect a rule like this to cause some breakage, but I agree that the Origin header is a tracking vector, so I think this sure is worth investigating/testing more.

👍

[KOLANICH]

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

What requests use CORS?
This cross-origin sharing standard is used to enable cross-site HTTP requests for:
Invocations of the XMLHttpRequest or Fetch APIs in a cross-site manner, as discussed above.
Web Fonts (for cross-domain font usage in @font-face within CSS), so that servers can deploy TrueType fonts that can only be cross-site loaded and used by web sites that are permitted to do so.
WebGL textures.
Images/video frames drawn to a canvas using drawImage().

[crssi]

that's because the number of sites that use someone else's CSS is slim to none

Sadly far from what I see. Maybe you see it that way as you block most 3rd party's. For someone who does not, the reality is different.

Origin header should only be present in XHR (XMLHTTPRequests) anyway

As we see, its not in the real world. Even github is using Origin in a websocket requests.

[earthlng]

but it's not really someone else's CSS, is it? It may be hosted on some CDN but it's only used by that site, no? I mean who would use someone else's CSS for his/her own site? that's just silly. The 3rd party changes something and all of a sudden your page looks different? really?

[Atavic]

CMS Templates are shared by many different sites.

[earthlng]

I guess that's possible but arent' templates usually installed into the CMS and then hosted and served by the domain using the CMS?

btw according to https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_settings_attributes even <img>s can leak the origin

[Atavic]

It may be hosted on some CDN but it's only used by that site, no?

Wordpress Themes are used by many, as Joomla, Blogger, even Jekyll on GH Pages.

[crssi]

We need additional rule for CORS... see #506 (comment)
Rule type: Modify the response header
Match type: All
Execute type: Custom function
Code:

if (detail.type === 'font' || detail.type === 'script' || detail.type === 'stylesheet') {
   for (let a in val) {
      if (val[a].name.toLowerCase() === 'access-control-allow-origin') { return; }
   }
   val.push({'name': 'Access-Control-Allow-Origin', 'value': detail.originUrl.split('/', 3).join('/')});
}

What we do here is to check if CORS is set, in that case we do not alter anything.
If is is not set, then we add it and set to the schema+domain of the response server for CORS.

We might get some better performance with regex for the line (@claustromaniac help 😄)

   val.push({'name': 'Access-Control-Allow-Origin', 'value': detail.originUrl.split('/', 3).join('/')});

Test page (note the icons with or without this additional rule): https://gitlab.com/labwrat/Firefox-user.js/tree/master

OT: @earthlng... for better performance add break; for eTag rule, after clearing eTag 😉, I don't think there is a need to roll over all headers when after a hit is found.

Still in ToDo: XHR, WebSocket, IMG.

Cheers

[claustromaniac]

We might get some better performance with regex for the line (@claustromaniac help 😄)

It seems the pattern is too simple for a regex to give a significant performance benefit here, at least on my end (YMMV). You can test here if you want:

• benchmark very close to reality
• simpler benchmark

Another alternative (didn't test this one):

val.push({'name': 'Access-Control-Allow-Origin', 'value': (new URL(detail.originUrl)).origin});

Hm.. I'm wondering, though. Isn't detail.originUrl always meant to be only the protocol + domain (+ port)? Gotta check that. If that's the case we just need to do:

val.push({'name': 'Access-Control-Allow-Origin', 'value': detail.originUrl});

EDIT: NVM, it's not. I just tested it.

[claustromaniac]

OT: @earthlng... for better performance add break; for eTag rule, after clearing eTag 😉, I don't think there is a need to roll over all headers when after a hit is found.

If performance is not a concern, not breaking out of the loop is safer because servers can include multiple ETag headers in the responses if they want. It's not common practice, but it is technically doable.

The same goes for Access-Control-Allow-Origin and all other response headers, AFAIK.

In the case of the Origin header, breaking out of the loop like you did in your rule is perfectly safe because it is a request header (the browser will not send multiple Origin headers in the same request).

[claustromaniac]

BTW, you shold probably check that the value of the ACAO header is not "null" if found, just in case. It is a bad practice but some servers do that, and Firefox will not fetch the resource in that scenario.

Another tip: you can use a for...of loop since val is an iterable object and you don't need the array index for anything else (makes code shorter and nicer).

Like this:

if (detail.type == 'font' || detail.type == 'script' || detail.type == 'stylesheet') {
   for (const a of val) {
      if (a.name.toLowerCase() == 'access-control-allow-origin') {
		  if (a.value == "null") {a.value = detail.originUrl.split('/', 3).join('/');}
		  return;
	  }
   }
   val.push({'name': 'Access-Control-Allow-Origin', 'value': detail.originUrl.split('/', 3).join('/')});
}

[crssi]

^^ @claustromaniac thank you for the upper tip and rework (and help overall). 👍 Could you just edit upper script and replace a with header, or am I complicating? Edit; never mind, I have updated the first post 😄

From what I see now, we have a working solution for Fonts, CSSs and JSs.., see updated first post.
We need a pair of request header and response header rules.
For now the request header script is #509 (comment) (I have edit it now with const method) and respond header script is #509 (comment) Edit: updated the first post.

OT:

If performance is not a concern, not breaking out of the loop is safer because servers can include multiple ETag headers in the responses if they want. It's not common practice, but it is technically doable.

I am aware of that, but didn't found a single case now browsing around, but of course it doesn't mean its not there somewhere or will be in the future. The same goes for using Origin on IMG,
Maybe the eTag script should be updated with your const trickery.

I am using fiddler where I am tagging all Origins to see what is happening in the last couple of weeks.

For now, there are XHRs and WebSockets left to investigate and, oh man, the XHRs are really bad, broadcastings Origins all around the globe.
More and more I look into XHRs... crap, a Gordian knot to solve.

EDIT: I have reedited this whole post.

[claustromaniac]

broadcastings Origins all around the globe.

Yeah, that's a good way to put it. 😆

Reading through https://w3c.github.io/webappsec-cors-for-developers/ more carefully, I think it is worth noting that these rules can involve some serious risks. Summarizing, we are trading off security for privacy.

If I understand correctly, this is how CORS works, in a nutshell:

spoiler

Typical situation:

• [1] client (Firefox) visits site A.
• [2] a script from site A running in the client attemps to fetch a resource from site B. Firefox adds the Origin header to this request, with site A as its value.
• [3] site B checks its policies to see if it allows clients visiting site A to fetch this resource.
• [4a] site B allows this, so it sends back the resource with an ACAO header saying either * or site A
• [5a] client reads the response headers, finds the ACAO header and allows the script from site A to read the body of the response for the resource in site B.
• [4b] (alternative path) site B does not allow this, so it doesn't add an ACAO header to the response.
• [5b] client reads the response headers, and since it doesn't find the ACAO header, the script from site A is not allowed to read that resource.

What happens when we use these rules:

• [1] same as above.
• [2] same as above, except the HE rule strips the Origin header.
• [3] server receives a request for a resource without an Origin header, therefore, it will most likely not add an ACAO header. If the resource is meant to be public, it may add an ACAO: * to the response anyway.
• [4] the HE rule ensures the final response headers include an ACAO header. In practice, the value will almost always be either ACAO: * or ACAO: site A.
• [5] same as 5a above.

---

The problem is that, in practice, we are giving up the same-origin policy for this, which is risky. Here is why:

spoiler

• [1] client visits www.malicious.net.
• [2] malicious script in www.malicious.net requests a resource from www.yourbank.com that requires authentication (like your bank account details). Let us say you visited your bank's site a while back and your session still has the auth cookies. The HE rule strips the Origin header from the request, but not the Cookie headers.
• [3] www.yourbank.com responds without an ACAO header, because the request did not include an Origin header, but the request did include the Cookie header, so the body of the response is your personal data.
• [4] the HE rule adds an ACAO: www.malicious.net header to the response.
• [5] client reads the response headers, finds the ACAO header and fetches the resource, and malicious script from www.malicious.net just got ahold of your bank account's details.

---

I believe we are safe so as long as we use FPI and/or containers, and there are other obvious ways to mitigate this.

Alternatively, this could be solved by a simple dedicated extension. Said extension would have to check whether the Cookie header is present in the request headers, and only remove the Origin header if it is not. Then, if it did remove the Origin header, it would have to check the response headers for that specific request and add/modify the ACAO header so it says Access-Control-Allow-Origin: *. That's the best compromise I can think of between privacy and security. It would be trivial to implement, but I personally don't like the fact that it would conflict with other extensions that use the OnHeadersReceived event...

Anyway, I think people should be warned of this. There is a good reason for these headers to exist, and that reason is not something that many would easily give up (such as performance).

[Maryse47]

Summarizing, we are trading off security for privacy.

Even with whitelisting CORS as in #509 (comment) ?

[claustromaniac]

Even with whitelisting CORS as in #509 (comment) ?

We are trading off security for privacy by whitelisting CORS. BTW what that rule does is not really whitelisting, it's more like enforcing CORS 😛.

I'm sorry to say I don't think I can explain it any better than I already did. The same-origin policy and CORS are messy concepts that take a while to comprehend. I don't fully comprehend them myself, TBH.

[crssi]

Its prematurely to say, but IMHO, what we are doing here should be safe for Fonts and CSSs.
JSs needs to be investigated further. At least I am using separate browser for banking/paying only, also to avoid possible breakages at the critical moments.
XHRs (same goes for WebSockets) would be best to have separated topic when time... this can lead to a lot of breakages.

[Maryse47]

Maybe drop detail.type === 'script' from the rules for now?

[claustromaniac]

IMHO, what we are doing here should be safe for Fonts and CSSs.

Yes, probably. Besides, if I understand correctly, there are various ways to mitigate the bad side effects of that rule. I believe that even without taking any special precautions the risk is likely low, but I thought it was worth pointing it out anyway.

[crssi]

Maybe drop detail.type === 'script' from the rules for now?

IMHO no. All it can do bad, is to lead to unforeseen breakages, but I haven't found any till now.

[Maryse47]

Breaking same-origin policy isn't matter of breakage but security #509 (comment) and using separate browser isn't a fix.

[crssi]

@claustromaniac
See #509 (comment) at step 4...

[4] the HE rule adds an ACAO: site A header to the response.

Its wrong, it should be:
[4] the HE rule adds an ACAO: site B header to the response.

The response rule actually doesn't know the site A.
In that case I don't see how this could weaken the security, except there might be a breakages (which I haven't found yet any),
It might also raise security awareness. If a "bank" is using a 3rd party public site for their scripting repository (which could lead in a breakage in our case), that would be a very very good sign to change the bank.

@Maryse47 Using a separate browser for banking/paying was never meant as a fix, but as a best practice.

[claustromaniac]

The response rule actually doesn't know the site A.

It does. detail.originUrl is the URL of the resource which triggered the request. See originUrl in the docs for onHeadersReceived.

If you want to confirm, you can use a rule like this in HE:

if (detail.type == 'font' || detail.type == 'script' || detail.type == 'stylesheet') {
	console.log(
`-----------------------------------
Resource at
	${detail.url}
has this originUrl:
	${detail.originUrl}`);
}

Save it as a rule to modify response headers and check the browser console (with CTRL+SHIFT+J) while you browse.

If a "bank" is using a 3rd party public site for their scripting

My bad. I should've made that part clearer. My example implied that site B was the banking site. In that example, site A would be a random malicious site, and a resource from site A would request your private data to your banking site (site B). So, it wouldn't be your bank making requests to a third party, it would be another site making requests to your bank (your bank would be the third party).

I should probably edit that comment, just in case. Even then, it is pretty hard to explain... for me, at least.

EDIT: OK, I edited that part of the comment. I hope it is easier to understand now.

[claustromaniac]

Now that I think about it, some sites may also rely on the same-origin policy for practical reasons, not just for security. Since web developers wouldn't expect common users to tamper with headers, in some scenarios it could be reasonable for them to attempt to make several requests for different resources and let the same-origin policy filter out the unnecesary ones, instead of doing that filtering by other means. This is just theoretical, though.

[crssi]

Thx @claustromaniac ... I will get back to the drawing board as soon I have time.

[crssi]

From what I have browsed and monitored in the last days, the detail.type === 'script' is not really needed if someone is using a good block lists sources for uBO.
Most of destinations that are using this feature I have stumbled on were covered by block lists I am using.
Same goes for XHR.
Without good block lists there is a madness.

First post updated.

[crssi]

Note to myself:

Libraries at code.jquery.com are using origin and are not sanitized, origin-wise, by Decentraleyes WE. I didn't noticed origin usage on other libraries that are covered by Decentraleyes WE.
I am thinking to add JS to the code and being active only for code.jquery.com ATM, will do so and test further.

Also, @earthlng mentioned possible abusements over IMG and I have finally found one page doing so at http://rpresa.**/ . I cannot reproduce, but I think it starts to happen when the page is left open longer time. Will test more and maybe add IMG also into account. and its interacting with street maps leaking Origin over IMG to destination url ggpht.com

There are abusements over referers, but this is covered by ghacks-user.js out-of-the-box.

I am currently logging possible discrepancies over console with header request code and ORIGIN_ALERT: as a filter:

if (detail.type === 'font' || detail.type === 'stylesheet' || detail.type === 'image') { return; }

for (const header of val) {
	if (header.name.toLowerCase() === 'origin') {
		var headerOrigin = header.value;
		break;
	}
}

if (headerOrigin === 'undefined') { return; }

// testing if different domain and filtering out same domain
if (!(detail.url.split('/', 3)[2].endsWith(headerOrigin.split('//')[1].replace('www.','')))) {
	console.log(`ORIGIN_ALERT: ${detail.type}
S: ${detail.originUrl}
D: ${detail.url}
O: ${headerOrigin}`
	);
}

Log output:

ORIGIN_ALERT: <call type>
S: source url
D: destination url
O: origin header

There will be also false positives in the output (but it can be identified as such by naked eye).
Could be done better, to avoid false positives, but not without knowing TLDs.
Mozilla should integrate API into to easier getting the domain and subdomain parts out of URLs with TLDs taking info account.
@sblask did a very good job resolving TLD problem in Skip Redirect WE: https://github.com/sblask/webextension-skip-redirect/blob/master/pslrules.js and https://publicsuffix.org/list/public_suffix_list.dat
More here https://github.com/sblask/webextension-skip-redirect/issues/29 and here https://github.com/sblask/webextension-skip-redirect/issues/30.

EDIT: Added image to upper script and to sripts at first post in this topic.

[crssi]

The cache must be cleared, otherwise it would not show.
But, never mind, you obviously nailed it at 1.0.0b6 and also I don't see XHR leakages. 😄

You are fantastic.

[crssi]

Is it possible to whitelist per destination?
If I do XHR with Exclude root domain matches then everything is almost perfect.
The exceprtion is that in that case the only breakage I have found is youtube video, but since it can also run on other web pages as embedded, then whitelisting www.youtube.com works only on youtube main page.
To make it work everywhere, I would need to whitelist by destination as *.googlevideo.com or even more complex like source->destination combination, in that case like www.youtube.com -> *.googlevideo.com, since for every embedded YT video the source is always www.youtube.com.

I have tried several video sources, like: youtube, twitch, twitter, imdb... with an exception where I haven't tried FB.
The youtube is the only one that is doing GET type of XHR requests. So this is ATM the only breakage I have found and cannot work around.

removed non-relevant confusement

I am just thinking out loud... but in that case you would avoid requests (issues) to add additional parameters or the query part of URL for whitelistings and the end user would have more control.
In that case I would also volunteer to take a part of resolving issues for users with such requests on your GIT issues page.

[crssi]

^^ To simplify the upper shitload, could you just add a whitelist for XHR destination to *.googlevideo.com (if simply possible then only when source is www.youtube.com) and leave upper comment aside for now. 🤗

Cheers

[claustromaniac]

It is not currently possible to whitelist individual resources, but I considered the idea last week. I kinda wanted to avoid implementing that, but I think that will be the best way to go about this, because it will require almost no maintenance in the long term. It is also more flexible and everything.

I think I'll use a syntax like the one you proposed. Something like origin -> target, but in a separate section of the options, to make things easier (for me) and tidier for the end user too.

I'll try to do it in the next few days. With that the extension will be feature-complete at last 😅 Then I'll have to write the documentation and all that, which is the boring part.

[crssi]

ˇˇ Don't worry, nothing to understand... I must have been eaten something "strong" that day, since you have already implemented that.

I will update that post and remove the confusing and embarrassment part.

[crssi]

@claustromaniac
I am testing now 1.0.0b7 from the moment of release.
Haven't found any culprit, having default+XHR+exclude root domain match+www.youtube.com *.googlevideo.com.

Its working perfect. Thank you.
Do you have ETA for release?

Cheers

OT:
What I learned in the process is that near 100% of XHR Post requests to different domains are trackers, FP sites... so in short bad ones.
Obviously I have really good uBO filtering config, since I can't see almost none (actually don't remember to see any) of those in the moment (except when I turn off uBO, then there are tons of it).
But it occurred me that it would be good way to detect rough domains as a source to build uBO block list.

[crssi]

OK... a small bug there is.
Current setting are same as on ^^previous post.
Visit https://hexxiumcreations.github.io/threat-list/, observe connection with Origin leak to https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/js/bootstrap.min.js.

Now add 2: *.bootstrapcdn.com to Overrides.
Clear cache and reload https://hexxiumcreations.github.io/threat-list/... the leak is still there.
But if I use 2 in Overrides it should be aggressive or I understood this wrong?

Cheers

[claustromaniac]

I couldn't reproduce that one. I tested on a clean profile with only this extension. I'm guessing there must be some kind of conflict on your end, but I wonder what that could be 😕 or maybe it is working inconsistently somehow? I'll try to see if the logic is missing something.

I meant to do a release today; it's been over two weeks already. I only have to do some final retouches and finish the documentation.

[crssi]

I have tried now with a clean profile with only this extension and can reproduce every time.
So now I am confused a bit. 😿

[claustromaniac]

I misread this part:

Now add 2: *.bootstrapcdn.com to Overrides.

That is not how overrides work. Overrides rely on the document URL (the URL in your URL bar). To accomplish what you tried to do I would have to implement a sort of blacklist (similar to the exclusions that I released yesterday, but for blacklisting).

[crssi]

Oh... I see.

[claustromaniac]

The problem is I don't see any efficient way to do that, because I'd have to parse headers in all requests to achieve that... I'd have to rewrite the whole webRequest.js to implement something like that. I'll have to analyze this more..

[claustromaniac]

I mean, I can do it, but I will be throwing out all the efficience-driven logic. Right now it's using fail-fast patterns to save CPU cycles, but I'll have to rewrite all that... hm... or maybe I can use an alternative callback for when there are items in the blacklist, and the extension will only be inefficient then, but that's like doubling the lines of code in webRequest.js and radically changing the whole logic everywhere.

It would take some time. I think I'd prefer to do the 1.0.0 release before implementing that (if I implement it). It's not like what you're trying to achieve is not doable in practice already (with global aggressive mode + overrides + exclusions). It's mostly a matter of preference.

EDIT: NVM, I think I overestimated the problem. I think I know what I'll do.
EDIT² I take that back. I really can't add this without making a pretty extreme rework.

[Woofy-Wolf]

Thank you @crssi for your early work to block this tracking method and for helping @claustromaniac as s/he developed POOP. I finally replaced CorsE and your Header Editor rule with POOP ver. 1.1.0. @claustromaniac, your knowledge and generosity impress me. Thank you for creating and offering this extension. It should be adopted by everyone, right alongside their favorite adblockers.

[crssi]

Thank you, but the heavy lifting was done by the @claustromaniac.
If you are using HE solely for removing ETag header, then you can replace it with ETag Stoppa (also made by @claustromaniac).

[claustromaniac]

@Woofy-Wolf, glad to help!

[crssi]

We have found Jesus. It disguises as @claustromaniac .
@Thorin-Oakenpants I will close this issue now to remove clutter in open issues, but if you need to reopen, then be my guest. 😸 ❤️

[ghost]

We have found Jesus. It disguises as @claustromaniac .

Is he Portuguese?!

[Thorin-Oakenpants]

I want to leave it open, because I think we should do something more about it (learn more about it myself, maybe add it to the wiki, etc ) - open issues are my personal todo checklist - just like we still have the EvilCorp AMP issue open

[tartpvule]

I have created an experimental extension aiming to provide complete user control over CORS, including plugging this Origin header leak. Might anyone be interested? Feedbacks needed.
https://github.com/tartpvule/custom-cors-control

Thank you

[Thorin-Oakenpants]

Thanks @tartpvule ... I'll keep out of this conversation (as I have up til now) as I'm not up to date or even qualified about all of this. I'm not sure where @claustromaniac - he's been missing for about 3 or 4 weeks - maybe he went on holiday or got locked in the neighbor's garage or something. Cats are pretty amazing creatures, so I expect he'll show up soon 🐈

[slowfar]

I keyed into the bold request of the first item wrongly selecting the first request option 'cancel'. It was entertaining having no functional web. Oops.

[claustromaniac]

Very nice, @tartpvule. Not user-friendly, if you ask me, but your extension certainly seems to give more control (which was the main goal, I guess). When I can, I think I will update the documentation of my POOP extension (thinking back on it... man, what an honest name!) and link to yours while I'm still not actively maintaining it. I should have done that long ago, actually, but I've been kind of DEAD for a while.

Now... which of my several dozen notifications should I pick next?...

[Thorin-Oakenpants]

if you want to do anything with this: e.g add it to the wiki, then reopen or just tell me