Last modified: 2010-05-15 15:33:42 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1477 - Ability to hide MySQL Errors
Ability to hide MySQL Errors
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.4.x
PC Linux
: High critical (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-06 04:13 UTC by Paul Laudanski
Modified: 2010-05-15 15:33 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Paul Laudanski 2005-02-06 04:13:07 UTC
I have searched both the closed and open bug reports for "hide mysql errors" and
could not find a solution.  As this is my first time using MediaWiki (and
checking Docs & Google for the answer), there ought to be an option to disable,
or hide MySQL errors from displaying.

Running MediaWiki on a production server having mysql errors displayed can
create security risks.  Bug #1057 is an example of this.  If there is an option
somewhere I'd be highly appreciative if you can guide me there. Otherwise, I'd
like to request this as a feature as soon as possible.

Thanks everyone.  I'll start pouring over the code in the meantime to see if I
can find something.

http://castlecops.com
Comment 1 Brion Vibber 2005-02-06 04:37:31 UTC
Note that because the software is open source, an attacker can find 
potential SQL injection problems without access to _your_ installation 
simply by re-enabling the error display on their local installation. Thus 
the benefits from obscuration of errors is going to be relatively limited.

Probably the simplest way to hide the errors would be to edit the 
OutputPage::databaseError() function in includes/OutputPage.php. You 
could prune out the message reporting (not including detailed error 
information) or even just have it die out with a 500 Internal Server Error.
Comment 2 Paul Laudanski 2005-02-06 04:47:55 UTC
(In reply to comment #1)
> Note that because the software is open source, an attacker can find 
> potential SQL injection problems without access to _your_ installation 
> simply by re-enabling the error display on their local installation. Thus 
> the benefits from obscuration of errors is going to be relatively limited.

You're right, which is precisely why additional security measures have been
taken in the server installation.  However, obscuring the errors do help to
prevent from displaying table names.  Many (but not all) SQL Injection
techniques rely on knowing table names.  Why provide the mechanism on a
production site to show the backend?

> Probably the simplest way to hide the errors would be to edit the 
> OutputPage::databaseError() function in includes/OutputPage.php. You 
> could prune out the message reporting (not including detailed error 
> information) or even just have it die out with a 500 Internal Server Error.

Thanks for the direct file path.  On quick inspection, it looks like

                        print $msg."\n";

Is the line that requires modification, or at the least, disable showing the
error on a prod site.  Development, I'd leave this in place.

Perhaps offering a special setting in LocalSettings.php defining a $debug value
which would show those errors as required. 

I'll report back after some testing.
Comment 3 Brion Vibber 2005-02-06 05:57:13 UTC
Committed to REL1_4 and HEAD:
http://mail.wikipedia.org/pipermail/mediawiki-cvs/2005-February/006515.html

Set $wgShowSQLErrors = true to enable database error display, off by default.
Comment 4 Paul Laudanski 2005-02-06 15:51:57 UTC
(In reply to comment #3)
> http://mail.wikipedia.org/pipermail/mediawiki-cvs/2005-February/006515.html

Much obliged.  Implemented and confirmed.  Now "Internal Error" is displayed
instead.  I may fire off a bugtraq FYI on this and direct folks back here.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links