Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hacking websites via third-party JavaScript libraries

dmsec.io

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Hacking websites via third-party JavaScript libraries

#31

Post by NKCSS »

hnarn wrote: post #29
NKCSS wrote: post #12

That's a risk every time you use a CDN. We used a CDN that f-ed up JS versions, breaking sites, had downtime, breaking sites... when ever you do use a CDN, be aware of everything that could go wrong, which is a lot... On the other hand, id you add hashes to the script references you load, you are a lot more secure, check out https://developer.mozilla.org/en-US/docs/Web/Security/Subres... if you use a CDN and would li…

Please excuse me if this is a dumb question, because my primary job isn't in web development, but what is really the benefit of using javascript code from a CDN rather than hosting it yourself? The way I see it, you're opening yourself up for massive potential trouble by essentially giving someone else a free pass on running whatever code they wish on your website, and you're giving up this privilege for what? I hone…

Yup.

The benefits of a CDN:

1) You don't pay for the bandwidth (in some cases)

2) If enough resources on the web request it, the client may have it cached locally already, causing faster load times.

3) If you request a lot of resources, you get more threading because the amount of simultaneous request to the same host is limited for most platforms (applicable when the source is not cached), but using HTTP/2 negates this issue as well.

4) Based on your location, the CDN can serve the content from a datacenter closest to the end-user (not all CDN's have this feature), resulting in faster transfers as well.

The question remains if this is worth it. For some stuff, it is (think Google Fonts for example), for most, you get version fragmentation, which makes the odds of someone having it cached a lot lower. Add all the other things that can go wrong, and using a CDN stops making sense in a lot of cases.

Re: Hacking websites via third-party JavaScript libraries

#32

Post by toast0 »

hnarn wrote: post #29
NKCSS wrote: post #12

That's a risk every time you use a CDN. We used a CDN that f-ed up JS versions, breaking sites, had downtime, breaking sites... when ever you do use a CDN, be aware of everything that could go wrong, which is a lot... On the other hand, id you add hashes to the script references you load, you are a lot more secure, check out https://developer.mozilla.org/en-US/docs/Web/Security/Subres... if you use a CDN and would li…

Please excuse me if this is a dumb question, because my primary job isn't in web development, but what is really the benefit of using javascript code from a CDN rather than hosting it yourself? The way I see it, you're opening yourself up for massive potential trouble by essentially giving someone else a free pass on running whatever code they wish on your website, and you're giving up this privilege for what? I hone…

Hosting javascript from a CDN is useful for a few things

a) seperates static hostic (js/css/images) from dynamic hosting, which require different tuning and traditionally may run better on separate machines

b) you used to get some parellism benefit from multiple hostnames, that might be gone with http/2, but then you may not want head of lime blocking interacting between html and css/js

c) a good CDN will get your js/css/images to your users faster than if they got them directly from your origin servers, if your assets are of significant enough size to overcome the overhead of connecting to the CDN, and the chance that the CDN has a cache miss (depends on usage). A good CDN is using geo aware DNS and/or anycast to get clients to a datacenter that's near to them, and chances are your origins are only in one to three locations. For one site I worked on, when we did a redesign that doubled the page weight, but also moved serving everything behind a CDN, the page load time ended up about the same, so the CDN basically let us double our page weight for free (I would have preferred that we just keep the page smaller and get a faster site, but I don't get to make those decisions)

d) some people claim there's a reasonable chance of browser caching if you use a public CDN path, although personally, I expect that's very small -- there are so many public CDNs and so many versions of all the libraries and most browsers have fairly small local caches.

Re: Hacking websites via third-party JavaScript libraries

#33

Post by jrpt »

Gikoskos wrote: post #23
jrpt wrote: post #3

I’ve come to the conclusion that the way to secure your website from third party JavaScript is to monitor everything happening on your site: https://enchantedsecurity.com/ These third party libraries are a necessary part of modern websites. It’s worth trusting but verifying their security.

I think you missed something here https://i.imgur.com/CtFLsSm.png

Thanks. That's a leftover from some automatic changes.

It should have only showed up if you didn't complete the form though.

Re: Hacking websites via third-party JavaScript libraries

#34

Post by jrpt »

Piskvorrr wrote: post #8
jrpt wrote: post #3

I’ve come to the conclusion that the way to secure your website from third party JavaScript is to monitor everything happening on your site: https://enchantedsecurity.com/ These third party libraries are a necessary part of modern websites. It’s worth trusting but verifying their security.

Hah. "Security is hard, let's go shopping (for our magic security dust)!"

It's not magic security dust. I don't claim all you have to do is use it to have a secure website, but to address a few prominent classes of attacks you can use it.

And security is hard, so defense in depth makes sense.

Re: Hacking websites via third-party JavaScript libraries

#35

Post by jrpt »

robin_reala wrote: post #10
jrpt wrote: post #3

I’ve come to the conclusion that the way to secure your website from third party JavaScript is to monitor everything happening on your site: https://enchantedsecurity.com/ These third party libraries are a necessary part of modern websites. It’s worth trusting but verifying their security.

The other option is to reduce your attack surface by minimising the amount of JS you use.

Companies derive so much value from third party JS that it's pretty much impossible to not use any third party JS. There's some paper on it that I can't find right now but the average site has dozens of third party resources and the number increases with largeness (more popular sites, which correlates with larger companies, tend to have more third party dependencies) and over time (it was less ten years ago). It's not just third party libraries embedded in their code, but products they're using on their site.

In general I agree that you should minimize unnecessary JS, especially simple libraries like the "left-pads" of the world.

Re: Hacking websites via third-party JavaScript libraries

#36

Post by jrpt »

voltagex_ wrote: post #5
jrpt wrote: post #3

I’ve come to the conclusion that the way to secure your website from third party JavaScript is to monitor everything happening on your site: https://enchantedsecurity.com/ These third party libraries are a necessary part of modern websites. It’s worth trusting but verifying their security.

>Add Enchanted Security's JavaScript to your website to prevent data exfiltration attacks, protecting passwords, credit cards, and other sensitive information. >Install Enchanted Security's tamper-resistant JavaScript snippet on your site. The inline snippet is designed to be small, adding only a few milliseconds to load time, and does not require active configuration on your end. There's a lot of marketing copy on y…

That's because the website's main purpose is marketing, not explaining inner workings. The site explains four steps and you mentioned only the first step, installing it: https://enchantedsecurity.com/how-it-works

If anyone wants to know more they can schedule a private demo.

Re: Hacking websites via third-party JavaScript libraries

#37

Post by rarecoil »

In the first example, this guy goes and pops a (web)shell on Datatables.net. There's no security policy, no bounty program, etc. for this site or its owner[2]. Generally I don't believe it's a good idea to go pwning businesses' servers that don't give you some sort of permission to test. That's some seriously dangerous business.

[2] https://sprymedia.co.uk/

Re: Hacking websites via third-party JavaScript libraries

#38

Post by jrpt »

DyslexicAtheist wrote: post #27
DyslexicAtheist wrote: post #4

SRI is such a cool idea (in theory) but the approach fails in practice. Also very few sites maintain a solid Content Security Policy (CSP). What's the point of all these controls/tools when nobody uses them?

can someone explain the downvotes? Would be cool to understand why this is rubbing y'all the wrong way.

I didn't downvote you but this site is very downvotey for anything that doesn't fit the hivemind. The downvotes on Dropbox's first post are infamous.

You're absolutely right that CSP and SRI are good in theory but fail in practice.

For CSP, it's too difficult to implement a secure CSP, especially without breaking your site. I know companies where it took over a year to implement their CSP. And then, at the end of the day, it's really hard to do securely. Research has found most CSPs are insecure. For example, the posted blog's CSP is: default-src * data: 'unsafe-eval' 'unsafe-inline' But even CSPs that look like they're trying to be secure contain subtle insecurities.

Even trusted domains you might put in your CSP can be used in untrusted ways. For example, this blog post uses Gravatar. Did you know that Gravatar has an optional "default image URL" that can be used for data exfiltration even on sites with secure.gravatar.com in their CSP? It's because Gravatar will proxy the request to fetch the default image if it doesn't recognize the email. https://en.gravatar.com/site/implement/images/ So you may think you've done everything correctly and have a good CSP but in reality it's really hard to do securely.

SRI isn't practical for third party resources that are expected to change over time, which is actually most third party resources. For example, a chat script like Intercom will change when someone from marketing makes a change that affects its frontend settings. This may be changing some text or coloring. You can use SRI for something like a specific version of jQuery, but not for most of the products people are relying on that have more dynamic functionality.

Re: Hacking websites via third-party JavaScript libraries

#39

Post by Piskvorrr »

tytho wrote: post #24
NKCSS wrote: post #12

That's a risk every time you use a CDN. We used a CDN that f-ed up JS versions, breaking sites, had downtime, breaking sites... when ever you do use a CDN, be aware of everything that could go wrong, which is a lot... On the other hand, id you add hashes to the script references you load, you are a lot more secure, check out https://developer.mozilla.org/en-US/docs/Web/Security/Subres... if you use a CDN and would li…

I would also add my (admittedly limited) experience to using CDNs in this way. If you do add the subresource integrity attributes (which a lot of major CDNs don't support because they change the content based on user-agent), you should be prepared for when that check fails, which might mean your site doesn't work. It's certainly more secure than loading malicious scripts, but if you're JavaScript heavy and the CDN lo…

There's a way of falling back to a locally-hosted version...but building and maintaining that gets hard if you're using more than a handful of scripts.
Post reply on HN