Secure private server/database information from public eyes

you should have firewalls and passwords to protect your database. also, opening two issues are rude.

@OP: You can make a bug report out of a support request by changing the 'Category' during follow up.

Sorry, chx, but I have to disagree with you on this one. This issue at least warrants discussion before it gets tagged as won't fix. I agree it is rude to double-post, but the issue has merit.

These error messages are for the benefit of the administrator, but they appear world-wide to anyone who tries to access the site. As I stated, this can be fixed by a boolean value in settings.php that would allow an administrator to get additional information, should they require it.

Yes, it is obvious that firewalls and passwords "should" do the job. Unfortunately, shared hosting puts firewall configuration outside of the Drupal administrator's control. Why feed script kiddies with free information for their brute-force bots, when the information is only useful to the administrator? The current situation is not a logical design when it comes to security.

I'm opening the issue back up for discussion.

I'd have to agree that showing the database username probably isn't the best way to do this, because I know on my hosting, the database starts with the username of my shared account, which would make it easier to hack (cpaneluser_dbuser).

I think it should do something similar to update.php, and have a variable, like drubeedoo mentioned. Maybe something like:

# $debug = true; //uncomment this if you're having trouble getting the site to connect to the database

It could also be used to replace the option in admin->settings of whether to print errors to screen, IMO.

This isn't a bug, so I'm tagging it as a feature request and renaming it appropriately.

I'm hoping the current lack of concern for this aspect of security is due to visibility, not apathy. It would be good to see someone from the security team respond here. I realize the situation in this thread doesn't come up under normal circumstances, but I'm wondering what would happen if some low-life were to hammer a server with a DDoS attack. Would an overloaded MySQL server pop up this message in Drupal, thereby providing more information to hack into an e-commerce site?

My position is that there is no need to advertise details to the world-at-large. Administrators, who have a need to know, should have other ways of getting at this information. A global $debug variable/constant might be a good first step towards addressing this, as well as providing a standard debugging "mode" in Drupal that could be built-upon in the future.

Settings > Error Handling > Error reporting. Where Drupal, PHP and SQL errors are logged. On a production server it is recommended that errors are only written to the error log. On a test server it can be helpful to write logs to the screen.

Set this to only "write errors to the log".

Tytest not withstanding, those that actually read the issue, will note that it has nothing to do with settings, since a db connection cannot be made when this error comes up.

I also don't see the point of making public connection specific information. It's one thing to report that there's an error, but providing path and username information seems superfluous at best.

The default behavior should be not to display this information. That is, for example, simply strip the offending strings from the various database.inc.* files and make the true feature request/bug fix (as far as requiring slightly more work & testing beyond editing a string) to decide how to allow the administrator to show more information if the administrator wants it.

Attaching a patch for includes/database.mysql.inc.

Actually, since I last replied, I've had the (mis)fortune of seeing this come up quite often indeed on an oversold shared hosting server at Site5. The more generic the response from Drupal, the better, IMHO... including the removal of the Druplicon from the error page.

I haven't tried the patch (haven't researched how to apply patches yet), but will be doing so soon. Still no response from the security team, eh? hmmm... Too busy elsewhere with higher priorities. All in good time, I guess.

There's a trend called "secure by default" gaining momentum in the Linux world. Some distributions are going as far as disabling the root account except for use with su.

Drupal is somewhat vulnerable by default. Some of the defaults on the main "settings" page are the non-secure options. However, it's sometimes difficult to know which option is more or less secure, or what the tradeoff is between security and usability for each option. Since these settings have to be done for every Drupal install, this is pretty much a documentation feature.

When the database can't be connected to, or for any other massive failure, no information should be shown to the public including the vaguest hint as to the nature of the problem. It should say something like "under maintenance" or "we'll be back soon." Giving away the fact that the site is even using a database is a critical security flaw.

I wasn't aware there was a security team. How do I join? :)

Security Team is documented here: http://drupal.org/node/32750

I believe the head of the security team responded in item 1

If you want this issue to get more response you should

1) provide a patch for pgsql as well because that should also be supported
2) once that is done, change the status to "patch (code needs reviw)"
3) raise the visibility of the issue outside of the issue queue (e.g. with forum post, mailing list post)

Personally, I feel that the information shown on the error page currently is useful to new users setting up their system and requiring a change to a log setting will only make Drupal HARDER to use. That is not the direction most people want to go.

I have been saved plenty of time of troubleshooting by seeing that username or host on the error page and saying "duh...my username is not I need to edit the settings.php".

yes, the head of the security team responded in item 1.

if you want this issue to be changed you need to convince me that security by obscurity adds anything. not likely. closing again.

This is useful information when setting up your site and likely wonát show up ever again. Again, I do not see anything to be changed.

In the world of shared hosting we may not always have access or control over our MySql database, at times things may go down without our knowing it! If MySql goes down then as stated here the user name is exposed to the world and this should not be. As MySql isnt designed to lock out usernames after x number of failed login attempts then this provides an open door for someone to slowly hack away until the password is found. I understand that this is possibly valuable information for the EU setting up his drupal site but there should at least be an option to disable this or perhaps this information should only ever log to file. With the increasing popularity of Drupal and the increasing number of users who will be using shared hosts based on cPanel and fantastico setup scripts this should really be reconsidered. Perhaps provide a troubleshoot.php page that a user can hit if his site isnt working that by default is disabled.

@red_eye - opening the issue again isn't going to change chx's mind.

Consider the strategies laid out for getting a bug fixed faster such as writing the code you desire or hiring someone else to do so. If there is code written that implements the solution you want then it is easier to convince the core maintainers for inclusion of the patch.

Sorry greggles wasn't trying to do something wrong I just figured my comment wouldn't be noted at all if it was closed or whatever.

My point remains the same, I've worked in IT for nearly a decade and one simple rule is you don't write down password and you don't give out your user name. Security through obscurity is a lot better than saying hey I have a ton of data over here, and here is the database server and here is the user ID, now why don't you just see if you can figure out the password.

I understand nobody wants to write the code, nobody wants to do any work they fell isn't needed etc but since this is a CORE issue it should be considered. Especially since as I noted probably 40% or more of drupal installs are scripted installs through tools like fantastico on shared host sites where the actual security admin for the mysql server could give one flip about what the users do.

I believe I found a temporary but solid solution for this serious problem.

On my test platform, connection with database gets lost very often for some reason. That’s how I found out about this topic.

My solution is basically, hard (re-)coding the file /includes/database.mysql.inc

Find if (!$connection) { at around line 53

Change the error message or comment out beginning from print theme('maintenance_page', '<p>This either … to before of exit;

Here are my changes:

  $connection = @mysql_connect($url['host'], $url['user'], $url['pass'], TRUE, 2);
  if (!$connection) {
    drupal_maintenance_theme();
    drupal_set_title('Unable to connect to database server');
    print theme('maintenance_page', '<p>We apologize for any inconvenience.</p>
    <p>Please try <a href="javascript:window.location.reload();">refreshing</a> this page or going to <a href="/">home</a> page.</p>');
/*  print theme('maintenance_page', '<p>This either means that the username and password information in your settings.php file is incorrect or we can\'t contact the MySQL database server. This could mean your hosting provider\'s database server is down.</p>
<p>The MySQL error was: '. theme('placeholder', mysql_error()) .'.</p>
<p>Currently, the username is '. theme('placeholder', $url['user']) .' and the database server is '. theme('placeholder', $url['host']) .'.</p>
<ul>
  <li>Are you sure you have the correct username and password?</li>
  <li>Are you sure that you have typed the correct hostname?</li>
  <li>Are you sure that the database server is running?</li>
</ul>
<p>For more help, see the <a href="http://drupal.org/node/258">Installation and upgrading handbook</a>. If you are unsure what these terms mean you should probably contact your hosting provider.</p>');
*/
    exit;
  }

p.s. if it'll make a difference, my platform; Windows 2003 Server, Drupal 4.7.2, MySQL 5.0, PHP 5.1.2.2

p.s.s I'm new to drupal community and its rules. I didn't change the posting defaults 'cause I wasn't sure. OPs, may fix it without asking. thanks.