In jQuery you can specify a CSS selector and HTML code with the same shorthand.
This is a selector:
This is HTML that gets evaluated immediately:
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));
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
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 ...
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:
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 ...
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. ...
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 ...
And JQuery cannot provide any additional functionality that circumvents this.
This appears to ...
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 ...
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 ...
The way to safely print untrusted data in HTML is by replacing HTML-significant characters with character entities. (That is, you'd replace < with <, 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 ...
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:
Retire.js (free open source tool maintained by me) will tell you if the ...
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.
It's a false positive.
obj.value = '" onClick=...
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,...
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.
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.
As you started to mention, CSRF is only really useful for actions that change state, so this is not truly an example of CSRF.
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 ...
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 ...
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.
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 ...
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 ...
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.
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 ...
You should be looking for:
Encrypted passwords like hashes
Encrypted / scrambled code
References to external websites, like IP addresses, domain names
These are common signs of backdoor in web based code.
Patches 9521 and 11290 several years ago attempt to mitigate this issue, although does not claim to completely remove the possibility for XSS. I've been running in jQuery 2.x some of the exploits they claim still exist, but they don't seem to be working, so I can't definitely confirm and deny if the code you provided is enough to exploit.
For what it's ...
jQuery's .html() is dangerous. It parses and evaluates content using eval(), which is frowned upon. html() actually finds <script>tags and executes them, on purpose! Normally when adding such tags as a string they fall into place silently as benign content w/o execution.
If you would use the construct elm.innerHTML=str; instead of $(elm).html(str), ...
Your example starts by disabling CSP's inline script and eval protection, which are its primary two security controls; particularly the inline one as it is the main way of preventing XSS.
Then you run a script which writes a <script> tag into the page, causing it to be placed into the page. If you'd have manually written the same script tag into the ...
This was a pretty common XSS attack vector in jQuery, and can still affect sites using an outdated version of jQuery.
Basically, if a string was an invalid selector, jQuery would assume it was HTML, and parse it as HTML. In jQuery version 1.9 jQuery mitigated this risk by only parsing a string as HTML if it started with &...