Skip to main content
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