4 ms·

I wonder what's considered external though. If I compile / minify my javascript and CSS and then use a CDN to cache or host it -- is this considered external??

I wonder what's considered external though. If I compile / minify my javascript and CSS and then use a CDN to cache or host it -- is this considered external?? If so, how is it different from trusting my hosting provider to host my site in the first place, or my domain provider for resolving for me? How can this analysis know whether or not the resource is external? based on dns records alone? because I can still use *.my-domain.com but point it to an external resource... The concerns raised are valid, but I'd like to see the methodology for analyzing the data because it can definitely skew results.

jacquesm 11y ago
If the url used to fetch the file is not related to the domain the original html comes from then that would be counted as external. 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.
- mixologic 11y ago
  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.
  - lifeisstillgood 11y ago
    Why use another domain and not a sub-domain? I assume something to do with the cookie-less comment - but not clear what?
    - mixologic 11y ago
      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.
- corford 11y ago
  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?
  - jacquesm 11y ago
    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.
    - corford 11y ago
      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).
- johncolanduoni 11y ago
  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.
  - jacquesm 11y ago
    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.
    - johncolanduoni 11y ago
      > 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.

jacquesm 11y ago

If the url used to fetch the file is not related to the domain the original html comes from then that would be counted as external. 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.

mixologic 11y ago
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.
- lifeisstillgood 11y ago
  Why use another domain and not a sub-domain? I assume something to do with the cookie-less comment - but not clear what?
  - mixologic 11y ago
    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.
corford 11y ago
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?
- jacquesm 11y ago
  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.
  - corford 11y ago
    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).
johncolanduoni 11y ago
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.
- jacquesm 11y ago
  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.
  - johncolanduoni 11y ago
    > 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.