Hot answers tagged

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 ...


44

In jQuery you can specify a CSS selector and HTML code with the same shorthand. This is a selector: $('#some-thing') This is HTML that gets evaluated immediately: $('<svg onload=alert(1)>') This is a real-life code sample for parsing a selector from the location hash (the URL part after a #): var x = $('#' + window.location.hash.substr(1)); x....


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 ...


11

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 ...


10

Introduction CSP should be enforced by the browser as long as you stay on the page, and not just while it is originally loaded or rendered. Everything else would make it quite toothless. So the behaviour you are experiencing has nothing to do with when the script is loaded. Instead it is about what loads it. There are two issues. Problem 1: strict-dynamic ...


8

To get away from the reported issues, (which will show up via projects like retire JS), you'll need to use a JQuery version in the 3.x line. At least one of the commonly referenced issues (this one) required breaking changes and as such was never fixed in the 1.X stream. The current latest version is 3.2.1 and I'm not aware of it having any disclosed XSS ...


6

It's a false positive. In both cases, the scanner only searched for "root:", assuming it is part of a passwd file. The line that is found is: root:function(a){return a===o} This is obviously not from a passwd file. It is also very unlikely that any server-side vulnerability exists in a request for a jQuery file, generally they are static files that are ...


5

One imperfect solution is to rely on reputation. Does the library have many users? Lots of downloads at GitHub or npm? An active community? Do any large established actors use it? A backdoor in jQuery would have been discovered by now, but one in a small obscure library might not. If that is not good enough for you, the next step is to go through the code. ...


4

This code snippet is vulnerable to XSS in jQuery prior to 1.9 (and in conjunction with the jQuery Migrate plugin). Even now, it remains at least a bad practice. The string argument to $() (shortcut for jQuery()) can be parsed either as a CSS selector or HTML code. Parsing the string as HTML implies an XSS vulnerability, just as document.write() would. On ...


4

No, JQuery is a client-side technology, which is really a wrapper for JavaScript for use within a web-browser only JavaScript doesn't have the capability to run OS commands when invoked by a browser, unless security settings are lowered within Internet Explorer. And JQuery cannot provide any additional functionality that circumvents this. This appears to ...


4

What jQuery actually does when you use attr(name, value) is to call setAttribute(name, value) on the relevant DOM elements. Not at home in the jQuery source, but I think this is the relevant part. This means that you can not escape out of the attribute context. So it is as safe as vanilla JS is. What you need to look out for is the following: Don't let the ...


3

One important distinction to make here is that only because the jQuery library contains known vulnerabilities, it does not mean that the website is vulnerable to the contained vulnerability. As with many libraries, a website using jQuery will only be affected by a vulnerability if it uses the vulnerable function in vulnerable way. If it does not use the ...


3

The way to safely print untrusted data in HTML is by replacing HTML-significant characters with character entities. (That is, you'd replace < with &lt;, etc.) I suppose this is what you mean by "HTML escaping". Now, if you filter untrusted HTML that way, you can't trigger XSS with jQuery's html() anymore. E.g., this will just print plain text without ...


3

Whether or not the client is vulnerable depends on the version of jQuery and on whether or not they are also loading jQuery migrate. I built this test site a while back, where I test different versions of jQuery against two of these bugs: http://research.insecurelabs.org/jquery/test/ Retire.js (free open source tool maintained by me) will tell you if the ...


3

You don't understand what you are doing. All PHP code (and also the backtick/exec/system commands) is executed on the server. There is no portable/reliable way to get the MAC address. Maybe a browser plugin could do that. Consider that the client can also not have any MAC addresses at all. For example when connecting via PPP.


3

It's a false positive. Reporting false code injection vulnerabilities is a well-known problem with HP Fortify and has confused developers before. Fortify just does basic static analysis of the Javascript code and can't go arbitrarily deep to understand how it works. As @AlexanderOMara suggested, it just seems to discover the potentially dangerous setTimeout(...


3

This does not work. The browser has to be able to read the link, and as soon as the browser is able to do that, the user is able to do that.


2

You can use subresource integrity. This prevents an attacker from altering scripts. It adds a hash to the script tag, and if that hash does not match with the script it does not get executed.


2

No, I don't think you can use it for XSS. Since the possibly unsafe object is passed to val() you should be fine. That function sets the value attribute. Whatever you set the value attribute to, you can not make it execute code. Since it manipulates the DOM and not the HTML source, something like this is completely safe in JavaScript: obj.value = '" onClick=...


2

When updating a library, you should indeed remove the (possibly problematic) code from the server. This is also true if the web application is not using the vulnerable parts of the library. There is a good reason for that: Served from that web server, the problematic code can possibly be leveraged in an attack that otherwise would be mitigated by CSP. If ...


2

As long as CORS is correctly configured, it is not possible to extract information from another domain via JavaScript. You should also check that your JSON endpoints return an object, and not an array, to protect against JSON Hijacking, an old vulnerability affecting old browsers.


2

As you started to mention, CSRF is only really useful for actions that change state, so this is not truly an example of CSRF. From OWASP: Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated. CSRF attacks specifically target state-changing ...


2

There's not really anything else major you can do. There's a few minor things, which I'll get to, but the basic pattern you describe is used near-universally for good reason. Just based on the steps you describe, if somebody were to have their credentials compromised, I would very strongly suspect it to have nothing to do with your HTTPS or password handling,...


1

Software vulnerabilities can usually only be exploited when the code is actively used. Having said that you'd like to remove the old files if possible so some faulty implementation doesn't continue to use them (never assume that other software is working correctly). However, be aware that depending on the cache control settings the website set for jQuery ...


1

It depends on the vulnerability. For example, a XSS vulnerability is client-side only. As long as you stop including a vulnerable version of the library on your pages, your site won't be vulnerable, since clients won't load it anymore. Some JavaScript librairies also have a server-side part, for example a file upload plugin for jQuery. The server will ...


1

For the lib you linked you could audit the code by looking at it. The file you would link inside <script> tags should be read through. I would recommend AGAINST using the jquery-latest.js and instead using the version from the jquery homepage (since his version is minified). That being said, while looking through jquery.tablesorter.js ... it looks ...


1

Is this a limited vulnerability? It is limited in the sense that the vulnerability can only apply if your application is querying via $.get an untrusty/compromised website. What could be its possible effects? As per the CVE, your application would be vulnerable to XSS and all of its implications. Should it be treated dangerous? As much as any XSS ...


1

No, there's not. If someone wants to attack one's own machine with JS, devtool's console tab is much easier than crafting a bad svg. XSS is only a problem when malicious code is shared with other users. If the user was unaware the file was malicious, it could present a problem, but it's not yours to deal with. Furthermore, the origin/protocol context in ...


1

I think it is safe to say at this point that there is no trivial/text-book bypass for this filter using a modern browser. I shared this snippet of code with a group of friends and colleagues who I consider proficient in XSS and none of them could construct a bypass.


1

If not user controlled, then it's not vulnerable to XSS. Someone somewhere must be able to inject script into data to make it vulnerable. appendTo isn't a sink in itself, however if it's appending free text to the DOM in this case then it could make the page vulnerable if data contains user input (read user input to be anything outside the security domain ...


Only top voted, non community-wiki answers of a minimum length are eligible