5 ms·

"When you allow third parties to run script on your site, you’re entirely beholden to them; they can run anything they like in the context of your site" I've s

"When you allow third parties to run script on your site, you’re entirely beholden to them; they can run anything they like in the context of your site" I've seen a fair few Internet banking web sites pulling scripts from over a dozen third parties, mostly for tracking and advertising, but even for trivial things like social media. On their customer login pages. It's beyond me how they can consider this to be an acceptable risk.

leni536 11y ago
I wonder how many websites' users would be compromised if code.jquery.com got hacked.
- mayrun 11y ago
  doesnt have to be literally "hacked", just a change of the dns records is enough.
  - leni536 11y ago
    Well, once you hotlink jquery in your website at least use the https link (assuming your site is on https too).
    - nothrabannosir 11y ago
      No need; the browser will block http:// http:// included from https:// https:// pages. Including from a http:// http:// page? Then a compromised jquery cdn is the least of your worries. In short; no, just a compromised dns record is not enough.
      - mayrun 11y ago
        if it is a http:// http:// page, then even a small change in the local host file is enough.
- nly 11y ago
  I've been saying this for years. It's not even just security: you're also potentially leaking all your visitor stats to a third party (IP, user agent, the pages they visit (via the Referer)), and effectively giving jquery.com a third party supercookie over thousands of domains. I surf with third party cookies and referers (via RefControl) disabled, and these should be the defaults
  - leni536 11y ago
    The same could be told about other third party resources, like images and css files, too.
    - nly 11y ago
      Maybe, but hotlinking images has historically been considered rude at best, and theft at worst. And most people still host their own CSS because it tends to come with whatever app, or theme, they're using. In any case, the defaults I live with cover all the other web resources too.
      - leni536 11y ago
        Well, pixel tracking actually exists. http://digiday.com/platforms/explainer-why-pixel-tracking-is-increasingly-popular/ http://digiday.com/platforms/explainer-why-pixel-tracking-is...
  - danielweber 11y ago
    I've been called an idiot (even here on HN) for being paranoid about loading scripts from all over the web. I think it's a losing battle and my side is going the way of the dinosaurs.
    - bsilvereagle 11y ago
      As tools like uBlock and uMatrix get widespread adoption more and more people are realizing how much extraneous junk is being loaded by webpages. I think your side is slowly but surely gaining followers.
- deleted 11y ago
  [deleted]
- fastest963 11y ago
  Which is why they're adding Subresource integrity to script tags so you can detect when a popular CDN/host is hacked and not load the script: http://w3c.github.io/webappsec/specs/subresourceintegrity/#htmlscriptelement http://w3c.github.io/webappsec/specs/subresourceintegrity/#h...
  - tarpherder 11y ago
    How would that help? The "integrity" packet is provided by the now hacked server, and thus can never provide extra security? Or am I missing something?
    - ryan-c 11y ago
      The integrity value is part of the script tag. You add a hash of the script content as a property of the script tag, and the browser only executes if it matches. I hacked together something that implements this sort of behavior in a script loader a while ago, if you're interested: https://github.com/ryancdotorg/VerifyJS https://github.com/ryancdotorg/VerifyJS
      - tarpherder 11y ago
        Ah I see, thanks for explaining. So, though this does allow one to safely circumvent the hosting cost associated with bigger third party scripts, it means giving up some of the advantages like dynamic updates (as the hash would now be incorrect), right? This would therefore not work when ad providers want to be able to supply content they get dynamically from others right?
        ryan-c 11y ago
        Many of the CDNs will let you reference a specific version of the script. If you didn't do this, and there were an update, the script wouldn't load and you'd have to update your site. My script allows callbacks to be specified for a bad hash, so you could be notified of this, and the subresource integrity draft also mentions this as a good idea. It seems not uncommon for ad networks to dynamically load further scripts/content, which would not fall under the hash. You can just sandbox them off in an iframe, though. An obvious extension would be signed scripts, which would re-enable trusted updates of a script in a CDN, but there is the question of how that would be implemented.
mrweasel 11y ago
>"they can run anything they like in the context of your site" Some of them actually depend on that. We seen weird stuff show up on our sites because we made a deal with a company that sells ads for us. Suddenly we're pulling in stuff from companies we never heard of because the ad reseller made a deal with a third-party, which then again outsource part of their infrastructure to a fourth company. It's hours of detective work when you need to figure out who has misconfigured https.
jameshart 11y ago
The issue here isn't so much that they can run anything they like - it's not implied that the provider intentionally put a cross-site scripting vulnerability into the code. The issue is that you don't get to audit the third party code for vulnerabilities, and vulnerabilities can be introduced without your knowledge. But that is part of the tradeoff you make when you agree to accept money from someone to add their code to your site. If someone offers you a hundred bucks to carry a bag onto a plane for them, you'd be right to be suspicious. Ah, but it's not just a random stranger. You were introduced to them by your buddy, the ad network. So that's okay then. Your ad provider wouldn't be dealing with anybody who was actually criminal. But what about negligent? Did they pack the bag themself? Have they let it out of their sight? When you run ads on your site, remember which direction the money is flowing in, and remember who is the customer. Ad networks are a trust broker. The ad provider wants to know their ad really was shown to a real person in a real web browser, who really does meet the demographic profile they are paying to target. They do not trust you, the publisher, at all. And they are paying. You, as the publisher, are getting money from the ad network to compensate you for the inconvenience of surfacing the advertiser's content on your site. And of proving that you aren't defrauding them. To do that, you are going to give up some control. And that includes control over whether the code you're serving is secure.

leni536 11y ago

I wonder how many websites' users would be compromised if code.jquery.com got hacked.

mayrun 11y ago
doesnt have to be literally "hacked", just a change of the dns records is enough.
- leni536 11y ago
  Well, once you hotlink jquery in your website at least use the https link (assuming your site is on https too).
  - nothrabannosir 11y ago
    No need; the browser will block http:// http:// included from https:// https:// pages. Including from a http:// http:// page? Then a compromised jquery cdn is the least of your worries. In short; no, just a compromised dns record is not enough.
    - mayrun 11y ago
      if it is a http:// http:// page, then even a small change in the local host file is enough.
nly 11y ago
I've been saying this for years. It's not even just security: you're also potentially leaking all your visitor stats to a third party (IP, user agent, the pages they visit (via the Referer)), and effectively giving jquery.com a third party supercookie over thousands of domains. I surf with third party cookies and referers (via RefControl) disabled, and these should be the defaults
- leni536 11y ago
  The same could be told about other third party resources, like images and css files, too.
  - nly 11y ago
    Maybe, but hotlinking images has historically been considered rude at best, and theft at worst. And most people still host their own CSS because it tends to come with whatever app, or theme, they're using. In any case, the defaults I live with cover all the other web resources too.
    - leni536 11y ago
      Well, pixel tracking actually exists. http://digiday.com/platforms/explainer-why-pixel-tracking-is-increasingly-popular/ http://digiday.com/platforms/explainer-why-pixel-tracking-is...
- danielweber 11y ago
  I've been called an idiot (even here on HN) for being paranoid about loading scripts from all over the web. I think it's a losing battle and my side is going the way of the dinosaurs.
  - bsilvereagle 11y ago
    As tools like uBlock and uMatrix get widespread adoption more and more people are realizing how much extraneous junk is being loaded by webpages. I think your side is slowly but surely gaining followers.
deleted 11y ago
[deleted]
fastest963 11y ago
Which is why they're adding Subresource integrity to script tags so you can detect when a popular CDN/host is hacked and not load the script: http://w3c.github.io/webappsec/specs/subresourceintegrity/#htmlscriptelement http://w3c.github.io/webappsec/specs/subresourceintegrity/#h...
- tarpherder 11y ago
  How would that help? The "integrity" packet is provided by the now hacked server, and thus can never provide extra security? Or am I missing something?
  - ryan-c 11y ago
    The integrity value is part of the script tag. You add a hash of the script content as a property of the script tag, and the browser only executes if it matches. I hacked together something that implements this sort of behavior in a script loader a while ago, if you're interested: https://github.com/ryancdotorg/VerifyJS https://github.com/ryancdotorg/VerifyJS
    - tarpherder 11y ago
      Ah I see, thanks for explaining. So, though this does allow one to safely circumvent the hosting cost associated with bigger third party scripts, it means giving up some of the advantages like dynamic updates (as the hash would now be incorrect), right? This would therefore not work when ad providers want to be able to supply content they get dynamically from others right?
      - ryan-c 11y ago
        Many of the CDNs will let you reference a specific version of the script. If you didn't do this, and there were an update, the script wouldn't load and you'd have to update your site. My script allows callbacks to be specified for a bad hash, so you could be notified of this, and the subresource integrity draft also mentions this as a good idea. It seems not uncommon for ad networks to dynamically load further scripts/content, which would not fall under the hash. You can just sandbox them off in an iframe, though. An obvious extension would be signed scripts, which would re-enable trusted updates of a script in a CDN, but there is the question of how that would be implemented.

mrweasel 11y ago

>"they can run anything they like in the context of your site" Some of them actually depend on that. We seen weird stuff show up on our sites because we made a deal with a company that sells ads for us. Suddenly we're pulling in stuff from companies we never heard of because the ad reseller made a deal with a third-party, which then again outsource part of their infrastructure to a fourth company. It's hours of detective work when you need to figure out who has misconfigured https.

jameshart 11y ago

The issue here isn't so much that they can run anything they like - it's not implied that the provider intentionally put a cross-site scripting vulnerability into the code. The issue is that you don't get to audit the third party code for vulnerabilities, and vulnerabilities can be introduced without your knowledge. But that is part of the tradeoff you make when you agree to accept money from someone to add their code to your site. If someone offers you a hundred bucks to carry a bag onto a plane for them, you'd be right to be suspicious. Ah, but it's not just a random stranger. You were introduced to them by your buddy, the ad network. So that's okay then. Your ad provider wouldn't be dealing with anybody who was actually criminal. But what about negligent? Did they pack the bag themself? Have they let it out of their sight? When you run ads on your site, remember which direction the money is flowing in, and remember who is the customer. Ad networks are a trust broker. The ad provider wants to know their ad really was shown to a real person in a real web browser, who really does meet the demographic profile they are paying to target. They do not trust you, the publisher, at all. And they are paying. You, as the publisher, are getting money from the ad network to compensate you for the inconvenience of surfacing the advertiser's content on your site. And of proving that you aren't defrauding them. To do that, you are going to give up some control. And that includes control over whether the code you're serving is secure.