5 ms·

Hacking websites via third-party JavaScript libraries

127 points by digitalclubb 7y ago

layoutIfNeeded 7y ago
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.
- voltagex_ 7y ago
  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?
- lxrbst 7y ago
  They literally do. Nice post there champ.
jrpt 7y ago
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/ https://enchantedsecurity.com/ These third party libraries are a necessary part of modern websites. It’s worth trusting but verifying their security.
- voltagex_ 7y ago
  >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.
  - jrpt 7y ago
    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 https://enchantedsecurity.com/how-it-works If anyone wants to know more they can schedule a private demo.
- Piskvorrr 7y ago
  Hah. "Security is hard, let's go shopping (for our magic security dust)!"
  - jrpt 7y ago
    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.
- robin_reala 7y ago
  The other option is to reduce your attack surface by minimising the amount of JS you use.
  - jrpt 7y ago
    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.
- Gikoskos 7y ago
  I think you missed something here https://i.imgur.com/CtFLsSm.png https://i.imgur.com/CtFLsSm.png
  - jrpt 7y ago
    Thanks. That's a leftover from some automatic changes. It should have only showed up if you didn't complete the form though.
DyslexicAtheist 7y ago
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?
- voltagex_ 7y ago
  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?
  - DyslexicAtheist 7y ago
    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.
- fabian2k 7y ago
  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.
  - 7y ago
h2onock 7y ago
I'd really like to see a web where developers stop `npm install`ing tons of dependencies, I really would!
- DyslexicAtheist 7y ago
  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.
  - StreamBright 7y ago
    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.
kreetx 7y ago
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.
- yodon 7y ago
  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.
NKCSS 7y ago
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/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... if you use a CDN and would like to do so securely...
- tytho 7y ago
  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.
  - Piskvorrr 7y ago
    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.
- hnarn 7y ago
  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.
  - NKCSS 7y ago
    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.
King-Aaron 7y ago
Doesn't surprise me that WA.gov.au is full of vulnerabilities.
rdl 7y ago
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).
ktpsns 7y ago
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.
- yodon 7y ago
  SRI: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
steve_taylor 7y ago
> 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.
5trokerac3 7y ago
> 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.
rarecoil 7y ago
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/ https://sprymedia.co.uk/

127 points by digitalclubb 7y ago

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.

voltagex_ 7y ago
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?
lxrbst 7y ago
They literally do. Nice post there champ.

jrpt 7y ago

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/ https://enchantedsecurity.com/ These third party libraries are a necessary part of modern websites. It’s worth trusting but verifying their security.

voltagex_ 7y ago
>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.
- jrpt 7y ago
  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 https://enchantedsecurity.com/how-it-works If anyone wants to know more they can schedule a private demo.
Piskvorrr 7y ago
Hah. "Security is hard, let's go shopping (for our magic security dust)!"
- jrpt 7y ago
  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.
robin_reala 7y ago
The other option is to reduce your attack surface by minimising the amount of JS you use.
- jrpt 7y ago
  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.
Gikoskos 7y ago
I think you missed something here https://i.imgur.com/CtFLsSm.png https://i.imgur.com/CtFLsSm.png
- jrpt 7y ago
  Thanks. That's a leftover from some automatic changes. It should have only showed up if you didn't complete the form though.

DyslexicAtheist 7y ago

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?

voltagex_ 7y ago
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?
- DyslexicAtheist 7y ago
  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.
fabian2k 7y ago
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.
- 7y ago

h2onock 7y ago

I'd really like to see a web where developers stop `npm install`ing tons of dependencies, I really would!

DyslexicAtheist 7y ago
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.
- StreamBright 7y ago
  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.

kreetx 7y ago

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.

yodon 7y ago
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.

NKCSS 7y ago

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/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... if you use a CDN and would like to do so securely...

tytho 7y ago
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.
- Piskvorrr 7y ago
  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.
hnarn 7y ago
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.
- NKCSS 7y ago
  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.

King-Aaron 7y ago

Doesn't surprise me that WA.gov.au is full of vulnerabilities.

rdl 7y ago

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).

ktpsns 7y ago

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.

yodon 7y ago
SRI: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

steve_taylor 7y ago

> 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.

5trokerac3 7y ago

> 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.

rarecoil 7y ago

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/ https://sprymedia.co.uk/