Multiple vulnerabilities in jQuery Mobile
All current versions of jQuery Mobile (JQM) as of 2019-05-04 are vulnerable to DOM-based Cross-Site Scripting (XSS) via crafted URLs. In JQM versions up to and including 1.2.1, the only requirement is that the library is included in a web application. In versions > 1.2.1, the web application must also contain a server-side API that reflects back user input as part of an HTTP response of any type. Practically all non-trivial web applications contain at least one such API.
Additionally, all current versions of JQM contain a broken implementation of a URL parser, which can lead to security issues in affected applications.
No official patch is available as JQM no longer appears to be actively maintained. Migrate to an alternative framework if possible.
In 2017, @sirdarckcat published a vulnerability in JQM that allowed an attacker to perform XSS attacks on any applications that also had a server-side open redirection vulnerability in them. If you're not familiar with @sirdarckcat's research, read that first.
The vulnerability was reported to the JQM maintainers, but was left unpatched for two reasons:
- Exploiting it required the use of another pre-existing vulnerability
- Patching would have risked breaking compatibility with exising applications
We've identified two ways of exploiting the aforementioned vulnerability without having to rely on open redirection. The first one works in all versions of jQuery Mobile, as long as certain functionality is present in the same web application. The second technique places no requirements on the web application, but only works in jQuery Mobile versions up to and including 1.2.1. It may, however, have other security implications even in more recent branches of the library.
Missing content-type validation
The idea of the first technique is to exploit the fact that jQuery Mobile does not validate the content-type of the XHR response sirdarckcat is exploiting for XSS. Instead of relying on open redirection, an attacker can use any same-origin URL that reflects back user input from a GET parameter.
Consider a REST search API.
The response format would be something like the following:
example.com contains both this API and a jQuery Mobile application, an attacker would be able to gain XSS as follows:
When a user opens this link, the jQuery Mobile application makes an XHR request to
This is more severe than sirdackcat's original exploit, since no server-side vulnerability is required, only fairly normal functionality.
Broken URL parsing
The second technique exploits the URL parser implemented in
jQuery.mobile.path.parseUrl. This parser is based on a regular expression,
urlParseRE, that looks like the following:
This is terribly broken and fails in the most basic forms of URL validation. Consider the following:
true in all versions of jQuery Mobile, even though the domain of the first URL is
evil.example and the second
In jQuery Mobile versions ≤ 1.2.1, an XSS exploit would look like the following:
jQuery Mobile parses the URL, determines it to be same-origin (even though it clearly isn't), issues a request, and loads a malicious payload into the DOM. On the attacker's side this merely requires setting up a server at
evil.example to serve the payload along with appropriate CORS headers.
On jQuery Mobile ≥ 1.3.0 the XSS exploit doesn't work, since the navigation logic has been largely rewritten. The URL parsing flaw may still impact other parts of the library and applications that rely on it.
|2018-12-01||Attempted to contact maintainers via GitHub|
|2018-12-02||Attempted to contact maintainers via email|
|2018-12-14||Repeated attempt to contact via email|
|2018-12-21||Reopened GitHub ticket|
|2019-02-01||Set 90 deadline for public disclosure|
|2019-03-06||Successfully contacted maintainers via Slack|
|2019-03-06||Received short reply to previous emails, "seems worth fixing", followed by complete radio silence|