Hot answers tagged

65

The security impact of exposing the version number is that an attacker can instantly see whether your version is vulnerable to a known vulnerability. For example, jQuery before 3.4.0 is vulnerable to CVE-2019-11358, so it is useful information for an attacker to know whether your jQuery is 3.3.9 or 3.4.1. However, with JavaScript that runs in the browser ...


36

Knowing the version number is not a security misconfiguration. The risk of exposing version numbers is an "information disclosure". This can create a hazard if knowing this information equips an attacker to craft an exploit for a vulnerability in that specific version. Even if the library ends up containing a vulnerability, it is still not a security ...


11

It is a very, very old pattern of thought in cybersecurity that exposing the version number of something is a security hazard. Allegedly, it makes the work easier for attackers, because if they know the version of whatever it is you are running, they can look up the vulnerabilities that apply to that version. Actually, that is what security scanners are ...


3

This does not work. The browser has to be able to read the link, and as soon as the browser is able to do that, the user is able to do that.


3

One important distinction to make here is that only because the jQuery library contains known vulnerabilities, it does not mean that the website is vulnerable to the contained vulnerability. As with many libraries, a website using jQuery will only be affected by a vulnerability if it uses the vulnerable function in vulnerable way. If it does not use the ...


2

There's not really anything else major you can do. There's a few minor things, which I'll get to, but the basic pattern you describe is used near-universally for good reason. Just based on the steps you describe, if somebody were to have their credentials compromised, I would very strongly suspect it to have nothing to do with your HTTPS or password handling,...


2

When updating a library, you should indeed remove the (possibly problematic) code from the server. This is also true if the web application is not using the vulnerable parts of the library. There is a good reason for that: Served from that web server, the problematic code can possibly be leveraged in an attack that otherwise would be mitigated by CSP. If ...


1

Software vulnerabilities can usually only be exploited when the code is actively used. Having said that you'd like to remove the old files if possible so some faulty implementation doesn't continue to use them (never assume that other software is working correctly). However, be aware that depending on the cache control settings the website set for jQuery ...


1

It depends on the vulnerability. For example, a XSS vulnerability is client-side only. As long as you stop including a vulnerable version of the library on your pages, your site won't be vulnerable, since clients won't load it anymore. Some JavaScript librairies also have a server-side part, for example a file upload plugin for jQuery. The server will ...


1

Is this a limited vulnerability? It is limited in the sense that the vulnerability can only apply if your application is querying via $.get an untrusty/compromised website. What could be its possible effects? As per the CVE, your application would be vulnerable to XSS and all of its implications. Should it be treated dangerous? As much as any XSS ...


1

I think it is safe to say at this point that there is no trivial/text-book bypass for this filter using a modern browser. I shared this snippet of code with a group of friends and colleagues who I consider proficient in XSS and none of them could construct a bypass.


Only top voted, non community-wiki answers of a minimum length are eligible