Page MenuHomePhabricator

Nessus Scan Revealed High Finding
Closed, ResolvedPublic


MW Version: 1.32.1

Using the GET HTTP method, Nessus found that :

+ The following resources may be vulnerable to blind SQL injection :

+ The 'skin' parameter of the /load.php CGI :


-------- output --------
HTTP/1.1 200 OK
-------- vs --------
HTTP/1.1 404 Not Found

+ The 'modules' parameter of the /api.php CGI :


-------- output --------
HTTP/1.1 200 OK
-------- vs --------
HTTP/1.1 404 Not Found
•	Discovery
o	First Discovered: Today
o	Last Observed: Today
•	Host Information
o	IP Address: [redacted] ( 443 / TCP )
o	DNS: [redacted]
o	NetBIOS: [redacted]
o	Repository: Individual Scan
•	Risk Information
o	Risk Factor: High
o	CVSS v2 Base Score: 7.5
o	CVSS v2 Vector: AV:N/AC:L/Au:N/C:P/I:P/A:P
•	Exploit Information
o	Exploit Available: No
•	Plugin Details
o	Plugin ID: 42424
o	Published: Nov 6, 2009
o	Last Modified: Nov 15, 2018
o	Family: CGI abuses
o	Version: 1.34
o	Type: remote
•	Reference Information
o	CWE: CWE-20 CWE-722 CWE-751 CWE-801 CWE-89 CWE-77 CWE-713 CWE-727 CWE-203 CWE-810 CWE-643 CWE-91 CWE-928 CWE-929


Event Timeline

sbassett triaged this task as Medium priority.Jul 19 2019, 8:08 PM

Without looking into these further, I'm going to guess they are false positives. The way many of these automated scanning tools work is that if they can fuzz a query parameter or two for a url (in this case with sqli payloads) and elicit different http response codes, they assume there's a blind sqli. That's almost certainly not the case for load.php and api.php, but we can keep this security-protected until someone has the chance to further investigate.

Neither of these are... The api.php one complains about bad params. It's definitely not doing an SQL query

<warnings><main xml:space="preserve">Unrecognized parameters: recursivesubmodules, modules.</main></warnings>

The load.php one doesn't do an SQL query for the skin parameter either, not that that's what it's complaining about anyway (at least on enwiki)

Problematic modules: {"mediawiki.legacy.commonPrint%2Cshared%7Cmediawiki.skinning.interface%7Cskins.vector.styles":"missing"}
Krinkle moved this task from Inbox to External on the MediaWiki-ResourceLoader board.
Krinkle subscribed.

Indeed. Both are working as intended. The invalid parameters are correctly rejected by the respective request handlers.

sbassett claimed this task.

Not seeing any particularly sensitive information here, and since these were confirmed as false positives, I'm going to resolve this task and make it public.

sbassett changed the visibility from "Custom Policy" to "Public (No Login Required)".Jul 22 2019, 1:44 PM
sbassett moved this task from Incoming to Our Part Is Done on the Security-Team board.

While I understand that there's no SQL query executed here, is it really harmless to have Mediawiki echo everything back that is passed in the URL? In a Mediawiki 1.34.0 installation I get:

$ curl -L

Curiously enough, when calling something else (i.e. not "modules") the standard placeholder is returned:

$ curl -L
/* This file is the Web entry point for MediaWiki's ResourceLoader:
   <>. In this request,
   no modules were requested. Max made me put this here. */

IOW, shouldn't Mediawiki return the same placeholder for everything else except modules=skins.vector.styles (and all the other installed modules)?

We want client side to be able to detect missing modules.

There are scenarios where reflecting input can be dangerous, but i think proper precautions are taken here

Indeed. This is no different from searching for a word on a search engine and the response including "You searched for …"

All text displayed on the web needs to be escaped for HTML to render correctly. Security is merely a compounding factor. Even "trusted" text must be escaped in order to render correctly, otherwise special characters can take up different meanings leading to all kinds of functional problems.

Unless you find unescaped or wrongly escaped content (regardless of whether it came from the user or not), there is no problem. The convention in security analysis is to emulate user input, I believe because that makes it easier to verify a problem because the original input is right next to it. Problems with trusted input are harder to verify because you might not know the original (perhaps the original already had the problem, etc.)

OK, understood. Thanks for clearing that up! 👍