-
Suggestion
-
Resolution: Unresolved
-
None
-
202
-
Problem Definition
Currently, Jira uses jQuery version 2.2.4.
Additional notes
Jira relies on an Atlassian patched JQuery which is available in this Bitbucket repository.
Jira 8.20.1 is shipped with JQuery 2.2.4.10 – see the changelog for further details.
Related CVE: CVE-2015-9251
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.
Suggested Solution
Upgrade jQuery to one of the newer versions (3.5+)
- More info in the release notes
Security Fix
The main change in this release is a security fix, and it’s possible you will need to change your own code to adapt. Here’s why: jQuery used a regex in its jQuery.htmlPrefilter method to ensure that all closing tags were XHTML-compliant when passed to methods. For example, this prefilter ensured that a call like jQuery("<div class='hot' />") is actually converted to jQuery("<div class='hot'></div>"). Recently, an issue was reported that demonstrated the regex could introduce a cross-site scripting (XSS) vulnerability.
The HTML parser in jQuery <=3.4.1 usually did the right thing, but there were edge cases where parsing would have unintended consequences. The jQuery team agreed it was necessary to fix this in a minor release, even though some code relies on the previous behavior and may break. The jQuery.htmlPrefilter function does not use a regex in 3.5.0 and passes the string through unchanged.
If you absolutely need the old behavior, using the latest version of the jQuery migrate plugin provides a function to restore the old jQuery.htmlPrefilter. After including the plugin you can call jQuery.UNSAFE_restoreLegacyHtmlPrefilter() and jQuery will again ensure XHTML-compliant closing tags.
However, to sanitize user input properly, we also recommend using dompurify with the SAFE_FOR_JQUERY option to sanitize HTML from a user. If you don’t need the old behavior, but would still like to sanitize HTML from a user, dompurify should be used without the SAFE_FOR_JQUERY option, starting in jQuery 3.5.0. For more details, please see the 3.5 Upgrade Guide.
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JRASERVER-71172] Update the version of Jquery used in Jira
I got this answer from Atlassian Support the other day.
On version 8.15.0 we implemented an update on the Jquery version shipped with Jira. Although we did not upgrade our jQuery library to version 3.5, we cherry-picked and applied some patches from that version.
Any version after 8.15 has this fix. You can find more details on what change on Preparing for Jira 8.15
Also looking for an ETA on a fix for this. Jira is flagged by our Security team until it uses an acceptable version.
Atlassian: This is getting a bit ridiculous. You've already updated JQuery for Confluence, what is the hold up with updating it for Jira? We have active POA&Ms out on this issue and it is significantly impacting our system's cybersecurity health status. Honestly, not like you haven't updated this widget before...how much of an effort is it?
We also need more information about this. I've been told it will be addressed in Jira 9. Even a rough estimate of expected delivery quarter/year would help.
This issue needs to be addressed asap. Our security team flagged this issue during the Pen Test and required to be upgraded to the latest JS version.
+1, Our security team has also flagged this as an issue - looking for an ETA we can provide around resolution for this
Atlassian: I see via the Confluence 9.0 updates that JQuery will be updated to v3.X (v3.7.1 was the current version quoted in that page)...any idea what's taking so long with the update for Jira, not like you haven't had multiple updates of that product over the span of the months since this CVE came out. Please advise...
This should not be an issue to vote on - Atlassian should be addressing all Vulnerabilities - just like they do with their marketplace vendors - must address all vulnerabilities before submitting Apps, so why don't they do this themselves in their own apps?
My view: In the short term, this is a valid option. In the medium to long term, the version must be upgraded.