XSS vulnerability scanner false positives
OpenPublic

Description

Several API formats allow the inclusion of arbitrary HTML in responses, and XSS is prevented only by the Content-Type header. This causes a false positive in McAfee Secure and possibly other vulnerability scanners. McAfee can be petitioned to recognise such scan responses as false positives, but this process is difficult and unreliable, and has to be repeated regularly.

I would like to have a configurable "scan-safe" mode, off by default, which will disable the following output formats: php, txt, dbg and dump. The documentation should be updated to indicate that these formats are not preferred and will not work on all installations.

Additionally, json_encode() should use the JSON_HEX_TAG option where it is available (i.e. PHP 5.3.0+), regardless of configuration. In scan-safe mode in PHP<5.3, a JSON encoder which does not pass through "<" characters should be used.


Version: 1.20.x
Severity: normal

bzimport added a project: MediaWiki-API.Via ConduitNov 22 2014, 12:15 AM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz34257.
tstarling created this task.Via LegacyFeb 7 2012, 11:58 PM
MZMcBride added a comment.Via ConduitFeb 8 2012, 12:02 AM

(In reply to comment #0)

I would like to have a configurable "scan-safe" mode, off by default, which
will disable the following output formats: php, txt, dbg and dump. The
documentation should be updated to indicate that these formats are not
preferred and will not work on all installations.

With Roan's recommendation, I'd actually go a bit further and recommend to end-users to only use JSON.

Catrope added a comment.Via ConduitFeb 8 2012, 2:08 PM

(In reply to comment #1)

(In reply to comment #0)
> I would like to have a configurable "scan-safe" mode, off by default, which
> will disable the following output formats: php, txt, dbg and dump. The
> documentation should be updated to indicate that these formats are not
> preferred and will not work on all installations.

That can be done for sure.

With Roan's recommendation, I'd actually go a bit further and recommend to
end-users to only use JSON.

Yeah I'd really like people to only use JSON, and if I were to start rewriting the API today I'd make it JSON-only.

Rich_Farmbrough added a comment.Via ConduitFeb 15 2012, 9:23 PM

XML is much easier to parse than JSON, in reality if not in theory. I'm not sure, though, that we should worry about McAfee, if the AV writers can't do their job then they will loose market share. I've lost count of the systems that have been fixed by removing shop-installed AV software. And one AV package has even detected /strawberry/bin/perl.exe as "an unknown threat".

Reedy added a comment.Via ConduitFeb 15 2012, 10:26 PM

(In reply to comment #4)

XML is much easier to parse than JSON, in reality if not in theory. I'm not
sure, though, that we should worry about McAfee, if the AV writers can't do
their job then they will loose market share. I've lost count of the systems
that have been fixed by removing shop-installed AV software. And one AV
package has even detected /strawberry/bin/perl.exe as "an unknown threat".

These things came up from the fundraising quarterly PCI scans

https://rt.wikimedia.org/Ticket/Display.html?id=2374 for anyone who has access and wants to see

bzimport added a comment.Via ConduitApr 4 2012, 8:23 PM

alext wrote:

Hello, I just want to share this with the Mediawiki community for reference.

A vulnerability scan of a Mediawiki 1.18.1 installation was falsely flagged as positive on an XSS injection attempt.

The injection url looks something like "https://site-address/load.php?debug=false&lang=en&modules=mediawiki.legacy.common..." and was replaced with "https://site-address/load.php?debug=false&lang=<script>somescript&modules=mediawiki.legacy.common..."

Mediawiki correctly issued a message saying that "<script>somescript" is an invalid language code but the vulnerability scanner falsely interpreted the echoed message as a positive injection.

Catrope added a comment.Via ConduitApr 12 2012, 6:46 AM

(In reply to comment #6)

Mediawiki correctly issued a message saying that "<script>somescript" is an
invalid language code but the vulnerability scanner falsely interpreted the
echoed message as a positive injection.

Confirmed that this is a false positive. The Content-Type of the response is text/javascript, the injected text is wrapped in a comment, and injection of "*/" is protected against. Tested in Chromium and IE.

Anomie moved this task to Needs plan on the MediaWiki-API workboard.Via WebFeb 20 2015, 4:48 PM
Legoktm added a subscriber: Legoktm.Via WebFeb 21 2015, 1:47 AM

Add Comment