39

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?

Improve this question
17
  • 8
    I think you have a logic error in that information disclosure is being equated as a security misconfiguration. They are in no way the same or related.
    – schroeder ♦
    Commented Aug 13, 2019 at 9:22
  • 10
    "Strangely, bootstrap version in the same file is not reported as a security risk." They might have randomly spotted the jQuery version number and reported that. Or they might think that it's redundant to nitpick over every version number they found. Or their automated tool just spotted the jQuery one. Just like software is never bug-free because the programmer doesn't think of every edge case or know every quirk (or perhaps doesn't get enough time to do so), pentesting is also an inexact business.
    – Luc
    Commented Aug 13, 2019 at 9:49
  • 7
    Removing the version number from the license file would not help you anyways, because an attacker can just check manually what version you are using.
    – user163495
    Commented Aug 13, 2019 at 13:55
  • 1
    @MonkeyZeus If you use a naïve exact match, then you would be right. However, if you check for a degree of similarity, then slight modifications to jQuery 3.1.7 will still look 99.8% like jQuery 3.1.7.
    – user163495
    Commented Aug 15, 2019 at 14:35
  • 2
    @MonkeyZeus Yes, I am aware, but that wasn't really the point. Script Kiddies use well-made automated tools, not badly-made self-written one's. Every basic webapp analyzer will be able to identify a modified jQuery version, so attempting to obfuscate it will just result in problems and no security benefit gain. Although I would like to know how you would cause a browser to use a vulnerable jQuery version, if the site includes a version without any known vulns.
    – user163495
    Commented Aug 15, 2019 at 15:56

5 Answers 5

Reset to default
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 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.

Improve this answer
8
  • 1
    Agreed, just a small note: "Hiding the version number may make it slightly more work" I'd argue it's a bit more than "slightly": in order to map code back to a version number (in order to plug that version number into a CVE search), you have to have an index of all variants (minified, maybe with different packers) of all versions of all relevant libraries. A dedicated attacker might do this if they suspect there will be an exploitable vulnerability, but most of the time, the vulns of client-side libraries are not reachable or have a limited impact. I think few attackers would bother.
    – Luc
    Commented Aug 13, 2019 at 9:45
  • 15
    @Luc I would argue that it's simply useless, you can access this through $.fn.jquery, way easier than scrapping the comments which may anyway be unreadable in most sources because of SOP.
    – Kaiido
    Commented Aug 14, 2019 at 1:07
  • 4
    @Luc if you are talking about the css, then no, there isn't something available from js (apart comments). But each bootstrap plugins have their own VERSION accessible from the constructor: stackoverflow.com/questions/43233588/…
    – Kaiido
    Commented Aug 14, 2019 at 8:01
  • 1
    @Echo They generally all have their own mailing lists. However oss-sec is a good catch-all mailing list.
    – forest
    Commented Aug 15, 2019 at 5:57
  • 1
    Can somebody point out to me how can client side library on it's own be a vulnerability in any case? For any attack to occur, attacker needs to first execute some code on client's side. Short of eval(window.location.hash) I don't see how a library that manipulates HTML can be vulnerable to attack without the website already being compromised.
    – Tomáš Zato
    Commented Aug 16, 2019 at 14:40
37

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.

Improve this answer
12

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.

Improve this answer
2
  • "unless you never scan yourself, hiding [version numbers] is shooting yourself in the foot." Except there exists a development team that made the software. They know what version they used and can check it for vulnerabilities. Doing that is as uncommon as running vulnerability scans on yourself (almost nobody does either), but if you have to pick one, I would rather check the version numbers myself than expose them for everyone to see. Yes, targeted attackers will use other means to get the info, but that doesn't mean you want to make it easy for either them or the script kiddies.
    – Luc
    Commented Aug 14, 2019 at 7:34
  • 3
    If you are easy target for script kiddies, then exposed version numbers are the least of your problems. I agree dev team should check for vulns, but you know what? They aren't security experts and you are. There is some sense in running scans instead of trusting the dev team on this. Ideally, you'd do both.
    – Tom
    Commented Aug 14, 2019 at 11:28
0

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.

Improve this answer
0

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .