It is pretty standard practice to host assets on a "cookieless" domain you control, but not on the same domain as the original site. For example, www.example.com has all the html, but all of the images are hosted at www.images-example.com. That would skew the results considerably.
The main reason is sometimes you have *.domain.com authentication cookies for single sign in across a suite of sites, however you do not want those authentication cookies sent to domains that do not need authentication.
I understand that it isn't possible to check if the external assets are hosted on a CDN bucket which is under the control of the website (but under a different domain name), but without the ability to discriminate such cases it makes your statistics on externally hosted content pretty meaningless.
I don't agree with that. From the point of view of the user that content might as well have come from a third party since - just like the headless browser used in the testing - they have absolutely no way to verify that short of doing a bunch of whois lookups. And if there is one thing that a user should be able to verify then it is that the entity sending them the main page is the same entity as the one that sends them the rest of the stuff on that page and to refuse all or part of the transaction if that isn't the case.
After all: there is only one slot in the URL bar, which strongly suggests to the user that that is the entity they are transacting with.
What technical tricks are pulled behind the scenes have no bearing on that.
> From the point of view of the user that content might as well have come from a third party since - just like the headless browser used in the testing - they have absolutely no way to verify that short of doing a bunch of whois lookups.
How many users, even among the extremely security conscious, do you expect to actually verify such things? And among these, how many do you expect will turn their noses up at a CDN url that is serving a number of obviously website-specific assets in addition to jQuery and friends? The real issue (and the one you focus on in your article) is the actual dangers you expose yourself to by using uncontrolled external asset sources. If I set up a CloudFront bucket that mirrors the static asset directory on my web server (and use it via HTTPS), what is the vulnerability? CloudFront could be hacked, but so could my web server (and the later is a more likely culprit since it is executing more dynamic code). The difference makes even less sense if my website is also hosted by Amazon.
If I want to keep my static assets on a CDN (and save myself a lot of server load) while keeping my assets URLs on the same domain, the only two things I can think of are:
1. Using a CNAME record, which precludes using HTTPS (introducing a real, not perceived, security vulnerability).
2. Use a local url that gives a 301 redirect to my CDN url. Which means extra requests to my website, for no real security benefit.
What about the common trick of serving static assets via a separate domain (one that's still owned and hosted by you) to avoid the overhead of cookies from the main site being included in asset requests?
That's a good point. That would require some more work to rule out, for instance by doing a whois lookup to see if the domains have the same controlling entity.
Yep, it's a tricky one to sort out. Harder still if the domains are using a whois privacy protection service.
Checking if both domains resolve to the same IP could help establish a link in certain cases (e.g. where the same haproxy load balancer is terminating traffic for both sites).
Maybe also checking if the asset domain contains the string of the main site domain e.g. company.com and companystatic.com or company.com and companyassets.com
Edit: if both sites are served over SSL you could also sniff the cert to see if its the same one in both cases (i.e. they're using one cert and multiple subjectAltName entries).
You can point *.my-domain.com to an external resource but it would see that resource as still under your control.
I will post the code soon.