
Hacking websites via third-party JavaScript libraries - digitalclubb
https://dmsec.io/hacking-thousands-of-websites-via-third-party-javascript-libraries/
======
NKCSS
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...](https://developer.mozilla.org/en-
US/docs/Web/Security/Subresource_Integrity) if you use a CDN and would like to
do so securely...

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

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

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

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

------
ktpsns
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
SRI: [https://developer.mozilla.org/en-
US/docs/Web/Security/Subres...](https://developer.mozilla.org/en-
US/docs/Web/Security/Subresource_Integrity)

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

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

------
layoutIfNeeded
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_
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?

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

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

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

------
DyslexicAtheist
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?

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

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

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

