- Issue created by @akalata
This issue was discussed by the Drupal Security Team, and their decision was that this can be solved in a public issue.
This module has a XSS vulnerability in its AJAX handling, similar to this recent Drupal core SA: https://www.drupal.org/sa-core-2020-007 β
The views-autocomplete-filters-dependent.js uses jQuery's $.ajax and where the AJAX url could potentially be controlled by an attacker.
Original report from reporter @millionleaves:
--------------------------
I'm using VirusDie as a malware scanner on a D7 site running D7.73.
It's reporting a vulnerability in this plugin, in line 7 of
views-autocomplete-filters-dependent.js, which it says is related to this
security advisory (which the 7.73 core release addressed):
https://www.drupal.org/sa-core-2020-007 β
The function it has flagged starts with this line:
Drupal.ACDB.prototype.search = function (searchString) {
I don't know if this is a false positive or if this function is actually
vulnerable. Thought I'd raise it here before checking with VirusDie support.
Unable to determine how to exploit this.
@mr.baileys commented
> This seems like a false positive. The module correctly escapes the supplied input used as part of the autocomplete-URL. Since there is no way to add "=?" or "??" to the URL to force a callback function, I don't think there is a way to exploit this or promote the request to JSONP. Adding "jsonp: false" to the call still seems sensible, but does not seem necessary in this case and should be considered (public) security hardening.
$.ajax({ type: 'GET', url: db.uri + '/' + Drupal.encodePath(searchString), ...
>
> Example URL when attempting to pass a callback-function:
>
> http://d7.ddev.site/index.php?q=autocomplete_filter/title/content/page/0..."
@ram4nd added a patch.
Active
1.0
Code
It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.