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.
Hacking websites via third-party JavaScript libraries
21–30 of 39 posts
Re: Hacking websites via third-party JavaScript libraries
#22> 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.
Re: Hacking websites via third-party JavaScript libraries
#23I’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
Re: Hacking websites via third-party JavaScript libraries
#24That'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 loaded library is integral to your site working, then a malicious actor could still do some harm.
Re: Hacking websites via third-party JavaScript libraries
#25A 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.
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.
Re: Hacking websites via third-party JavaScript libraries
#26While 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…
Re: Hacking websites via third-party JavaScript libraries
#27SRI 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.
Re: Hacking websites via third-party JavaScript libraries
#28> 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.
Re: Hacking websites via third-party JavaScript libraries
#29That'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 honestly don't understand, but it's so popular that I'm assuming I've missed something.
Re: Hacking websites via third-party JavaScript libraries
#30The 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.
They literally do. Nice post there champ.