Possible false positive: wordpress xili language plugin xss vulnerability

Vulnerability Tests
1

The vulnerability “WordPress Xili Language Plugin XSS Vulnerability” is reported.
id = 1.3.6.1.4.1.25623.1.0.803600

This plugin is not installed on the server, but the newest wpml plugin.

The nasl file is opening the url. If I test this link on my browser, there is no “alert” message.

url = dir + "/?lang=%22><script>alert(12345)</script>";

if(http_vuln_check(port:port, url:url, check_header:TRUE,
   pattern:"<script>alert\(12345\)</script>"))
{
  report = http_report_vuln_url(port:port, url:url);
  security_message(port:port, data:report);
  exit(0);
}

Is this a false positive?

2

Only a few short more generic notes:

  • Answering “is this a false positive” is usually only possible when having direct access to the target and in most cases it is the responsibility of the user to verify/clarify this
  • Most modern browsers AFAICT have build-in XSS protection so opening the URL might not always “trigger” the XSS
  • The VT in question is doing / checking the flaw in a generic way so any other plugin besides Xili Language could be affected as well
  • Such older XSS VTs (this one is from 2013) might be a little bit more false positive prone so there is a chance of a false positive
2 Likes
4

I’m curious about how NASL pattern: function works. I know that OWASP ZAP Proxy gives false positives for XSS exploitation when the “payload” is reflected in the page such as when it’s included as an error output. I’ve even seen this error in the “invisible” parts of the page. Try loading the source code from the page and search for the pattern manually - you might find out what’s going on.

1 Like
5

Please note this forums is not a free resource of security consulting. If you are in question and you are not able to judge this, i would strongly advise to get professional help on this topic. As far as the community can help you CFI responded to your question.

8

Me too. This could be the hint, no error but the payload is in the page’s source code as a link multiple times.

9

Yes, OWASP ZAP also commonly has this false positive.

1 Like
10

What could be done from Greenbone side is:

  1. Lower the QoD to remote_analysis to make it more clear that additional user verification is required for such active XSS flaws (from 11 Reports and Vulnerability Management — Greenbone Enterprise Appliance 22.04.17 documentation):

    Remote checks that perform some analysis, but may not always be completely reliable depending on environmental conditions. Narrowing down suspected false-positive or false-negative edge cases may require analysis by the user (see Chapter 11.8).

  2. Make the response pattern check in the VT in question a little bit more strict to only report if it matches the response of an affected plugin installation

Notes:

  • Nr. 1 has been been already done and should be already included in the feed
  • Doing / adding the more strict response check might take quite some time and it won’t guarantee that the target in question is actually not affected. It is still required by the OP to verify that the system in question is not vulnerable
3 Likes