jQuery Security Vulnerability Mitigation

A number of vulnerability issues have been found in jQuery throughout the years. These issues have been reported by various developers around the world on vulnerability tracking sites such as CVE, SNYK, and NVD. All these issues have now been fixed in jQuery and jQuery UI. These vulnerabilities are very unlikely to be exploited on ICEfaces, because ICEfaces doesn't directly use the affected parts of the code, and, in the case of cross-site scripting (XSS) vulnerabilities, user input always does a round trip to the server first to get processed, making it very difficult to inject arbitrary javascript on a page. Despite that, fixes for these vulnerabilities have now been ported onto the jQuery version used in ICEfaces (as of the ICEfaces EE 4.3.0.GA_P03, ICEfaces EE 3.3.0.GA_P09 releases), in order to completely remove any possibility of these exploits being used.

A comprehensive list of vulnerabilities in jQuery can be found on this CVE Page. Of those, only five of them apply to the jQuery version used by ICEfaces (1.12.4 for jQuery and 1.8.4 for jQuery UI). These vulnerabilities are listed below, along with technical explanations as to what was done in ICEfaces to mitigate them.

XSS, code passed in <option> elements

The issue was reported on CVE as follows:

In jQuery versions greater than or equal to 1.0.3 and before 3.5.0, passing HTML containing <option> elements from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.

This corresponds to CVE-2020-11023 and SNYK-JS-JQUERY-565129.

In ICEfaces we ported over a fix to make the jQuery.htmlPrefilter function an identity function, instead of using a regular expression to sanitize self-closing tags, which was causing this vulnerability.

This was very unlikely to happen in ICEfaces anyway, because nearly all the markup is rendered from the server, making it very difficult or impossible for someone to inject malicious code on a page. The few components that render option elements (ace:dataTable, ace:list, ace:simpleSelectOneMenu, and ace:themeSelect) do so in the server, without the intervention of jQuery.

XSS, passing html to DOM manipulation methods

The issue was reported on CVE as follows:

In jQuery versions greater than or equal to 1.2 and before 3.5.0, passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.

This corresponds to CVE-2020-11022 and SNYK-JS-JQUERY-567880.

This was fixed in the same way as the previous issue in ICEfaces. We ported over a fix to make the jQuery.htmlPrefilter function an identity function, instead of using a regular expression to sanitize self-closing tags, which was causing this vulnerability.

Again, this was very unlikely to happen in ICEfaces anyway, because nearly all the markup is rendered from the server, making it very difficult or impossible for someone to inject malicious code on a page.

XSS, missing 'dataType' property in ajax request.

This issue was reported on CVE as follows:

jQuery before 3.0.0 is vulnerable to Cross-site Scripting (XSS) attacks when a cross-domain Ajax request is performed without the dataType option, causing text/javascript responses to be executed.

This was fixed by only executing scripts in ajax requests if they have explicitly set the dataType property.

This was very unlikely to happen in ICEfaces anyway, because ICEfaces doesn't use the jQuery ajax functionality whatsoever. ICEfaces uses it's own ajax functionality as well as JSF's.

Prototype pollution

This issue was reported on SNYK as follows:

Affected versions of this package are vulnerable to Prototype Pollution. The extend function can be tricked into modifying the prototype of Object when the attacker controls part of the structure passed to this function. This can let an attacker add or modify an existing property that will then exist on all objects.

This was fixed by checking for the _proto_ key in the jQuery.extend function to skip extending those passed prototype properties.

jQuery UI, 'closeText' parameter in Dialog widget

This issue was reported on CVE as follows:

Cross-site scripting (XSS) vulnerability in jQuery UI before 1.12.0 might allow remote attackers to inject arbitrary web script or HTML via the closeText parameter of the dialog function.

This was fixed by escaping the closeText option in Dialog widget.

This was very unlikely to happen in ICEfaces anyway, because the ace:dialog component doesn't use the closeText option in Dialog widget of jQuery UI.

Other Observations

No matter which frameworks or platforms are in use in a web application, validating and sanitizing user input is always an excellent and effective measure that will prevent the vast majority of security issues.

OWASP ZAP Security Scan

The OWASP Zed Attack Proxy (ZAP) tool is a popular free and open sourc security scan tool. We ran some automated scans, using the traditional spider (based on HTML markup) and the ajax spider (using a real browser) against various of our sample applications, including the ICEfacs showcase.

This tool focuses on Penetration Testing (pentesting), meaning that it simulates malicious attackers and actually tries to exploit well-known vulnerabilities, such as those documented for jQuery.

In all of the scans there were no high-risk alerts of any kind, and there were no cross-site scripting (XSS) alerts either, meaning that the tool wasn't able to exploit well-known vulnerabilities on our ICEfaces sample applications.

The four medium-risk alerts reported don't represent any real risk intrinsically in ICEfaces. They are described below:

• The mere detection of the jQuery version number used in ICEfaces, which has already been patched with the security fixes described above.
• The absence of the X-Frame-Options HTTP header to avoid click-jacking attacks. This can be configured at the application code level.
• Using the session ID in the URL, which is done by certain application servers in some cases and can be configured to avoid that behaviour.
• Some warnings about error page handling, which can be avoided at the application code level as well.

There were other minor warnings and informational alerts that don't represent real risks. Most of them can be dealt with at the application code level as well.

The automated scans provide a high degree of reassurance that our code is secure, however they can't possibly cover all specific cases of every application. If you are interested in thoroughly testing your application against security vulnerabilities, manual testing is recommended. More information on the subject can be found on the OWASP ZAP website.