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.
It read to me like their injecting content into sites they host.
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;
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
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:
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!”
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.
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.