Timeline for Is it really Security Misconfiguration to show a version number?
Current License: CC BY-SA 4.0
28 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Aug 16, 2019 at 14:15 | comment | added | ceejayoz | @MechMK1 Fair enough, I can agree to that. | |
Aug 16, 2019 at 14:12 | comment | added | user163495 | @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, 2019 at 14:09 | comment | added | ceejayoz | @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. | |
Aug 16, 2019 at 13:49 | comment | added | user163495 | @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, 2019 at 13:06 | comment | added | ceejayoz | @MechMK1 Sure, but it'd help OP get the client's security scanner off their back. | |
Aug 16, 2019 at 10:24 | comment | added | user163495 | @ceejayoz As mentioned earlier, it would not help you anyways to obscure the version. | |
Aug 15, 2019 at 22:06 | comment | added | ceejayoz |
I don't see any indication on 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.
|
|
Aug 15, 2019 at 19:38 | answer | added | rackandboneman | timeline score: 0 | |
Aug 15, 2019 at 18:07 | comment | added | user163495 | @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, 2019 at 17:54 | comment | added | whirlwin | Spending time trying to hide client side libraries versions, instead of spending time fixing real security issues potentially makes you more vulnerable. | |
Aug 15, 2019 at 16:39 | comment | added | MonkeyZeus |
@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);
|
|
Aug 15, 2019 at 15:56 | comment | added | user163495 | @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, 2019 at 14:59 | comment | added | MonkeyZeus | @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. | |
Aug 15, 2019 at 14:35 | comment | added | user163495 | @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, 2019 at 14:32 | comment | added | MonkeyZeus |
@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.
|
|
Aug 15, 2019 at 3:35 | history | edited | atk | CC BY-SA 4.0 |
spelling, grammar
|
Aug 14, 2019 at 4:38 | answer | added | Tom | timeline score: 12 | |
Aug 13, 2019 at 18:00 | history | tweeted | twitter.com/StackSecurity/status/1161336779343060992 | ||
Aug 13, 2019 at 16:48 | history | became hot network question | |||
Aug 13, 2019 at 13:55 | comment | added | user163495 | 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, 2019 at 9:49 | comment | added | Luc | "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. | |
Aug 13, 2019 at 9:26 | answer | added | schroeder♦ | timeline score: 37 | |
Aug 13, 2019 at 9:26 | answer | added | Sjoerd | timeline score: 65 | |
Aug 13, 2019 at 9:24 | answer | added | jfran3 | timeline score: 0 | |
Aug 13, 2019 at 9:23 | history | edited | schroeder♦ |
edited tags
|
|
Aug 13, 2019 at 9:22 | comment | added | schroeder♦ | 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. | |
Aug 13, 2019 at 8:35 | review | First posts | |||
Aug 13, 2019 at 12:35 | |||||
Aug 13, 2019 at 8:34 | history | asked | stormtrooper | CC BY-SA 4.0 |