News:

SMF 2.1.4 has been released! Take it for a spin! Read more.

Main Menu

Securing plaintext MySQL password in Settings.php

Started by CarpeDiem, June 09, 2009, 12:43:49 PM

Previous topic - Next topic

CarpeDiem

I've just done a fresh install of SMF's v2.0 RC1.1, and I've been worried about protecting the SMF Settings.php file, since my database name and password are both there in plain text.  I've worried that someone may be able to see the include file in any browser if they activate the view-source option that is available is most all browsers I've used.

In relation to this issue, previously in a thread elsewhere, which was originally about SSL, I had been interacting with Arantor about the security of the Settings.php file, and I brought Settings.php into that thread when I asked if SSL would protect it.  Since Arantor said SSL would not help me with my Settings.php security issue, I now bring the discussion here as Arantor suggested this SMF Coding Discussion area was now more appropriate if I had more to discuss about the security of Settings.php (and indeed I do have a few more issues).

So, to catch you up with what's been discussed thus far, here's some of what Arantor said (quoted from a variety of posts in the other thread...and I've added a few My Notes here and there in italics):

  • They can't view the source of Settings.php from the browser. The only time this can happen is if the server is misconfigured and stops processing PHP before sending it.
  • Your thought of moving it to another place then including it from forum/Settings.php is a good one - and is basically the method I am hinting at. Most hosts do not allow users to have PHP outside the webroot folder.
  • If inside the webroot, the raw PHP code can only been seen if the server is misconfigured. If outside the webroot, the only way it can be seen is if the server is compromised somehow (My Note:  This is similar to the first comment above, but brings up another point about webroot, so I'm repeating the comment here).
  • Leaving Settings.php inside webroot poses 1 security risk, and only 1 direct risk. Should the server be misconfigured or exploited, it may stop serving PHP code as PHP code and simply serve the raw code. In this case, the unexecuted contents of Settings.php would be spat out to a user.  That sounds like it might be a big issue, but in reality it may not be. Many database servers (the one on my VPS included) are configured to listen only to localhost. Meaning that the originating connection has to be on localhost; so they have the password for the database. It's only then an issue if that's the same login details to actually log into the machine and add a file that enables them to access the database directly.  cPanel type hosting sometimes does this, unfortunately.  (My Note:  Oops, I have a cPanel!)

Now some of Arantor's comments above may sound repetitive, but they are actually from a multiple of posts, and I've not edited the collective here (except to add a few My Notes).

Some of what I need more help understanding or for which I could use any feedback on how to do better falls into the following areas:

  • SETTINGS CAN'T BE SEEN UNLESS PHP STOPS:  This sounds excellent and my testing seems to verify this about included php files, but I read by searching Google that others say in practice that the PHP engines do stop periodically (how frequently, I really don't know -- I only know that's what some of them claim to know).  If it doesn't happen, things are well; but if it does stop unexpectedly and the file displays as some say, then this may indeed be bad depending on what file was being processed at the time, though I don't think the include shows (however, some say the include files do show according to some comments I found in a Google search, though my own tests agree with Arantor, that they do not display).  It'd sure be nice to feel more certain about this!  Would the include file show if it was being processed at the moment the PHP engine failed?  Has anyone observed in browser "show source" windows that the contents of an include file shows when integrated into the file which called it (or is that not how it works)?
  • THE cPANEL VULNERABILITY:  I'm a little unclear how this works in terms of what Arantor said above, but since I definitely have a cPanel, I'm concerned about the vulnerability this may incur.  However, I'd also like a little more detail about the cPanel vulnerability issue, like how or why it happens (if known), and whether it affects other components or files outside the Settings.php file issue.
  • DIRECT CALL TO SETTINGS.PHP:  Anyone who uses SMF knows the likely path structure for a possible direct call to a Settings.php file (in other words, such as MyWebsite.com/SMF/Settings.php entered on the URL line of a browser).  In Firefox, I get nothing but a blank screen when I try to view the source on a direct access to Settings.php, however, if I use the wrong name "settings.php" instead of "Settings.php" (using a lower case "s" instead of a capital "S"), I get a 404 error; so it is possible to know when the right name and path matches the file, since no error is reported with a blank screen showing up when the capital "S" is used matching the file that is actually there.  Now I don't know if all browsers will show a blank source window when the name correctly matches the Settings.php file since I don't have all browsers, but a blank screen verifies that the filename and path of the file are indeed correct, which is exploitable information that could be used by someone trying to break into a system.  Personally, I'd prefer no information to result from such a test (like constant 404 errors).  Does anyone have a different experience (perhaps using a unique browser) with direct calls to files which are usually include files or know how to see the contents of such files with a direct call (and if yes, any ideas on how to prevent this)?
  • MOVING THE SETTINGS.PHP FILE SOMEWHERE ELSE:  Arantor agrees that moving the Settings.php file may be a good idea if it is possible with the webhost.  A search on Google comes up with some who say moving it is an excellent idea, especially if the PHP engine fails, as the line with the include code line will not show even in a view-source display since the processing engine is inoperable (keep in mind that this include code line shows the path to the Settings.php file), but the rest of the index.php file that has no include lines may indeed show (while it's unlikely for the PHP engine to fail, if it does, it may reveal some potentially critical information -- not necessarily in how SMF has structured things, but in how some developers may have done their work).  It helps to think the path to the Settings.php file will not show in a PHP engine failure.  So (and all these are long-shots), hiding the file somewhere else (webhost permitting) may have merit in the unlikely event of a PHP engine failure (or cPanel vulnerability, as in my case).  Worth it, maybe, maybe not -- it won't hurt if it works, and if someone comes along looking for something to exploit, perhaps it might be just enough extra trouble to make them move on to easier targets.  Has anyone had success moving included php files to unique places and have them still work?
  • WEBROOT?:  I understood (in the past) php files only work in a webroot (I think I remember seeing that statement before), so it's important to know where the php files are in relation to the webroot.  Webroot, hmm, I thought I understood, then I don't.  I thought originally webroot was the same as the root folder of my website, but since all my SMF php primary files are not in my website's root folder but in a subfolder, obviously I'm wrong about the website root being the webroot for SMF.  So maybe a webroot is relative to the index.php file that is currently active (that's a question, not a statement) which is why the index.php for SMF works in a subfolder inside my website's root (though the website's root is relative to the public_html folder, and so forth...ah gee, I am certainly confused).  Then there are all those other php files in the subfolders of the SMF folder -- so, I'm beginning to babble on what the world the webroot is, unless it's indeed a relative indicator instead of absolute.  I would love a clarification here, so can anyone clarify this for me (and I did do a Google search, and was taken all over the land, mostly about home-based servers with statements like "Be sure to use the webroot", but I was not taken to a clear landing place about the question I pose here about where is the webroot on a webhost system which is not home-based -- is it relative or absolute, or what)?
  • SUBDOMAINS:  I bet I've got lots of extra nooks and crannies in which I can put important security files (like Settings.php, etc.) since I have quite a multiple of subdomains to my primary domain account (gee, at only $10 a year for each subdomain, with unlimited bandwidth and storage space too, it was just too fun and I couldn't resist setting up quite a variety).  Let me digress a moment, for those not familiar with subdomains, from the point-of-view of my public_html folder, which is my primary domain, all subdomains are simply subfolders inside my primary domain (the primary domain is parent, and the subdomains are children).  However, I can call any one of my subdomains directly in a browser's URL line without referring to my primary domain, such as MySubDomain.com and it will immediately implement the index.php file in it as though it is a fully independent domain (or primary domain), though, technically, MySubDomain.com is actually just a subfolder within my primary domain in terms of the paths I see with my ftp program.  Every subdomain, like my primary domain, has unlimited and independent subfolder potential and active runnable php files can be placed in all of them.  So, to return to the hiding places idea, I wonder if these subdomains could be unique storage areas for important security files belonging to other subdomains (for example, as a special case, if I were to use a subdomain I'm not actively using and it appears to the outside world to not exist at all as an active website, though it is still actually a viable subfolder in my web structure's directory tree, it might be a very useful and unique hiding place -- like who would guess it has something important buried in a weirdly-named subfolder, since it doesn't appear to exist as a website).  I've yet to test out if my particular webhost will allow all this to work, but, again, since all my subdomains are but ordinary everyday subfolders to my primary folder and the paths are fairly easy to construct logically, maybe it'll work as a structured maze in which I can hide things that are needing some additional security or misdirection (just to help confuse or foil those exploiters who sometimes do really exist!).  I thought I'd share these concepts in case it works for someone else on a different hosting system (though I hope it works for me too).  Again, this is a nook-and-cranny maze kind-of-crazy idea, and I know, it might not even be needed (but it was fun to think about!).  Does anyone have experience with hiding files this way?

Wow!  Too wordy, I know!  Well, I would have painted a picture instead if I could (but I don't paint)!  Besides, who would have been able to decipher such a picture?

Norv

Quote
I read by searching Google that others say in practice that the PHP engines do stop periodically (how frequently, I really don't know -- I only know that's what some of them claim to know).  If it doesn't happen, things are well; but if it does stop unexpectedly and the file displays as some say, then this may indeed be bad depending on what file was being processed at the time, though I don't think the include shows (however, some say the include files do show according to some comments I found in a Google search, though my own tests agree with Arantor, that they do not display).
If the php engine is stopped, then there is nothing to process the include statement, to interpret it as that thing who requires to search in a certain path for a certain name of file. So the content of the included file won't show.
Then again, you seem to hint to the extremely particular case, down to the millisecond, that: php engine starts processing a request, interprets the include, then it stops. And you ask, whatever it was in its variables (processed content of the page perhaps) would be suddenly thrown to the user... That would be practically impossible.

Quote
Now I don't know if all browsers will show a blank source window when the name correctly matches the Settings.php file since I don't have all browsers, but a blank screen verifies that the filename and path of the file are indeed correct, which is exploitable information that could be used by someone trying to break into a system.  Personally, I'd prefer no information to result from such a test (like constant 404 errors).
I think you can do this, by instructing the web server to treat particular URLs as if not found.
To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github

Norv

The PHP engine could crash. But the likelihood that happens, and at the very moment after it interpreted a particular include, and from all the behaviors it could have it also feels the sudden urge to first answer a valid text before dying, and is able to do so, and that text is the exact variable that has the full content of the page, and I don't even know if they do it so simplistic, is ... I can't begin to calculate the odds. Not sure what I'm missing here either, but it may very well be.

Quote
Note that if they see the copyright string, realise that it is SMF, they're going to know that Settings.php is present. Telling the server to report a 404 isn't really strong, it's mostly security through obscurity.
Ah by the way. If one really wants, I guess you can very well change the name "Settings.php" on your particular SMF installation and fix the includes to point to the other one. Custom name, that looks like all the other php files who deal with less sensitive data. (Please correct me if wrong.). So that it would be at least much more time consuming for one seeing that your host is serving raw php text, to find your database credentials.

But even so, the other point, about database access with those credentials being restricted to the local computer or internal network of the host, remains anyway a very hard problem a malicious user would have to face.
To-do lists are for deferral. The more things you write down the later they're done... until you have 100s of lists of things you don't do.

File a security report | Developers' Blog | Bug Tracker


Also known as Norv on D* | Norv N. on G+ | Norv on Github

CarpeDiem

I'm really pleased that many of my worries seem obsessing over unlikely events, and that gives me great comfort.

A few quick things:

  • DIRECT CALLS:  About the direct call to the Setting.php file.  I know it won't show anything when simply called in a browser directly, as there are no echo or print lines in it, but I was concerned that the show-source function of that blank-looking page might be used in some browsers to reveal the contents of the php anyway.  I would think it would be just logical that the source code would display when show-source is activated, but I have to say that in my experience with the browsers to which I have access that no source code shows yet (why not? -- it's source code...though I haven't found a display yet of a direct call to Setting.php and I'm glad!).
  • INDEX.HTML:  I note that when I view the source code after a call to SMF's index.php, I see an html file instead (and not a php file in terms of contents like I called) -- there is not one <? php call in the html (and I did a search for "<?" but no matches were found).  I take this to mean the displayed code is converted output and definitely not the original php code, and that's good news in terms of my initial worries.  Note:  One browser says it is displaying the source code of index.php and another says it is displaying the source code of index.html, but neither browser shows php code lines.
  • WEBROOT:  So, if I understand, if something is within webroot (such as a subfolder is to the root), it will work the same as if it is IN the root prime itself.  I started working with computers when nobody had hard disks (they were way too expensive, and besides, they held a huge 5MB of space and we couldn't figure out how anybody would ever need that much space), but we all had one 5-1/4" single-sided floppy disk drive (Drive A:), and there was only one root on each disk and nothing above it (unlike the discussion of webroot, since with webroot, there is something above webroot, and that's the parent to public_html, the host, etc.).  Dropping the floppy analogy now, php files will work in the webroot and all subfolders which are children to it (but php files won't necessarily work if placed above or as a sibling to the webroot if I understand correctly).  I also agree that subdomains have a separate webroot logically, although they appear as a child folder of the primary domain's webroot.  I figured all along that the webroot discussion had to be relative and not absolute, since it was driving me nuts when I tried to understand what as being said as though it was an absolute set of relationships.  When I look at this discussion as relative, I go "Yup!"  Whew!  I hope some parts of this paragraph are coherent to others.
  • 404 ERRORS:  In relation to my comment about 404 errors being given for certain files that actually exist, Norv said "I think you can do this, by instructing the web server to treat particular URLs as if not found."  I like this and will look through my cPanel to see if it gives me this flexibility, since I've learned here that the purpose of the cPanel is both to keep me away from server settings and make things more convenient (ah, a classic double-edged sword in my experience).  Convenience often results in giving something up, but I'm going to look at all the stuff cPanel has, since there are some protection options in which I have not snooped yet.  And, Arantor, I do see my .htaccess file, but have never dealt with it before.  I think moving the Settings.php file is still the best option, but I like the 404 errors too.
  • SHARED HOST:  Last thought about "if you have a shared host", since I have a dedicated IP and SSL, I hope I'm outside the shared host concept.

Thanks for all this feedback.  I like to be told I'm worrying over nothing!  Keep it up!

CarpeDiem

My, my!  3:20am.  You are SO dedicated!  I hope you don't have to go to a traditional 8-to-5 job tomorrow!

Thanks for all the information in your last post.

WEBROOT (continued):  When you said "This will work provided PHP has been configured to be allowed outside the webroot for files. Normally this is on VPS and up systems with a sysadmin who knows what they're doing."  Since I have a webhost and cPanel, I assume I cannot configure this PHP setting.

.HTACCESS:  Downloading the .htaccess file was easy and I could open it in the editor I use for programming.  Other than a commented header line, it says "AddHandler application/x-httpd-php5 .php" and nothing more.

SHARED HOST (continued):  Interesting.  I thought since I have a dedicated IP, I'd be clearly outside a shared anything.  Alas!

CarpeDiem

Day job -- ugh!

WEBROOT (continued):  Yeah, the cPanel has an icon called PHP Config, but it has little to configure.  However, since we've been having this conversation, I do notice that the first of three options says "PHP5: All files with the extension .php will be handled by the PHP5 engine" and the second option says "Same as PHP5, but all subdirectories will use ~/public_html/php.ini" (and a third is about FastCGI).  I currently, by default, have the first-option's radio button selected.  Does the first option give me the flexibility of stepping out of the public_html folder to tuck something like Settings.php in a folder outside public_html like we've been talking about?  I hadn't thought previously about what these options might mean until we started interacting about php files and webroot recently.  (Note:  The last section of my PHP Config in my cPanel adds code to the php.ini for the use of either IonCube or SourceGuardian, which are encryption schemes that cost considerable money, and I wouldn't doubt that my host gets a return for providing a simple way to insert their code and advertise their products on the cPanel.)

.HTACCESS (continued):  Oops!  I didn't mean that I downloaded the .htacess from my web browser.  I downloaded it with Filezilla, which is what I usually use to upload my website's php's that I write.  The cPanel does have a file manager, but it doesn't quite have the facility or provide the same wealth of information that Filezilla does.

Advertisement: