4 ms·

I would be happy to address these issues. You have no reason to believe me but all custom servers are secured and are regularly updated. For CloudFlare and Max

by jimaek 13y ago

I would be happy to address these issues. You have no reason to believe me but all custom servers are secured and are regularly updated. For CloudFlare and MaxCDN I have 2-Step authentication enabled + for MaxCDN 1 allowed whitelisted IP address. Regarding unmodified files I guess we can build an app to monitor them? If you want drop by https://github.com/jsdelivr/jsdelivr https://github.com/jsdelivr/jsdelivr and we can discuss this even further. I would be happy to do anything possible to ease your concerns regarding security.

bronson 13y ago
Do you have any sort of agreement that they will serve these files bit for bit unmodified? I had a problem with cloudflare inserting some tracking cookies into my static HTML files. They claimed it was ddos protection. To me (and the EU cookie directive) it looked no different from the garbage other analytics sites use. If jsdelivr providers are allowed to modify the files they serve, I won't use it. Got any sort of guarantees? Thanks.
- jimaek 13y ago
  They are not allowed to modify the files. CloudFlare had to deploy a special fix to disable all cookies and security functionality completely on my account. Only after the fix I enabled their CDN. MaxCDN does not modify the files in any case.
  - saurik 13y ago
    I think with CloudFlare you should really get an agreement that states some kind of penalty if that "special fix" every accidentally breaks (their engineers seem pretty fast/loose with agile code changes that affect their customer's sites).
    - bronson 13y ago
      I think so too. I'm happy and reassured to hear that assets are served unmodified now, but do you have a guarantee that it will remain that way?
      - jimaek 13y ago
        Modifying already hosted files is unacceptable. The fix by CloudFlare was a custom code that disables the Control Panel features completely. Even if I or someone else enables it, it wont do anything. I will be in contact with them to make 100% sure the fix wont be reverted in any case.
- saurik 13y ago
  FWIW, the only "CDN" I've ever heard of to regularly pull stunts like that is CloudFlare; and really, that's their angle: it adds latency (which has been demonstrated in various commentary on the service) with the goal of modifying content to reduce the number of requests or improve client-side rendering times. It is more of a "content optimization" service than a "content delivery" service. If you want a CDN the tradeoffs (number of edge nodes, latency, cache sizes) are much better with other providers. Sometimes, the stuff they inject also has horrible bugs ;P. One time, for an entire day, they were managing to lock up Safari entirely. Cydia is mostly a web browser, and one of the companies I work with apparently used CloudFlare, so Cydia suddenly stopped working that day in a way that was pretty catastrophic. I did a writeup on the process of discovering the bug (which I had to report to CloudFlare to get fixed: I don't even think they really had the expertise in-house to figure out what happened). http://www.saurik.com/id/14 http://www.saurik.com/id/14
  - jessaustin 13y ago
    Good stuff! If you write this sort of article every so often, please set up an RSS or Atom feed.
giergirey 13y ago
Here's one security concern - What procedure do you follow when accepting files for inclusion in jsdelivr? I mean, what's to stop this scenario: 1. attacker uploads a poisoned version (say, with an XSS vulnerability) of a popular library to an official-sounding github repo 2. attacker raises a github issue with you asking you to put it on jsdelivr 3. you assume the attacker is a legitimate contributor or user of the library and add it to jsdelivr 4. other sites start using the poisoned version of the library 5. attacker can now carry out XSS attacks on the sites using the library I have another security concern about www.jsdelivr.com (which I hope is totally separate from the CDN?) but I'll email that to you.
- jimaek 13y ago
  I validate all submitted libraries. I try to do size and md5 validation for everybody. Cases where I do minimum validation is when the author himself submits his library and for trusted people I can skip md5. But once the auto-update app comes online this issues should become obsolete. www.jsdelivr.com is completely separate from the CDN. Plus the code is open sourced so you can actually see how it works.
lazyjones 13y ago
To be frank, I'd like to be able to believe and trust you and work myself in a climate where this is generally safe to do. But we're no longer in the early 90's, so we can no longer base technical decisions that concern security on trust in other people's decisions and behavior (esp. when they are not on our payroll). Nor can we trust contracts and legal assessments when even governments are breaking the law. There are no technical measures that can prevent you or the companies hosting these files for free from serving modified JS arbitrarily, or on some authority's demand, to everyone or to selected individuals. If we could put a checksum in the <script> tag, we'd be fine (to some extent, provided collisions are really hard to find - so no md5 please), but we can't, so we aren't. Like many other web site owners, I believe security to be more important than my bandwidth or a few 10 more miliseconds of loading times, so I can't be convinced easily to use a public CDN for JS. (and yes, I still have to trust other people for not backdooring other software and hardware I'm using, but I try to keep the attack surface as small as possible)

by jimaek 13y ago

bronson 13y ago

Do you have any sort of agreement that they will serve these files bit for bit unmodified? I had a problem with cloudflare inserting some tracking cookies into my static HTML files. They claimed it was ddos protection. To me (and the EU cookie directive) it looked no different from the garbage other analytics sites use. If jsdelivr providers are allowed to modify the files they serve, I won't use it. Got any sort of guarantees? Thanks.

jimaek 13y ago
They are not allowed to modify the files. CloudFlare had to deploy a special fix to disable all cookies and security functionality completely on my account. Only after the fix I enabled their CDN. MaxCDN does not modify the files in any case.
- saurik 13y ago
  I think with CloudFlare you should really get an agreement that states some kind of penalty if that "special fix" every accidentally breaks (their engineers seem pretty fast/loose with agile code changes that affect their customer's sites).
  - bronson 13y ago
    I think so too. I'm happy and reassured to hear that assets are served unmodified now, but do you have a guarantee that it will remain that way?
    - jimaek 13y ago
      Modifying already hosted files is unacceptable. The fix by CloudFlare was a custom code that disables the Control Panel features completely. Even if I or someone else enables it, it wont do anything. I will be in contact with them to make 100% sure the fix wont be reverted in any case.
saurik 13y ago
FWIW, the only "CDN" I've ever heard of to regularly pull stunts like that is CloudFlare; and really, that's their angle: it adds latency (which has been demonstrated in various commentary on the service) with the goal of modifying content to reduce the number of requests or improve client-side rendering times. It is more of a "content optimization" service than a "content delivery" service. If you want a CDN the tradeoffs (number of edge nodes, latency, cache sizes) are much better with other providers. Sometimes, the stuff they inject also has horrible bugs ;P. One time, for an entire day, they were managing to lock up Safari entirely. Cydia is mostly a web browser, and one of the companies I work with apparently used CloudFlare, so Cydia suddenly stopped working that day in a way that was pretty catastrophic. I did a writeup on the process of discovering the bug (which I had to report to CloudFlare to get fixed: I don't even think they really had the expertise in-house to figure out what happened). http://www.saurik.com/id/14 http://www.saurik.com/id/14
- jessaustin 13y ago
  Good stuff! If you write this sort of article every so often, please set up an RSS or Atom feed.

giergirey 13y ago

Here's one security concern - What procedure do you follow when accepting files for inclusion in jsdelivr? I mean, what's to stop this scenario: 1. attacker uploads a poisoned version (say, with an XSS vulnerability) of a popular library to an official-sounding github repo 2. attacker raises a github issue with you asking you to put it on jsdelivr 3. you assume the attacker is a legitimate contributor or user of the library and add it to jsdelivr 4. other sites start using the poisoned version of the library 5. attacker can now carry out XSS attacks on the sites using the library I have another security concern about www.jsdelivr.com (which I hope is totally separate from the CDN?) but I'll email that to you.

jimaek 13y ago
I validate all submitted libraries. I try to do size and md5 validation for everybody. Cases where I do minimum validation is when the author himself submits his library and for trusted people I can skip md5. But once the auto-update app comes online this issues should become obsolete. www.jsdelivr.com is completely separate from the CDN. Plus the code is open sourced so you can actually see how it works.

lazyjones 13y ago

To be frank, I'd like to be able to believe and trust you and work myself in a climate where this is generally safe to do. But we're no longer in the early 90's, so we can no longer base technical decisions that concern security on trust in other people's decisions and behavior (esp. when they are not on our payroll). Nor can we trust contracts and legal assessments when even governments are breaking the law. There are no technical measures that can prevent you or the companies hosting these files for free from serving modified JS arbitrarily, or on some authority's demand, to everyone or to selected individuals. If we could put a checksum in the <script> tag, we'd be fine (to some extent, provided collisions are really hard to find - so no md5 please), but we can't, so we aren't. Like many other web site owners, I believe security to be more important than my bandwidth or a few 10 more miliseconds of loading times, so I can't be convinced easily to use a public CDN for JS. (and yes, I still have to trust other people for not backdooring other software and hardware I'm using, but I try to keep the attack surface as small as possible)