Quote:
This isn't really true... It's a php file, and doesn't display it's contents unless there is a server misconfiguration (such as PHP not working properly). And especially since XOOPS 2.0.7, where mainfile.php was changed, is there a check that will determine if the files requesting mainfile.php comes from the same site as the mainfile.php belongs to.

Plus, if the user knows the location of the securedata/filename.php file, the same security risks apply, and the 2.0.7 patch to mainfile.php is rendered useless.

But, all in all, a good tip, and it can never hurt to secure your data, but don't make it look as if XOOPS is insecure when it really isn't (under normal circumstances, of course). By the way, XOOPS 2.2 will probably have better vulnerable-data management.

Herko

Quote:

Just to clarify it - as Herko mentioned, Xoops is by far one of the securest systems around, if not the securest. The issue we have here is that should the php stop working, the combination would be world readable, thus posing security risks.

Quote:
securedata/filename.php is outside the web tree, people cannot access it directly.

Quote:
it supposes that you have a full access to the web server.

Most of ISPs will provide you the access

Your directory mostly will be like

Top Level -> your account

Second Level
-> www.yoursite.com (your web tree)
-> (you can create a directory parallel to your web tree)

Two alternative ways of doing it (suggested by Dave_L)

1. Replace the contents of mainfile.php with:


The path specified above is your "real" mainfile.php. [copy the working real mainfile.php to the protected directory, then create a new mainfile.php file suggested by Dave. Be careful with whitespace. tl]


2. You could leave mainfile.php alone, and add an .htaccess file to the main Xoops directory:


[First alternative is preferrable, as it is not under the webtree. tl]

Taking this a step further...

Create a file with a very cryptic alphanumeric string as the name (example: 7NVaIDjbfj.php) and insert the following into it (change the values in " " of course):



Now in mainfile.php, change the following values as indicated:



If you radomly generate the secured filename instead of using the suggested "xoops-auth.php" filename, there is even less chance that a hacker would find out your db details. This is also good if your db server is not localhost, which is the case on some large hosting providers.

Hope this is useful for someone.

James

Thank you, James. IMHO, xoops-auth.php is just as effective as 7NVaIDjbfj.php. If the hackers got hold of the file name, then they could try to hack file, no matter what it is called.

If you have not read the chmod tutorial, please don't forget to change file/directory permissions to the following:

Files:
chmod 604 xoops-auth.php
chmod 404 mainfile.php

Directory:
chmod 701 securedata

The permission changes effective prevent other users sharing the the same server from "peeking/stealing" your database settings.

Quote:

What I was meaning by that is that a script kiddie might use a regular expression to search a drive for any file with "auth" in the name, thereby exposing xoops-auth.php. By using a cryptic, random alpha-numeric string that only you are aware of, it wouldn't even show up on most hacker's radars uless they were targeting you specifically. Then they might take the extra time to hunt down your configs.

As a general rule, yes, xoops-auth.php would be just fine. I've grown to be a bit p@r@n01d since MyWebResource got hacked.

BTW... GREAT TIP! Real good for p@r@n01d people like myself.

Best Regards,

James

Thanks James. Hopefully one day MySQL/PHP could come up with a clever way of password encryption so this tip would be obsolete.

The database-info has to be in clear text, you can usally do as the article says, but Herko has as right as he can get; if php for some reason stops working you will still have the problem you wanted to get rid of from the beginning, because the includepath and the included file will also be in clear text.

BUT - if you do som magic, you can prevent that to ;)
Databaseinfo has to be in clear text..but not the includepath.

So if you cryptating the includepath in mainfile.php and place the included file a random place, i.e. in one of your modulesfolders and call it language.php or something, it's a bit more secure.

All a cracker will see of the includepath in mainfile.php will be useless for him or her since its crypted.

Best Regards,
Bananadude

The included files are OUTSIDE the webtree and nobody should be able to access those files no matter what names you call them. IF the crackers could potentially access those files then the encrypted path is useless as well. You then have a much bigger security problem to your website.

As of any system not just Xoops, people should never ever leave their database settings under the webtree.

[edit]Xoops is a secure system, but people should not rely on the default settings alone. False security sense tends to come back bite you.[/edit]

are there incompatibility with module Protector ?

thanks

None as we are aware of.

Indeed, I am using Protector. Even with Protector, the database info are still in mainfile.php. I am on a VPS network and my PHP went out not to long ago and mainfile.php was completely visible. Very worrisomeThis is a great tip. I feel a lot better about having it out of the web tree. Still p@r@n01d though.

Paranoia is the best defense when it comes to web security. There can never be enough security measures. Be sure to have a daily checking routine: protector logs, website raw logs.

Even you have done everything possible, DO NOT forget your ultimate security: don't forget to back up your database and download the back-up to your local computer . If contents change daily then a daily backup routine is required. God forbids, if anything goes wrong, then you can always get your site back up running quickly using the backup.

Completely agree with you about paranoia and security... also up-to-the-minute application of patches, 24/7 attention to netstat, processes and strange traffic. etc etc etc...

Anyway, the method I use to keep co-users/script kiddies from being able to see mysql passwords is to put them into the apache virtualhosts' environment. Of course, only root can do this.

In a root r/w only httpd.conf (or an included vhost file):
<VirtualHost *:80>
...stuff...
SetEnv SQL_HOST localhost
SetEnv SQL_USER andy
SetEnv SQL_PASS asecurepassword
SetEnv SQL_DB a_database_name
SetEnv FTP_USER andy
SetEnv FTP_PASS asecurepassword
</VirtualHost>

PHP database connect thus becomes:
$conn = mysql_connect( $_SERVER['SQL_HOST'], $_SERVER['SQL_USER'], $_SERVER['SQL_PASS']) or die(mysql_error());
mysql_select_db($_SERVER['SQL_DB']);

Advantages:
+ only root can read/write passwords.
+ owner of the site/php files can reference passwords.
+ passwords don't exist anywhere in the users site in text form
+ code portable between dev and production sites without modification

Disadvantages
+ only root can read/write passwords.
+ a PHPINFO() will expose the password

All in all it is a hell of a lot better than leaving plain text in the code!

Hope this tip helps.
Andy Haveland-Robinson

Hello ---

Thanks for the site. I'm new to Xoops. I have correctly installed Xoops 2.0.17.1 on a current WAMP stack - Apache 2.2.6, PHP 5.24 and MySQL 5.0.45, on an old Win2K box.

However, I'm probably committing some very basic error[s] while trying to implement this tip. I've followed the instructions but I am receiving this message when I try to load my http://localhost/xoops/index.php page:

"This page cannot be displayed due to an internal error.

You can provide the following information to the administrators of this site to help them solve the problem:

Error: Unable to connect to database"

Here are the relevant [munged] excerpts from my revised mainfile.php file:

"<?php
// [... comments ...] //

// Physical path to my securedata folder and xoops-auth.php file]
include ("C:/Program Files/apache.org/web-server-2.2/htdocs/xoops/securedata/xoops-auth.php");

if ( !defined("XOOPS_MAINFILE_INCLUDED") ) {
define("XOOPS_MAINFILE_INCLUDED",1);

// XOOPS Physical Path
// [...]
define('XOOPS_ROOT_PATH', 'C:/Program Files/apache.org/web-server-2.2/htdocs/xoops');

// XOOPS Virtual Path (URL)
// [...]
define('XOOPS_URL', 'http://localhost/xoops');

define('XOOPS_CHECK_PATH', 1);

[... several unchanged settings and comments ...]

// Choose the database to be used
define('XOOPS_DB_TYPE', 'mysql');

// Table Prefix
// [...]
define('XOOPS_DB_PREFIX', '[munge]');

// Database Hostname
// [...]
define('XOOPS_DB_HOST', 'localhost');

// Database Username
// [...]
define('XOOPS_DB_USER', $db_user);

// Database Password
// [...]
define('XOOPS_DB_PASS', $db_passwd);

// Database Name
// [...]
define('XOOPS_DB_NAME', $db_name);

..."

Likewise, here is my newly-created xoops-auth.php file [in my local C:\Program Files\apache.org\web-server-2.2\htdocs\xoops\securedata\ folder]:

"<?php
$db_user = "db [munge]"; //database username here
$db_passwd = "db [munge]"; //database password here
$db_name = "db [munge]"; //your database name here
?>"

Obviously, I'm running a localhost installation for now. I'd like to add the official CommercePack module. Also want to use the zencartxoops-0.3-1.3.zip module (see https://sourceforge.net/projects/zencartxoops/).

However, the main idea is to create a functional, reasonably secure bare-bones ecommerce installation on my machine, then copy it over to my site, modify the paths etc, and go live.

What am I doing wrong? Is it just some newbie syntax error?

Thanks in advance,

Sean

Not sure about your problem is, you may want to answer the following three questions:

1 Did you get Xoops working without modification/moving-out?

2. If Yes, is xoops-auth.php executable?

3. if problem persists, double-check xoops-auth.php and make sure no space or typo's.