Hacking websites via third-party JavaScript libraries(dmsec.io)
dmsec.io
Hacking websites via third-party JavaScript libraries
https://dmsec.io/hacking-thousands-of-websites-via-third-party-javascript-libraries/
38 comments
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 like to do so securely...
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 loaded library is integral to your site working, then a malicious actor could still do some harm.
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.
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 honestly don't understand, but it's so popular that I'm assuming I've missed something.
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.
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.
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.
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.
> The Tealium iQ Tag Management System service is used by many companies to organize tags on their websites.
Tag managers are the worst. They shouldn’t even exist. When a website uses a tag manager, it means the web devs have been forced to give marketing and every other department a backdoor to insert whatever vile abominations they want.
Tag managers are the worst. They shouldn’t even exist. When a website uses a tag manager, it means the web devs have been forced to give marketing and every other department a backdoor to insert whatever vile abominations they want.
> Each time a new table was generated, a new PHP file was created on the server. Using a hole in filtering of the input parameters for creating the PHP file, I was able to reproduce an RCE attack: a malicious request injected arbitrary PHP code into the generated file.
So this has nothing to do with the third party JS library itself, but with how the website's backend stored the data generated by the frontend script. The developer could probably reproduce the hack with postman and doesn't need the CDN hosted library at all.
So this has nothing to do with the third party JS library itself, but with how the website's backend stored the data generated by the frontend script. The developer could probably reproduce the hack with postman and doesn't need the CDN hosted library at all.
A few ways out of these are:
- don't eval on the server side (this is a bad idea most of the time anyway);
- serve js bundles from your own domain and set an appropriate content security policy;
These hacks won't work then.
- don't eval on the server side (this is a bad idea most of the time anyway);
- serve js bundles from your own domain and set an appropriate content security policy;
These hacks won't work then.
The charting vulnerability discussed in the article and found to be introducing vulnerabilities in 90 crypto coin sites remains 100% effective if you never eval server side and only serve bundles from your own domain with appropriate content security policy. Worse, now that the bug has been fixed in the vendor's distribution, your customers would still be at risk if you were self hosting the old files. There are no simple solutions to securing large complex systems. It's simply hard and takes lots of work, and you will almost certainly still be vulnerable in the end. That's why physical locks are rated in terms of time for attackers to open not inability of attackers to open.
While I think SRI is a good tool to counter CDNs (with the correct deploying strategy, human-supervised semi-automatized SRI generation shall become trivial), there is a fundamental flaw with "compiled" aka obfuscated/minimized javascript code: How do you, as an author, even know that it doesn't contain malicious code in the first place? That's the fundamental problem of using software written by other people: Except you can afford expensive code audits, you never know. I expect any security-related company (like Banks) to do these source code audits. But I doubt they do it.
Minimize JS use, serve the JS you use only from your own domains, run high security apps on dedicated domains with less JS and other external shit than your public marketing site, and use CSP.
I'd probably trust a single CDN (like cloudflare) with my own copies of all things I include more than I'd want to serve directly but use code from lots of different sources, but for something incredibly high security, I'd want end users to be talking directly to a secure server (maybe with tcp/etc. layer proxies for ddos resistance and flow-level monitoring, but without decrypting).
I'd probably trust a single CDN (like cloudflare) with my own copies of all things I include more than I'd want to serve directly but use code from lots of different sources, but for something incredibly high security, I'd want end users to be talking directly to a secure server (maybe with tcp/etc. layer proxies for ddos resistance and flow-level monitoring, but without decrypting).
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/
[2] https://sprymedia.co.uk/
The fact that this was possible is a testament that web devs really have no concept of due diligence. Sad.
Imagine if running a native app on your computer would load random DLLs from servers. It boggles the mind.
Imagine if running a native app on your computer would load random DLLs from servers. It boggles the mind.
Technically applications with auto updates do load "random" DLLs from servers.
I'm pretty sure you can't make a blanket statement like this without discounting a lot of developers who do take security into account when developing. These are just some interesting holes that were reported.
Is all your code perfect?
I'm pretty sure you can't make a blanket statement like this without discounting a lot of developers who do take security into account when developing. These are just some interesting holes that were reported.
Is all your code perfect?
I'd really like to see a web where developers stop `npm install`ing tons of dependencies, I really would!
Keep the DevOps Mindset but get rid of DevOps as a thing where Devs are allowed to control everything that goes into production without a technical argument (the argument has been replaced by test-cases). We need to start having hard discussion again between devs (the agents of change) and ops (the protectors of the realm). Maybe not for every case but
Note: having seen terribly rigid processes I'm very much an advocate for DevOps and welcomed this way of working. I think we threw out the baby with the bathwater when we embraced DevOps. A site that allows what is mentioned in this article doesn't have a functioning Operations unit.
Note: having seen terribly rigid processes I'm very much an advocate for DevOps and welcomed this way of working. I think we threw out the baby with the bathwater when we embraced DevOps. A site that allows what is mentioned in this article doesn't have a functioning Operations unit.
DevOps is not about letting devs control everything that goes into production. There is a much deeper problem with npm and the bloat driven web development. The amount of JS code an average website had more than a rich client implementation would be. The generic argument for web used to be that the resulting size of the web site is smaller than the rich client. This is not true anymore.
Doesn't surprise me that WA.gov.au is full of vulnerabilities.
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?
I would suspect that ads make it difficult if not impossible to write a good CSP. It's also probably much easier to create a good CSP if you start with it, and much harder and likely to break unexpectedly if you try to add it retroactively on an existing site.
I also found that some modern tooling for web apps doesn't seem to be built with CSPs in mind. For example CSS styling in JS like React Styled Components, I'm not sure it's even possible to create a CSP that covers CSS in this case.
I also found that some modern tooling for web apps doesn't seem to be built with CSPs in mind. For example CSS styling in JS like React Styled Components, I'm not sure it's even possible to create a CSP that covers CSS in this case.
It is, but often not supported out of the box. You will need to extract any css during the build into separately served files. Also it‘s a pain during development. But it‘s possible.
Yes! I mean, I understand that few websites have the expertise, personnel and incentive to come up with a working CSP and maybe even SRI tags. But then you see these incidents where CC data is exfiltrated from the payment pages of major airlines (British Airways) and all that other MageCart shit and you start to wonder: These pages don't need ads on them, any code that goes out should be reviewed so there would be resources for CSP/SRI, and the economic incentive is somewhat given (bad press). Still nothing happens :/
Is no one using them because there's little awareness of them in the wider web dev industry? Is no one using them because the courses being taught at the moment don't include security? Are they too hard to use? Are they not turned on by default?
yes to all of them? I love these concepts but who wants to maintain CSP's and audit revisions to 3rd party javascript in a fast moving environment (see my DevOps is crap rant below). Maybe I start a new project with best intentions, but then marketing comes, then there is pressure to just get on with it ... Even with best intentions, it's literally impossible to keep track as the system matures and complexity increases. And you eventually have to give up on auditing any of the external resources (who even does that in the first place - instead we all assume it has been properly checked by the upstream vendor).
Having a "security-ops meeting" to discuss whether we should really be using shiny new XYZ.js from another external provider isn't going to work either. It all seems like it's more of a mindset problem than a technical one. It's one hot mess.
Having a "security-ops meeting" to discuss whether we should really be using shiny new XYZ.js from another external provider isn't going to work either. It all seems like it's more of a mindset problem than a technical one. It's one hot mess.
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.
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.
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.
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 your site, but it doesn't really tell me what it's really doing, or even how Enchanted Security itself is secured.
>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 your site, but it doesn't really tell me what it's really doing, or even how Enchanted Security itself is secured.
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.
If anyone wants to know more they can schedule a private demo.
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.
It should have only showed up if you didn't complete the form though.
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.
And security is hard, so defense in depth makes sense.
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.
In general I agree that you should minimize unnecessary JS, especially simple libraries like the "left-pads" of the world.