back to article Today's WWW is built on pillars of sand: Buggy, exploitable JavaScript libs are everywhere

The web has a security problem: code libraries. Almost 88 per cent of the top 75,000 websites and 47 per cent of .com websites rely on at least one vulnerable JavaScript library. As described in a recently published paper, "Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web," researchers …

Silver badge
Joke

Perhaps

If we just scrapped browser support for JavaScript, then created a plugin to enable rich content without the need to be downloading snippets of insecure script from untrustworthy sources.

We could call if Flash - saviour of the universe.

You heard it here first...

33
1
Silver badge
Boffin

Re: Perhaps

In the {immortal} word's of Brian Blessed,

"Flash? He's alive?"

Sorry, both Flash and this JS crap needs to be consigned to the bin of history. Yet far more sites are relying on things like node.js.

I guess we are trying to push water uphill then?

We are doomed I tell ye, doomed!

19
4
Silver badge

Re: Perhaps

"In the {immortal} word's of Brian Blessed..."

In the more immortal words of Brian Blessed....

"CALAMITY! I could've farted that in!"

Brian Blessed giving some commentary over a snooker match on Room 101 years ago

3
0
Silver badge

Re: Perhaps

@Steve Davies 3

I guess we are trying to push water uphill then?

Just try nailing jelly/jam to a tree...

1
0
Silver badge

Re: Perhaps

"If we just scrapped browser support for JavaScript, then created a plugin to enable rich content without the need to be downloading snippets of insecure script from untrustworthy sources."

Serious question. What do you propose as an alternative to interactive websites? Anything else you propose is likely to be holier than a wheel of Emmentaler, given we tried this approach in the past. Remember RealPlayer?

3
1
Silver badge
Megaphone

Re: Perhaps

"What do you propose as an alternative to interactive websites?"

a) you don't need JavaScript for an interactive web site

b) you don't need all of that "cruft" to serve up content

c) style sheets can give you almost as much control over the appearance as can scripting (and probably better, more efficient, less memory footprint on the client, MUCH lower bandwidth requirement, faster load times, yotta yotta)

d) if it requires scripting, maybe it should be done server-side instead

e) if a 'meta' tag can't control refresh rates, you're doing it wrong

This isn't about interactive web sites, anyway. It' about ABUSE of SCRIPT, and the sheer volume of crappy JavaScript code being used all over the intarwebs.

Ever since some "bright-bulb" decided that SCRIPTED LANGUAGES within HTML was a *GOOD* thing, it (the script-monster from HELL) has grown into the bakemono that it is today. It's infected everything like a PLAGUE, and it's *EVERYWHERE*.

It's amazing how good a web site can look with standard HTML, tables, hot links, forms, etc.. And they load a LOT faster. It's also amazing just how "dynamic" content can be if the server does a reasonable amount of the work. But yeah, it's easier for lazy developers to just CRAM IN a bunch of script from 3rd party libraries, glue it together, and call it "a web site", and THEN spare their OWN servers from the extra bandwidth by having those ginormous libraries load from CDNs.

/me runs NoScript and if I can't read your content, I typically go elsewhere. It's a big intarwebs.

18
5
Silver badge
Pirate

Re: Perhaps

It was just a joke, not an attempt to start a religious war!

0
0

This post has been deleted by its author

Silver badge

Re: Lots of shouty, no content

Follow the link and read the article. Despite being full of language like "Javascript is notorious for security problems" which really doesn't help much they do go into quite a lot of detail about the javascript vulnerabilities they're talking about. I've only scanned it but it looks like it'd be worth a proper look at some point!

18
0
Bronze badge

Re: Almost 88 per cent of the top 75,000 websites and 47 per cent of .com websites

"Lots of shouty, no content"

Did we read the same research paper? I found it quite interesting and informative.

9
0

Re: Lots of shouty, no content

I've just scanned it as well, but I can't find anything of any value. It even explicitly states "Note that the focus of this paper is not measuring the security state of specific JavaScript libraries. Rather, our goal (and primary contribution) is to empirically examine whether website operators keep their libraries current and react to publicly disclosed vulnerabilities". The technical content on vulnerabilities appears to be zero.

2
2

Re: Lots of shouty, no content - because the topic is messy

The scope of this topic could be described as list of websites -> list of libraries -> library -> list of vulnerable versions -> list of vulnerabilities in each version -> technical details of each vulnerability. The paper only looks at the first four components. If you're looking the details in components 5 & 6, start with the list from component 4 and consult each release note and CVE.

I'd argue that the list from component #4 (mentioned on page 4, point 4 of the doc) is the most valuable point from a deployment strategy, because it would allow you to check your version(s) against that list and patch. The problem is that the javascript library world is poorly managed, because there are approximately 400 (!) versions across 11 libraries (pg 4, figure 1), so the list is simply too massive to include.

1
0

Yet another reason to use NoScript

NoScript and AdBlockPlus reduce the amount of Javascript executed in the browser thereby lowering (but not eliminating) the chance of encountering a problem.

20
2

This post has been deleted by its author

Silver badge

Re: Yet another reason to use NoScript

also greatly shortens load times in many cases. if you're doing a 'duck duck go' search, and you end up on what LOOKS like something with the content you want, it takes less time to realize they're just click-baiting you.

0
0
Anonymous Coward

Backwards compatiblity

Just like OpenSSL, it's backwards compatibility that's hurting security.

If you ruthlessly ditch depreciated versions of IE, then what exactly IS jQuery? A 30kB dependency that re-invents document.querySelector and Object.assign

5
6
Silver badge

Re: Backwards compatiblity

Please lookup depreciate and deprecate.

21
2
Silver badge

Re: Backwards compatiblity

Normally I'd agree but it's IE that was mentioned so both apply.

16
1
Anonymous Coward

Re: Backwards compatiblity

You sound absolutely butt-devastated over my internet typo.

Secondly, all versions below IE11 have already passed end-of-life. Nobody should be supporting or using them on the web.

3
18
Silver badge

Re: Backwards compatiblity

Nobody should be supporting or using them on the web.

Meanwhile, back in the real world...

34
0
Silver badge
FAIL

Re: Backwards compatiblity

Secondly, all versions below IE11 have already passed end-of-life. Nobody should be supporting or using them on the web.

Spoken like a true zealot. Hey Mr Chinese Man whose company still only uses IE 9, look I really can't accept that huge big bag of cash for accessing our website because AC said you should be using IE 11 already.

You can nudge, you can poke, you can plead, but the only time you can stop supporting shitty old browsers is when the users of your sites stop using shitty old browsers.

10
0
Silver badge
Facepalm

Meanwhile, back in the real world...

I was in an NHS hospital a couple of weeks ago. PC in the corner was XP with IE old. Data was being entered into an app running using Java plugin. I was just waiting for Flash to appear to complete the full set of security vulnerabilities.

Month previous, I was in the local private hospital. Still very sensibly using paper for all their records!

6
4
Silver badge

Re: Backwards compatiblity

You sound absolutely butt-devastated over my internet typo.

Nope, just mildly amused by your lack of erudition and subsequent defensiveness. Why not go with end-of-life in the first place?

FWIW for my clients I advocate such a policy for all web site development. But I also see, as do others what the real world throws up: IE9 is indeed still popular in China. Furthermore, while it's a good start to use the most recent stable versions of libraries. this doesn't obviate the need for objective security reviews and tests. And as developers we all need to ask ourselves: do we really need this library?

5
3

This post has been deleted by its author

Anonymous Coward

Re: Backwards compatiblity

I bet you don't actually do any business with China though. You're using it as a contrived example to support your point.

China is very insular and overwhelmingly serves it's own markets.

0
4
Silver badge

Re: Meanwhile, back in the real world...

"Month previous, I was in the local private hospital. Still very sensibly using paper for all their records!"

And what if there's a FIRE? Hard to copy paper records offsite, and expensive.

3
5

This post has been deleted by its author

Anonymous Coward

Re: Backwards compatiblity

"And as developers we all need to ask ourselves: do we really need this library?"

And if the answer comes back, "YES, and it MUST be an outdated and always-vulnerable version because any later kills critical functionality, we can't life it because it's copyrighted, and we can't run the site without it, end of."?

5
0

Re: NHS hospital a couple of weeks ago. PC in the corner was XP

There are still a lot of XP devices out there, especially in places like hospitals where it is needed to communicate with perfectly serviceable medical equipment manufactured when XP was cutting edge. They do however have restrictions in place and kept off networks unless required and then limited.

4
0
Anonymous Coward

Re: NHS hospital a couple of weeks ago. PC in the corner was XP

Wonder what would happen, though, if a device like that requires something open that leaves it vulnerable to pwnage and can't be replaced because to do so will involve a seven-plus-figure expenditure?

0
0
Bronze badge

Re: China

"They're still morons to use IE9."

There's a difference between being uninformed and being a "moron".

Over 18% of the world's population live in China, and a little over half of those have internet access. You can't expect every one of those hundreds of millions of people to be as well-informed as yourself.

6
0
Headmaster

Re: Backwards compatiblity

> Secondly, all versions below IE11 have already passed end-of-life.

Nope, Vista and its IE9 won't be EOL for another four weeks or so. Yes, we'd all much rather forget that one.

4
0
Silver badge

Re: China

So what, AC? They're still morons to use IE9.

Morons with money. My favourite kind of moron.

0
0
Silver badge
Trollface

Re: Backwards compatiblity

"Normally I'd agree but it's IE that was mentioned so both apply."

IE? then I'd have to add "defecate" to that list of words to look up

1
1
Anonymous Coward

Re: Meanwhile, back in the real world...

"And what if there's a FIRE? Hard to copy paper records offsite, and expensive."

Yeah, but if there's NOT a fire, then all you need to read the paper record is good vision and sunlight (which more or less happens every day). Oh, and comprehension of the language it's written in. No high-tech stuff there, really. No problems with outdated data file formats, no problems with lack of a tape drive that can still read the records off the reel, no worry about it getting hacked. None of that. It's just info on paper.

Need a copy for off-site storage? There's a marvelous invention called a copy machine that can make copies almost as fast as you can think about it. There IS some techno there, but the output of said techno just needs eyes and sunlight to be useful.

4
2
Bronze badge

Re: Backwards compatiblity

Don't forget Server 2008. It's still supported until 2020, and it only supports up to IE9..

2
0
Gold badge

Re: And if the answer comes back...

Then you need to ask a different developer. Try looking for one with a fucking clue about software development. The answer you quoted would imply that the existing devs have managed to engineer a hard dependency on a broken feature. You need new devs.

1
1
Silver badge

Re: Meanwhile, back in the real world...

Which doesn't help when you're in the dark without benefit of a flashlight. As for photocopiers, that means additional paper, toner, and maintenence not to mention malfunctions.

0
0
Anonymous Coward

Re: Meanwhile, back in the real world...

"Which doesn't help when you're in the dark without benefit of a flashlight."

If you're in the dark without the benefit of a flashlight (and, I'm assuming, without the benefit of light bulbs and electricity), how the hell are electronic documents better than paper documents? At least the sun will come up in the morning and fix your problem of not having any light to read by. But if you don't have electricity, your computer is just a boat anchor, and your electronic documents are effectively lost.

I will give you the point about copier upkeep and maintenance, though.

0
0
Silver badge

The problem are web agencies and freelancers, not the site owners.

Company X goes to Agency A, "Build us a website". "OK" says the agency. Gets 50% down payment on a £10,000 website, outsources it to India to maximise returns. Agency presents Company X with website to get signed off. Company X, not really knowing what to look for code wise, kicks the tyres and says "Yeah that's great here's the other £5,000 to make it go live". Website goes live. Agency moves on to the next project, Company X moves on to another part of their business because the website is "done".

Company X will probably never touch the website again for a good 2 or 3 years, at which point they'll either appoint Agency A again or go to Agency B. Either way they'll be charged the same amount of money for a brand new website which is either outsourced or given to the YTS member of the team to bash out in 2 weeks. Rinse and repeat.

At no point does Company X ever think to ask Agency A to "update" the website when needed to address security concerns. Agency A also either never offer that service, or they do offer it but they want a fairly substantial monthly fee to do so. Company X can't see the point in spending money on something to prevent the worse from happening. That's even if Agency A actually bother doing what they say they're going to do.

But that's the same with everything. No one wants to spend money on something that might not happen. If the website works, then why bother fixing something that might affect it? It makes more financial sense - for some reason - to fix the problem after it's occured. This goes for car companies, aircraft manufacturers, even councils.

Also, the above is based on 75% of companies not giving a damn how the website works. They just want it up with their brand and their "message", a way for the customers to see some photos and email them through a contact form.

34
2
Silver badge

I have to disagree on this: website owners are at fault for not budgeting and contracting for maintenance. This favours cut-throat cowboys over anyone with a proper support policy.

6
6
Bronze badge

"website owners are at fault for not budgeting and contracting for maintenance"

Most website owners are unaware of the need for ongoing maintenance. I'd expect a conscientious web developer to explain it to them.

16
0
Silver badge

No, the people fundamentally at fault are those who have done so much to push the POS that Javascript is as a standard that all should embrace and rely on, and then abjectly refuse to police it, weed out the dross, etc.

That's basically the major browser developers, outfits like Google, Mozilla, etc. They claim to have made a runtime environment that's universal and safe, yet it's turning out to be as hazardous as any other client side execution Web technology. "Use Javascript, it's safer than Flash/Java/ActiveX/etc". Yeah, right.

Automatically running arbitrary code downloaded from God knows where without so much as a first glance, never mind a second glance, is always a bad idea. Anyone trying to convince you otherwise is almost certainly selling snake oil.

14
4
Anonymous Coward

>arbitrary code

Javascript can't run arbitrary code though. It can only call APIs.

Despite the hype, webassembly is even more limited. Arithmetic only.

5
0
Facepalm

I've tried

As a "conscientious web developer", I've tried this. But you're telling people something they don't understand, and don't want to hear - while the cowboys are saying "There's no need to spend that extra money, it's all fine, and people who say this sort of thing are just trying to fleece you for extra monthly fees." So who are they going to listen to?

Also, the site owner rarely gets punished for poor security, because the payload is most often activated on an end-user's computer. The end-user gets their bank account emptied and/or their files ransomewared, but has no idea which site caused the initial malware infection - so there's no little or no incentive for the site owner to secure the site.

15
0
LDS
Silver badge

The problem is browser offer an execution environment, but not "system" libraries.

Besides fashion-driven development that asks developers to change framework every six months, the main issue is browser are offering an execution environment that is powerful enough to be dangerous (despite the sandboxing attemps, but to be useful sandboxes can't be too tight...), but they don't offer the system libraries (and their updates) an OS offers - so developers use a plethora of third party code even for basic functionalities (up to one line functions!) - which is just too difficult to keep up to date.

Especially if that code is not maintained using proper lifecycle policies, making each upgrade a risk without proper testing and developers availability to fix any issue. IMHO it's time for a "standard js library" - and maybe it's also time for a standard widget set for UIs. Delivered by browser and updated with browser updates. Browsers wants to be sort of OSes? They have to offer the same services.

Designers and marketing would complain, but if they do, it means it's the right path to follow.

12
1

Re: The problem is browser offer an execution environment, but not "system" libraries.

"IMHO it's time for a "standard js library" " .... I actually suggested more or less that to Mozilla a while back... along the lines of "there are umpteen websites using JQuery/Angular/etc" and everytime a user goes to one they need to download the library again... so why not bundle the popular libraries into the browser, and bypass the fetch. Since browsers are nowadays updated frequently, the user gets the latest version of library, and no wasted bandwidth.

I accept that in some cases backwards compatibility will be an issue, as well as "custom builds" of libraries, and name-space issues... but if it was a default then these things can be managed/worked around.

2
1
Silver badge

But that's the same with everything. No one wants to spend money on something that might not happen.

Yes, that's a nice succinct restatement of a very large part of the problem ...

... but what can we DO about it?

1
0
Silver badge

I don't think there's anything that we can do. But a big outfit like Google could show some leadership and do something and impose it. Very Microsoft. Very evil. Very necessary?

Google had better get on with it. Their entire empire is built on Javascript, and it's not too far from being deemed to be a massive security hazard. If that actually happens, and the world at large goes off Javascript like they have gone off Java, Flash, activeX, etc, then Google are in deep trouble. "Please run Javascript on our search page, please, otherwise those ads are going to be far less effective! And we'll do a native gmail client soon, honest.".

4
1
LDS
Silver badge

Re: The problem is browser offer an execution environment, but not "system" libraries.

No, just bundling the popular libraries without any control on their APIs and development is not much different than downloading them from a CDN.

There should be a *standard* library decoupled from the latest fashionable library, because the problem is not downloading them each and every time, the problem is their stability, maintenance and their use in applications.

Ensuring security *plus* backward compatibility is important when your application is not the web site du jour, and you don't have the resource of Google or Facebook to maintain it. For many business their web applications (internal or external) are not the business, are just tools to support the business - and the compete for resources and priorities with all the other tools.

3
0

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2017