38

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?

atk
  • 2,156
  • 14
  • 15
stormtrooper
  • 481
  • 1
  • 4
  • 4
  • 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 Aug 13 '19 at 09: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 Aug 13 '19 at 09: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. –  Aug 13 '19 at 13:55
  • @MechMK1 not if you add unreachable code (like `if(true===false){}`) or random whitespace somewhere/everywhere then their automatic matchers wouldn't be able to definitively match a version. – MonkeyZeus Aug 15 '19 at 14:32
  • 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. –  Aug 15 '19 at 14:35
  • @MechMK1 It's been mentioned countless times that if an attacker is specifically targeting you then none of this matters especially when talking about code sent to the client like JS but if you're just trying to avoid script kiddies then even the slightest obscurity "helps". The real security misconfiguration is using a vulnerable version. Even if you're not using a vulnerable version it is dead simple to make the browser use a vulnerable version. Quite honestly if your website is vulnerable because of JS then you are doing something wrong from a security standpoint. – MonkeyZeus Aug 15 '19 at 14:59
  • 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. –  Aug 15 '19 at 15:56
  • @MechMK1 Copy+Paste+Enter into your console window: `var script = document.createElement('script'); script.type = 'text/javascript'; script.src = 'https://ajax.googleapis.com/ajax/libs/jquery/1.2.3/jquery.min.js'; document.head.appendChild(script); alert(jQuery.fn.jquery);` – MonkeyZeus Aug 15 '19 at 16:39
  • Spending time trying to hide client side libraries versions, instead of spending time fixing real security issues potentially makes you more vulnerable. – whirlwin Aug 15 '19 at 17:54
  • 1
    @MonkeyZeus Yes, but you can only do this to yourself, not to others. You couldn't, for instance, cause me to use a vulnerable jQuery version. –  Aug 15 '19 at 18:07
  • I don't see any indication on https://jquery.org/license/ that the version number needs to remain intact. It says the copyright header needs to... as long as you've got the `Copyright 2005, 2014 jQuery Foundation, Inc. and other contributors; Released under the MIT license; http://jquery.org/license` I wouldn't expect them to bat an eye. – ceejayoz Aug 15 '19 at 22:06
  • @ceejayoz As mentioned earlier, it would not help you anyways to obscure the version. –  Aug 16 '19 at 10:24
  • @MechMK1 Sure, but it'd help OP get the client's security scanner off their back. – ceejayoz Aug 16 '19 at 13:06
  • @ceejayoz "Fixing" problems to make the scanner stop complaining is one of **the worst** things you can do. Sure, deleting a version in a license file isn't enough, but it's the fundamentally wrong approach. Stuff like this is why the Debian PRNG bug came to be. –  Aug 16 '19 at 13:49
  • @MechMK1 As long as OP has a safe version of jQuery, the scanner result here is a *false positive*. I'm not advocating for covering up an insecure version; I'm saying the version disclosure being flagged can be dealt with safely in this fashion. – ceejayoz Aug 16 '19 at 14:09
  • @ceejayoz Yes, that's true, and in this specific case I wouldn't see a problem with it. But I would argue that in general, it's better to learn how to label reports as false positives, rather than to rush and implement a "fix". –  Aug 16 '19 at 14:12
  • 1
    @MechMK1 Fair enough, I can agree to that. – ceejayoz Aug 16 '19 at 14:15

5 Answers5

64

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.

Sjoerd
  • 28,707
  • 12
  • 74
  • 102
  • 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 Aug 13 '19 at 09:45
  • 14
    @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 Aug 14 '19 at 01:07
  • @Kaiido Nice, I didn't know of `$.fn.jquery`. I'm not sure if this is a lucky coincidence or if it's common for other libraries to have this as well though. Looking up the library I see second-most commonly, Bootstrap, it [doesn't seem like](https://stackoverflow.com/questions/15335537/how-to-identify-bootstrap-version) there is such a function for that. – Luc Aug 14 '19 at 07:29
  • 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: https://stackoverflow.com/questions/43233588/how-can-i-get-bootstrap-version-via-javascript – Kaiido Aug 14 '19 at 08:01
  • @Sjoerd What mailing lists would you reccomend for a web-based system (Apache, nginx, JQuery, SSH, FTP, server packages in general)? – Echo Aug 14 '19 at 09:34
  • @echo there are tools specifically designed for monitoring vulnerabilities in 3rd party components. Two of the commercial leaders in the space are current Palamida and Black Duck, but if you do some google searching you can come up with a list of newer products at different pricing (some free, but requiring substantial manual work) that might suit your needs better. – atk Aug 15 '19 at 03:37
  • 1
    @Echo They generally all have their own mailing lists. However oss-sec is a good catch-all mailing list. – forest Aug 15 '19 at 05: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 - Reinstate Monica Aug 16 '19 at 14:40
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 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.

schroeder
  • 123,438
  • 55
  • 284
  • 319
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.

Tom
  • 10,124
  • 18
  • 51
  • "*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 Aug 14 '19 at 07: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 Aug 14 '19 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.

Lightness Races in Orbit
  • 2,173
  • 2
  • 14
  • 15
jfran3
  • 111
  • 9
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.

rackandboneman
  • 975
  • 4
  • 9