Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security Bug The Internet

6 In 10 Websites May Be Impacted by jQuery XSS Vulnerabilities (i-programmer.info) 25

"Although the JavaScript library jQuery is no longer as popular as it was, it is still widely used. As a result at least six in ten websites are impacted by jQuery XSS vulnerabilities," reports I Programmer: Even more security issues are introduced by the jQuery libraries used to extend jQuery's capabilities. These findings come from open source security platform, Snyk and are included in "The state of JavaScript frameworks security report 2019". While this report is mainly devoted to a security review of the two leading JavaScript frameworks, Angular and React, it takes a "sneak peek" into the security vulnerabilities in three other frontend JavaScript ecosystem projects - Vue.js, Bootstrap and jQuery.

jQuery was downloaded more than 120 million times in the last 12 months, which is equivalent to the number of downloads for Vue.js (40 million) and Bootstrap (79 million) combined. Snyk reports that four vulnerabilities had been found for Vue.js, all of which have been fixed. Bootstrap contained seven cross-site scripting (XSS) vulnerabilities. Three of these were disclosed in 2019 and there are no security fixes or upgrade paths to avoid them. In the case of jQuery, Snyk tracked six security vulnerabilities affecting jQuery across all of its releases to date. Four are medium severity Cross-Site Scripting vulnerabilities, one is a medium severity Prototype Pollution vulnerability, and the final one is a low severity Denial of Service vulnerability.

The report concludes that unless you are using jQuery 3.4.0 and above then you are using vulnerable jQuery versions.

This discussion has been archived. No new comments can be posted.

6 In 10 Websites May Be Impacted by jQuery XSS Vulnerabilities

Comments Filter:
  • by phantomfive ( 622387 ) on Saturday November 09, 2019 @08:41PM (#59398558) Journal
    Most of the functionality of jQuery has been moved into standard Javascript now, so there's no real reason to use jQuery anymore. A good library, no longer needed.
    • Re:Don't use jquery (Score:4, Informative)

      by jellomizer ( 103300 ) on Saturday November 09, 2019 @08:54PM (#59398570)
      JQuery is Javascript so Yes all the functionality is actually in Javascript, and always has been. However, the plugins for JQuery UI, and also some of the extra controls. It does make it migrating off JQuery difficult if you have a site that was based on it. Also many applications it is easier to upgrade the version of JQuery over time then do a full Javascript rebuild.

      One of my popular Intranet Apps Uses JQuery, this App was originally designed to run in IE 6, As work had that as standard. Normally I avoid third party libraries, however, I picked JQuery, knowing IE 6 would be on its way out, and when Chome/Edge became the standard, it was a quick upgrade. I did upgrade jQuery, and it worked much easier then if I had to convert all my IE6 Javascript hacks to work for standard browsers.

      New Apps I avoid JQuery, but old apps I am glad I used it and I still use it.
      • by pyrrho ( 167252 )

        the example is for example, in 2006 I used Jquery b/c there was no way to get an element by a "selector"... as far as I know jquery invented that idea (though it might have come from somewhere else)... basically using CSS selectors to query the dom. And then it became part of javascript. But also, the anim stuff was great, so I started using that, before there was CSS animation/transitions... and finally, a big thing for jquery then was doing "ajax" b/c the way you instantiated XMLHttpRequest was slightly

    • The problem is there are a lot of functional libraries out there that are useful that are dependent on jQuery. Some are implemented as jQuery plug-ins. It will be a looooong time before jQuery falls out of common use.

    • Sizzle is still the world's best selector engine. Built-in css is a bitch.
      • To be honest, I just like jQuerys Ajax pimitives. $.post and $.get have alwaysa been pretty great get-shit-done tools.

    • by LifesABeach ( 234436 ) on Sunday November 10, 2019 @01:01AM (#59398898) Homepage
      "Although the JavaScript library jQuery is no longer as popular as it was, it is still widely used.

      When 6 out of 10 web sites use something, that is popular. Would it be better described, is it that EditorDavid does not like jQuery?
  • prototype.js (Score:4, Interesting)

    by bussdriver ( 620565 ) on Saturday November 09, 2019 @09:05PM (#59398586)

    People complained about prototype.js and how it was more of a series of hacks and one shouldn't modify DOM but should encapsulate it like jQuery's approach. HOWEVER, if we had all used prototype perhaps most of it's features would be built-in today and it would be extremely easy to migrate away once IE was not longer the prime driver of browser difference patching. But we went with jQuery so now it's quite entrenched and it's nicer workflow has many still clinging to it way beyond it's usefulness. Perhaps it's impact will be better designed interfaces for programmers?

    It certainly is not making people think twice about jumping into entangling their projects around libraries which merely automate some steps by creating a whole new framework of doing things... almost like how we keep inventing new languages... something else that has spread into this world... (at least typescript is more like a future javascript.)

    The problem is scripting has it's purposeful niche just like libraries and we eventually end up with feature creep pushing them beyond where they are best suited... rising to the level of their incompetence... what scripting should be doing is linking components written in many different tools as the coupler of loosely coupled work. At least web assembly has a promise of making that a reality and perhaps reducing the demand to make javascript the scripting version of C++ (and all the mess of browser issues and now the language itself requiring a mess of tools if you want to use new things early... all needing to be handled at runtime... big sites running slower on faster computers. ) Why we couldn't have macro/parser hacks in JS -- they should have done it in ECMA 6!! It would have mitigated some of the mess that continues to fester... while some would have abused it; that wasn't the reason to stop it.

  • I got pretty pissed off at ecmascript two decades ago when I needed to encrypt a password for access control. I could not get the damn thing to force a type. Even 1980's BASIC let me work with ASCII conversion.

    Since then, I have seen so many web sites with "fancy" pull-down menus, animated slide shows, and other bullshit crap. I wonder if all this offensive shit is rooted in these ecmascript libraries.

    I am NOT a "web" programmer, but I easily made a PHP inventory control system with PHP with absolutely NO e

    • This. After getting a bad taste in my mouth with the "if ie3 do this, if ie4 do that, if netscape 3 do this, if netscape 4 do that" bs in the late 90s/early 00s that it got me to do everything server side and deliver plain HTML (and later HTML/CSS) to the client.

    • by znrt ( 2424692 )

      I got pretty pissed off at ecmascript two decades ago when I needed to encrypt a password for access control. I could not get the damn thing to force a type. Even 1980's BASIC let me work with ASCII conversion.

      funny then that i've written several clients using several cryptographic algorithms and mathematical proofs for critical security systems in ecmascript with no noteworthy issues, except a few platform incompatibilities. maybe you shouldn't be 'encrypting passwords for access control' if you don't know what you're doing in the first place ...

      and however handy and dandy php might be for you, what does that have to do with client side library security? there are cases where you simply need client side logic. o

  • by ptaff ( 165113 ) on Sunday November 10, 2019 @04:16AM (#59399108) Homepage

    Let say I build a basic Hello World HTML page, including a vulnerable jQuery library that's only used to print the Hello World text. Please explain how can jQuery be exploited and who are the victims.

    Thanks.

    • by MS ( 18681 )

      I'd like to know that too.

      • by peterw ( 88369 )

        From what I've seen, most of these bugs are really obscure and only apply to unusual, specific circumstances. Consider https://snyk.io/vuln/npm:jquery:20150627 -- to be vulnerable, your web page has to be making an $.ajax() call to a malicious cross-domain server.

        This may be a better example, for jQueryUI (not jQuery core): https://snyk.io/vuln/npm:jquery-ui:20160721 -- to be vulnerable, you have to create a dialog box object and use browser-supplied data in the Close Text property. 99.99% of the time close

  • by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Sunday November 10, 2019 @06:03AM (#59399204)

    So you can sideload stuff and feed it into the DOM easier and more relyably in jQuery?

    Well, duh, Captain Obvious, that's the whole point of jQuery.

    That's what jQuery is supposed to do. It is not jQueries job to check libs and plugins you ad without checking what they do and, most importantly, without managing your own dependencies. That's the job of the web developer.

    This "study" is beyond pointless. I want my 5 minutes back.

  • This is what you get for using HTTP and HTML/XML/javascript in a browser for your application's user interface. The result is poor security and web pages that are larger than Windows 95. [dev.to]
  • Don't user a fucking web browser as a general purpose interface and this entire problem disappears along with the 100+ module dependencies and 400MB webpages.

"Look! There! Evil!.. pure and simple, total evil from the Eighth Dimension!" -- Buckaroo Banzai

Working...