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

Latest Videos FromTom's Hardware
Nathaniel Mott
Freelance News & Features Writer

Nathaniel Mott is a freelance news and features writer for Tom's Hardware US, covering breaking news, security, and the silliest aspects of the tech industry.

  • 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.
    Reply
  • 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.
    Reply
  • grant barker
    Thanks for this article. It reminded me to update about 30% of my pages to the latest version on jquery.
    Reply
  • josejones
    This article doesn't mention how to check the JavaScript library for updates and patches.
    Reply
  • 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.
    Reply
  • brucek2
    19426249 said:
    @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...

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