Mdthbs

Our web application uses a HTML file with jQuery embedded inside.
According to the jQuery license (https://jquery.org/license/), we have to leave the license header intact, including the version number.

Our client reported exposure of the product and version combination as a security risk. Strangely, the bootstrap version in the same file is not reported as a security risk.

Many applications use libraries with version numbers inside. It's even possible to get version numbers by running some code in Firebug or Chrome's Developer Console.

In what circumstances does this "security misconfiguration" (https://www.owasp.org/index.php/Top_10-2017_A6-Security_Misconfiguration) apply to displaying product and version number? And how can we resolve this issue without violating the jQuery license?

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 the complete source code is accessible by the attacker, so it is impossible to hide whether your jQuery is vulnerable. Even if you hide the version, the attacker can compare the code, or just try an exploit, to determine whether you are vulnerable. Hiding the version number may make it slightly more work, but realisticly it accomplishes little.

Furthermore, there are other ways to mitigate this:

• Keep in the loop about security problems in the libraries you use. Subscribe to a mailing list or another publishing method for security problems.


• Update the client libraries whenever a security problem is identified.

If you always have a non-vulnerable version because you update regurarly, it is no problem that the version is disclosed. And you can tell your client that this is the way you mitigate the information disclosure.

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 misconfiguration issue. That would be "A9-Using Components with Known Vulnerabilities".

So, it appears that the client has an incorrect and rigid understanding of the risks and the situation.

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 doing. Nessus et al have a built-in database of vulnerabilities by version number. So unless you never scan yourself, hiding that information is shooting yourself in the foot.

Except that both scanners and attackers (who use scanners, you know?) have other means than a simple strcmp() to determine the version number of something. It's a bit more effort, and can't always pinpoint an exact number, but no attacker worth anything will confuse jQuery 3.3.0 with jQuery 2.2.1

Non-script-kiddie level attackers also have several other methods to figure out what you're running, from fingerprinting to simply testing automatically a few hundred exploits and checking which work.

Hiding the version number gives you a very small amount of additional security. If you have nothing else left to do, you can do it or not. As long as you have any real security issues to fix, spend your time on those.

Lastly, exposing the version number is not a case of a Security Misconfiguration. If your tool reports it as such, report that bug upstream so your tool can get fixed.

I'm not 100% sure whether or not this is a duplicate question. If it should be marked as such, please do so mods, but I think that the advice in this particular post "Is there a base version of jQuery which has no XSS Vulnerability" would be useful in solving the problem for your clients.

One of the main factors you'll have to evaluate in addressing the general question is whether the proposed security solution is a good ROI for your client. Is it worth writing an exception into the security policy, or perhaps implementing code to strip out the version numbers returned (or as the commenter notes potentially ditching jQuery) to mitigate the risk of exposing the version number? In many cases it won't be, but in others it will, and it will all depend on the individual situation. However, you should definitely verify the versions that you are using aren't already compromised by using something like cvedetails or the NIST National Vulnerability Database.

As to why Bootstrap is not reported that is likely down to the scanner (which you didn't mention) and tests you're using for evaluation. According to the logic of the OWASP Security Misconfiguration it could be seen as a vulnerability as well and should/should not be addressed for the same reason. Regardless, exposing that information does give any potential attacker another data point from which to conduct research and potentially identify vulnerabilities.

In the end, hiding it is security by obscurity.

Which is often maligned as misguided and useless behaviour.

Which it is, if used ON ITS OWN and AGAINST A TARGETED ATTACK.

It can enhance "proper" security measures by lowering the chance you are not targeted in the first place by anyone that is still looking for a target.

It minimizes RISK.

"Proper" security is like making sure your actions are legal, security by obscurity is like still making sure you don't gather gratuitous police attention in case you are mistaken about the law.