settings.php viewable by the world

[rspx0]

I've installed Pligg using DreamHost's one-click install. I have a shared hosting account.

Right now anybody can view my settings.php file (ie example.com/settings.php). It gives a nice error message in the browser window with the entire /home path, so people can then see the DreamHost server I'm installed on and also my SFTP login. So they have everything they need to login to DreamHost, apart from my password, which they could theoretically brute-force, or exploit a security hole in the various DreamHost login methods (web panel, ftp, ssh etc).

The Pligg instructions say to change the permissions of settings.php but that's useless in my case because I'm on shared hosting and (to the best of my knowledge) ownerships/permissions don't work that way. All files are owned by my username. Making permissions restrictive to just me (not group or others) makes no difference--files still appear in the browser window.

The questions are:

1) Is there any way of changing references to settings.php in Pligg's config files so I can use a different filename? This offers security by obfuscation, which isn't ideal, but is better than right now.

2) Is there anything I can add to .htaccess? Somebody told me I can add a line turning off PHP error messages, but I don't know what it is (or even why this isn't turned off by DreamHost).

Any help appreciated. I did a forum search and one or two others have this problem, so figuring out a cure would be helpful.

[chuckroast]

You should be able to change permissions even on a shared hosting.
You can also add php_flag display_errors off to the .htaccess

[cmstheme]

I don't quite understand here but here's my two cents.

1. *.php code can't be viewed in any browser, instead it shows the output of the code if there's any, shows any errors/warnings, or it will only a blank screen. Correct me if I'm wrong with this and please let me know if there's a way that I can view a PHP code in a browser.

2. If they knew the path where it's installed, it's only the path. They will not know the login credentials except for the username. The username is known because it gets from the domain name. For example, if I have a domain that is example.com, for sure the username is "example" because it did not exceed 8 chars.

3. You can set permission to each files under your account even if it's a shared account.

4. The warning messages is by default TURNED ON.

5. What's your basis when you say "So they have everything they need to login to DreamHost.com/r.cgi?84605" target="_blank" rel="nofollow">DreamHost"?

[rspx0]

Hi -- thanks for the reply:

Originally Posted by cmstheme

1. *.php code can't be viewed in any browser, instead it shows the output of the code if there's any, shows any errors/warnings, or it will only a blank screen. Correct me if I'm wrong with this and please let me know if there's a way that I can view a PHP code in a browser.

If anybody attempts to view settings.php right now on my site (typing www.example.com/settings.php into their browser address bar), this is what they see:

Warning: include_once(mnmincludesettings_from_db.php) [function.include-once]: failed to open stream: No such file or directory in /home/.servername/username/example.com/settings.php on line 6

Warning: include_once() [function.include]: Failed opening 'mnmincludesettings_from_db.php' for inclusion (include_path='.:/usr/local/php5/lib/php:/usr/local/lib/php') in /home/.servername/username/example.com/settings.php on line 6

I've removed any personally identifying material in the path but included is the name of DreamHost's server, then my DreamHost username, and then the name of the site (because DreamHost generally install to a directory within /home named after the domain URL).

2. If they knew the path where it's installed, it's only the path. They will not know the login credentials except for the username.

Well, I might be unnecessarily concerned, but that's more than I want them to know!

The username is known because it gets from the domain name. For example, if I have a domain that is example.com, for sure the username is "example" because it did not exceed 8 chars.

I'm not entirely sure what you mean here, but I don't think what you say is the case for DreamHost shared hosting accounts.

3. You can set permission to each files under your account even if it's a shared account.

Yes, but it makes no difference. Right now the permissions of settings.php is -rw-------. It's still viewable by the world. It's owned by my username. The group is something obscure (letters+numbers) and I assume relates to how DreamHost handle shared hosting. The site works fine with this permission setting on the file, btw.

4. The warning messages is by default TURNED ON.

So how do I turn it off? I've googled various htaccess rules for turning off PHP errors and none seem to work (including what's been posted here by somebody else). I don't think what I'm seeing is a PHP error.

[rspx0]

Originally Posted by chuckroast

You should be able to change permissions even on a shared hosting.
You can also add php_flag display_errors off to the .htaccess

As mentioned--changing permissions has no effect.

settings.php currently has permissions of -rw-------, and is still viewable by the world. With these permissions the site works fine.

settings.php is owned by my username.

[rspx0]

It looks like there's no answer to this, so can I turn this thread into a feature request? Please add some way of changing the name of the settings.php file so it isn't world-visible on certain kinds of shared hosting?

[chuckroast]

I don't think anyone else is really answering this because it borders on the ridiculous. I have a DreamHost account and it doesn't use my login in the path such as yours, you must have set it up that way. You can request this as a feature request but I can tell you that it would be so far down on any list that it would probably not happen ever. If you feel that your path shows too much personal information, I would suggest contacting DreamHost and have them change it. But I wouldn't expect them to help either. Especially since DreamHost provides you with the opportunity to compile your own php allowing you to create your own php.ini file. I would not expect Pligg to change their entire CMS structure. You would have the same problem with practically every CMS or php script on the planet.

Here is how to compile your own php on DreamHost

 mkdir ~/php

mkdir -p ~/src/php
cd ~/src/php
wget http://us3.php.net/distributions/php-5.0.3.tar.bz2
tar -xjf php-5.0.3.tar.bz2
mkdir php5libs
cd php5libs
wget http://cogent.dl.sourceforge.net/sou...t-2.5.7.tar.gz
wget http://xmlsoft.org/sources/libxml2-2.6.18.tar.gz
wget http://xmlsoft.org/sources/libxslt-1.1.13.tar.gz
wget http://www.zlib.net/zlib-1.2.2.tar.gz
tar -xzf libmcrypt-2.5.7.tar.gz
tar -xzf libxml2-2.6.18.tar.gz
tar -xzf libxslt-1.1.13.tar.gz
tar -xzf zlib-1.2.2.tar.gz

cd zlib-1.2.2
nice ./configure --prefix=~/php --shared
nice make
nice make install

cd ../libxml2-2.6.18
nice ./configure --prefix=~/php --without-python
nice make
nice make install

cd ../libxslt-1.1.13
nice ./configure --prefix=~/php --with-libxml-prefix=~/php --without-python
nice make
nice make install

cd ../libmcrypt-2.5.7
nice ./configure --prefix=~/php --disable-posix-threads
nice make
nice make install

ln -s /usr/lib/libltdl.so.3 ~/php/lib/libltdl.so

cd ../../php-5.0.3
nice ./configure \
--prefix=~/php \
--enable-force-cgi-redirect \
--with-mcrypt=~/php \
--with-zlib-dir=~/php \
--with-mysql=/usr \
--with-xml \
--with-libxml-dir=~/php \
--with-openssl=/usr \
--with-xsl=~/php \
--enable-mbstring \
--enable-mbregex
nice make
nice make install

[rspx0]

I don't think anyone else is really answering this because it borders on the ridiculous. I have a DreamHost account and it doesn't use my login in the path such as yours, you must have set it up that way.

Hi Chuck -- thanks for the answer. I didn't set anything up :) This is an out-of-the-box DreamHost account. As far as I know, for shared hosting you get a /home directory that is named after your login name (ie username=frank, you'll be assigned /home/frank). So the error message in settings.php shows my login name for DreamHost that can be used across the board not just for SFTP/SSH login but also their web panel, and so on. Yup, without my password they can't get further, but it's still more information than I'm sure most would agree should be o ut there.

As you've probably figured, I'm new to hosting websites, and am learning as I go along. I was attracted to Pligg because it's offered as a one-click install solution by DreamHost, and it's also proved pretty easy to configure, despite my limited HTML knowledge (and zero PHP knowledge). By tweaking the CSS and modifying the language, I've created something pretty personal and effective. This is good, right? Or is Pligg only for people with PHP knowledge?

The thing is that I don't think I'm a unique case--lots of people are (or are going to be) attracted to Pligg because it's offered in this way, and is easy to use. I guess what I'm saying is that it would have been nice for somebody to diplomatically point out that I was asking a stupid question. Although I'm not convinced it is that stupid, at least from my point of view.

[cmstheme]

I think you're concerned is the username that was displayed in the error message.

As far as I know the username is already known to everyone - I guess this is setup that way for a shared account. For example, when you guess for the username at pligg.com, it should be "pligg" and for digg.com, it should be "digg" unless it is setup in a different way.

In Web Host Manager (WHM), when I create a new account for my client, I just used the WHM's suggestion for username. For example, when I setup a new hosting account for the domain abcdefghijk.com, it suggest to use "abcdefgh" as the username and I just use it. WHM suggestions is to use the first 8 character of the domain name as the username and I think when your web host create an account, they will also used the WHM's suggestion to avoid confusions later. Of course, your host can customize your username but I gues they're just using the default - which is suggested by WHM.

So I guess it's just fine that your username is displayed in public. Just use strong password, use secure connection when accessing cPanel/Webmail, use SFTP (this is the secure one) instead of FTP, etc.

And my experienced with a shared account is that, the staff at your host have access to your cPanel, etc. They login as "root" in WHM and then they enter your own cPanel from there, as a super user. This happened when I asked a support in my shared account. I was expecting that I will be given instructions but then the staff is already navigating to each of my folder and place there a file for the fix of the issue I raised.

Thus, this is not all about Pligg, but also or totally about the host.

[rspx0]

I'll make one last attempt at explaining this :)

1. I sign up for DreamHost's shared hosting. They ask me to enter a FTP username. I type in johnsmith1234.

2. I login to DreamHost's web panel, ftp, sftp, ssh etc using the username johnsmith1234. When I do this, I find that my space on the server -- which is in the /home directory -- is called johnsmith1234. So the path is /home/johnsmith1234. I can't change this. It's how DreamHost does things.

3. I do a one-click install of Pligg using DreamHost. This is installed to a folder named after the domain. Let's say the domain is example.com, so the whole path is now /home/johnsmith1234/example.com/, after which is the Pligg site files and directories.

4. Frankie Hacker stumbles across my website. He's clever enough to know how Pligg works, so he tries to see if any files are accessible that shoudn't be. He tries the install/ directory. Ah, that's gone. He tries settings.php. Ah! An error. Here's what he sees (assuming the site is hosted on a DreamHost server called "bob"):

Warning: include_once(mnmincludesettings_from_db.php) [function.include-once]: failed to open stream: No such file or directory in /home/.bob/johnsmith1234/example.com/settings.php on line 6

Warning: include_once() [function.include]: Failed opening 'mnmincludesettings_from_db.php' for inclusion (include_path='.:/usr/local/php5/lib/php:/usr/local/lib/php') in /home/.bob/johnsmith1234/example.com/settings.php on line 6

So do you see why I'm concerned? He's now got my login name, because it's there in the full path. Sure, he doesn't have my password, but he's only one security vulnerability away from getting access. This username is information that he shouldn't have. This is information that he's being given by Pligg.

The standard instructions to stop this are to alter permissions on the file so it's not publicly accessible but with DreamHost's shared hosting, this doesn't work -- ownerships aren't setup that away. Right now the permissions on the file are -rw------- and it's STILL viewable by the world. And the site works fine.