Study: One-Third Of Websites Use Outdated, Insecure JavaScript Libraries

[Guest]

Northeastern University researchers scanned 75,000 of Alexa top websites and 75,000 more websites randomly taken from "a snapshot of the .com zone in May 2016." They found that many sites are vulnerable to attack.

Study: One-Third Of Websites Use Outdated, Insecure JavaScript Libraries : Read more

 

[Morbus]

There's no such thing as an insecure JavaScript library, is there?
I'm not an expert, but if it's client-side, you can use whatever library you like, there's no point in security, because the user is always king.
I could be wrong, of course, but I don't really see an instance where JavaScript security is ever a thing. It's like locking your curtains or covering your money with a drinking glass.

 

[brucek2]

@Morbus, I had the same thought. Since any user can substitute their own JavaScript any time, if there's any insecurity here it feels like it must be in the web standards or their implementations themselves.

 

[grant barker]

Thanks for this article. It reminded me to update about 30% of my pages to the latest version on jquery.

 

[josejones]

This article doesn't mention how to check the JavaScript library for updates and patches.

 

[michalt]

@morbus A lot of web sites are developed using server side JavaScript. Look up node.js as one of the recently popular development stacks.

 

[brucek2]

@morbus A lot of web sites are developed using server side JavaScript. Look up node.js as one of the recently popular development stacks.

Fair enough, but this particular study must be talking about client side JavaScript, no? Because they wouldn't have access to know what was running on the server...

 

[Marissaryan]

Could there be MORE ads on this site? I was going to share this article on my social profiles, but i dont feel comfortable sending my audience to such a spam-filled landing page.

 

[B_Sterner]

@morbus, only as a quick example.

A page pulls information from the URL with client-side JavaScript. In the function that handles the path, there is a eval() statement. Now someone posts a link on a website to the new article/post on somesite.com and slips some code in the link.

- This code in the link is then evaluated, runs a script and sends your cookie information, username, anything it can get, to a remote server. Perhaps on a payment site in forwards your payment info next time you purchase something.

- Maybe the bad link dynamically changes the download link of a download page. The installer thinks they are downloading something from the current site, but it instead downloads from evilsite.com.

- Maybe someone has figured a way to upload a script on sub-domain.somesite.com. Now they set document.domain = "somesite.com" and then uses an altered link to incorporate that script. Now that script will run as if from the same domain.