GoDaddy is sneakily injecting JavaScript into your website and how to stop it

godaddy
javascript
Tags: #<Tag:0x00007f0fa8c97020> #<Tag:0x00007f0fa8c95c98>

#1

https://www.igorkromin.net/index.php/2019/01/13/godaddy-is-sneakily-injecting-javascript-into-your-website-and-how-to-stop-it/

The technology that’s in use here is called Real User Metrics and GoDaddy has a page about it here - Why am I signed up for Real User Metrics?. If you happen to be a customer in US (which I am not but the website is hosted in a US data centre) then you are automatically opted into this service and all your website’s pages will have this JavaScript injected into them.

Reason to not use GoDaddy or Javascript.


#2

I had heard of cellphone providers injecting this kind of thing into content mobile client’s consume. However, this is the first time ive heard of it on the server host’s end.

I wonder if it might one of our better browser / better html dream specs it might be wise to do embed a digital signature in a HTML document; that would break under such attacks. Browsers should then just not render the page. No scripting required in the document. Much like how a GnuPG signature will break if an email has been tampered with.


#3

We have that for scripts and external resources, content integrity hashes; Hugo can do that for ya, BTW.

I’m not sure about injecting new ones. I think a header can tell the browser to require the hash? But then that can also be injected…

So, yeah, that sucks.


#4

Actually, I don’t know how they are injecting it. Is it the web server? I mean, they control the server, so it is considered compromised in all other contexts.


#5

It seems like a saavy enough compromised server in this case could inject javascriptless tracking pixels and get around such blocks. They could also make a tracking pixel image appear as if it is a local resource.

It read to me like their injecting content into sites they host.


#6

My head is a bit fuzzy, so posting this here to discuss later. :slight_smile:

https://www.w3.org/TR/SRI/

MDN has the interesting sections:

Content Security Policy and Subresource Integrity

Section

You can use Content Security Policy to configure your server to mandate that specific types of files require the use of Subresource Integrity. Do this using the require-sri-for directive in your CSP header. For example:

Content-Security-Policy: require-sri-for script;

This requires that any attempts to load JavaScript will only succeed if the Subresource Integrity information is in place and the integrity check succeeds.

You can also specify that SRI should be used when loading stylesheets:

Content-Security-Policy: require-sri-for style;

You can also specify both script and style to mandate SRI for both kinds of file.

Cross-Origin Resource Sharing and Subresource Integrity

Section

For subresource-integrity verification of a resource served from an origin other than the document in which it’s embedded, browsers additionally check the resource using Cross-Origin Resource Sharing (CORS), to ensure the origin serving the resource allows it to be shared with the requesting origin. Therefore, the resource must be served with an Access-Control-Allow-Origin header that allows the resource to be shared with the requesting origin; for example:

Access-Control-Allow-Origin: *

Posting this I realize that while I enjoy having this level of protection, the web really sucks as a generalized platform for everyone. “Hey folks, make sure to hash your resources and set up CORS, or your webhost will break your site! Whee, the open web!” :roll_eyes:


#7

For folks wondering what this means, and why I was asking how they injected it, it is because of this: using subresource integrity and a corresponding cross-origin resource sharing policy, certain types of injection is prevented.

For instance, this is how one could prevent Comcast from injecting into the stream, because they are only messing with HTTP when it goes over the wire. It is still possible to mess with, I believe, which is why if it matters one uses HTTPS, which practically circumvents that practice.

This is the important part, because in this very strange case, the web host is doing the creepy part, and they can change how all parts of the web server works, including the headers it sends out that would prevent external manipulation.

Which is super strange, because what GoDaddy is doing won’t give as accurate stats, and uses more resources on top of the server level logs they already keep. If I read this, aside from creepiness, I just don’t get what this company is thinking, technically. That’s not how you collate logs… unless you are trying to track a visitor across domains, and are ID-ing the user via their browser. I suppose that is valuable to someone.


#8

Its become fashionable to micro track people on a page. See where their mouse hovers, how long they dwell on certain sections before scrolling on. Ive mostly heard of it in terms of social media conglomerates but I wonder if their after those kinds of metrics. For a lot of it you couldn’t use server locks with most pages as written I would think.