Thread

I have always had concern with config.php having db user and pw exposed in it…..but today my worse fears were realized when I was ftp into the site and changing some stuff…......what it was had nothing to do with config.php or any core EE files…or even any files related to the forums.

But, what happened was this - for a few seconds users were presented with a screen of garbled text including the full contents of config.php! I know for a fact that a number of members saved it…..because they sent it to me!

Now, I cannot duplicate the error, but my question is this - are there ways I can make it so a dump of config.php does not contain a plain english password to the main dbs?
I tried once to do the simple “include” or require, but for some reason it caused an error…and that would probably return the pw anyway.

Oh, the dump was virtually everything! All the censored words, etc. etc. etc…...I posted some of it below….
Again, my concern is not what I did to make it occur (it was just editing and looking at a doc via ftp), but rather how I can keep the db name and pw safe…the other info is not as important….
————-
dump (edited)
————-
Preferences Object ( [core_ini] => Array ( [enable_image_resizing] => y [image_resize_protocol] => gd2 [image_library_path] => /usr/local/bin/ [thumbnail_prefix] => thumb [word_separator] => underscore [use_category_name] => n [reserved_category_word] => category [auto_convert_high_ascii] => n [new_posts_clear_caches] => n [auto_assign_cat_parents] => y [site_404] => wiki/index [save_tmpl_revisions] => y [max_tmpl_revisions] => 15 [save_tmpl_files] => n [tmpl_file_basepath] => [strict_urls] => n [un_min_len] => 4 [pw_min_len] => 5 [allow_member_registration] => y [allow_member_localization] => y [req_mbr_activation] => none [new_member_notification] => n [mbr_notification_emails] => [require_terms_of_service] => y [use_membership_captcha] => y [default_member_group] => 5 [profile_trigger] => cost [member_theme] => default [enable_avatars] => y [allow_avatar_uploads] => y [avatar_url] => http://www.hearth.com/econtent/images/avatars/ [avatar_path] =>  [cookie_prefix] => [user_session_type] => c [admin_session_type] => c [allow_username_change] => y [allow_multi_logins] => y [password_lockout] => y [password_lockout_interval] => 1 [require_ip_for_login] => n [require_ip_for_posting] => n [allow_multi_emails] => n [require_secure_passwords] => n [allow_dictionary_pw] => n [name_of_dictionary_file] => [xss_clean_uploads] =>

———-and the really important part————-

app_version] => 170 [license_number] => 7837-########3 [debug] => 1 [install_lock] => 1 [db_hostname] => ##### [db_username] => ###### [db_password] => ##### [db_name] => eengine [db_type] => mysql [db_prefix] => exp [db_conntype] => 0 [system_folder] =>

Any suggestions on securing either the entire file, or most importantly the db stuff…..welcome.

FYI, I noticed some earlier threads about security where EE employees stated:

“And no, there is no request you can form with your web browser that will get ExpressionEngine to reveal information from your config file.  An intruder would need access at the file system level to see that.”

This is quite a blanket statement, considering that not only my basic config but ALL configs were revealed in this case.
Admittedly it did not happen by a planned URL attack of any sort, but it did happen…...to me and dozens of others who were posting in our forums during a short time period.

More specifically, it happened when folks were posting replies in the forum - they were presented with all that info instead of the forum screen after entry.

It sure may have to do with an add-on or extension, which is why I am not reporting this as either a bug or a bug fix request. I am simply looking for ways to secure the db pw and name better…..can they be encoded, etc in an easy way?

If this is not possible, I’d like to know that also.

Craig, PHP files will never be delivered in plain text if PHP is parsing properly.  It’s parsed server-side, before it ever hits the browser.

For any PHP file (not just config.php) to display that way, the server would have to see it as something like a .txt file.  There’s nothing in EE that would cause that.

Sounds right…..so maybe as it was open in ftp and being looked at or edited it became, for an instant, a text file…

But the question still remains…..
can I somehow encode the db parts of it so that if it ever happens again they are served up scrambled when the text is revealed?

Maybe this would have to be a mod in Javascript or something which allowed coding of those names?

Hi, handyman - EE can’t read it if it’s encrypted, but it would make a good feature request.  EE 2 does separate config.php into config vars, and database stuff into “database.php”, so that the database one would be less likely to be touched/modified.

File editor in CPanel can also re-format the file before editing/converting…leaving also some room for mistake and another place to look. But if the ‘config.php’ was changed to ‘config.txt’ it would break everything not just some features - eg. forum posting no? Perhaps check when the file was last modified?
For what is worth…

OK, so not much I do can for now.
I know others have been concerned about this in the past, so…yes….having a completely secure db connection would be a neat thing…but since I am on old EE I would not expect such a improvement to be done for legacy stuff anyway.

Leb, I think it is is OK since it stopped doing that as soon as I stopped looking at the file- so it must have had something to do with the state of that file being changed temp while viewing in text editor through ftp.

We have posts happening every couple seconds, so for certain we know when things are funny…..one of my moderators sent me the screen and said “here are your db passwords”.........requiring, of course, that I change them quickly!

I usually don’t have too much concern about secondary mysql connections where the access is very limited (only select, etc.), but the EE one allows for table creation and lots of other stuff, so security is definitely a big issue.

Hey handyman,
I think it is a fair concern, it caught my eye as well 😊
Glad to see you are ok and I can imagine the traffic on your site considering the amount of info on it.
To be honest, any server side language (php here) as Lisa said it, is secure if until it is turned into plain text/html as there is no way to access raw code (db pass etc) unless the file access is compromised.
I would not worry much just look over some of your practices for maintenance and access, passwords resets, rouge accounts….the usual drill that you probably have already done.
All the best.

Thanks for the assist, lebisol.

Craig, as Lisa mentioned, EE2 does split off the db connections into a separate config file, so there’d be less likelihood of this happening again. What did your server guru say about the glitch? Is this on the newer server?