Hide your data!

If you run WordPress, take care on this issue:

How to access the database is stored in module wp-config.php, in your blogs root directory. This file needs to be readable by the PHP engine, based on the UIC. ACL’s are not enough, the current PHP implementation on VMS doesn’t take these in account.
Not that it would help much, since the PHP engine will run under the webserver’s account (or one closely related, depending on the server). in other words: the webserver will ba able to read the file.
So will any user, if he gains access to the file!
In itself, it doesn’t have to be a problem, but if for some reason, the used has access to the directory itself, your database is wide open.

To prevent this to happen, move database access data: the databnase name, username, password and host at least, eventually the suffix, from wp-config.php and store it in a separate file, that is then included in wp-config.php. Store the file in a location that is NOT accessable over the web.

An example: this is the original wp-config.php:

< ?php // ** MySQL settings ** // define('DB_NAME', 'WPDB'); // The name of the database define('DB_USER', 'MyBlogMgr'); // Your MySQL username define('DB_PASSWORD', 'MyDBPassword'); // ...and password define('DB_HOST', 'localhost'); // 99% chance you won't need to change this // You can have multiple installations in one database if you give each a uniqu $table_prefix = 'prfx_'; // Only numbers, letters, and underscores please! // Change this to localize WordPress. A corresponding MO file for the // chosen language must be installed to wp-includes/languages. // For example, install de.mo to wp-includes/languages and set WPLANG to 'de' // to enable German language support. define ('WPLANG', ''); /* That's all, stop editing! Happy blogging. */ define('ABSPATH', dirname(__FILE__).'/'); require_once(ABSPATH.'wp-settings.php'); ?>

This is the new one:

< ?php require_once('/closet/dbaccess.php'); // Change this to localize WordPress. A corresponding MO file for the // chosen language must be installed to wp-includes/languages. // For example, install de.mo to wp-includes/languages and set WPLANG to 'de' // to enable German language support. define ('WPLANG', ''); /* That's all, stop editing! Happy blogging. */ define('ABSPATH', dirname(__FILE__).'/'); require_once(ABSPATH.'wp-settings.php'); ?>

The included file “closet:dbaccess.php” contains the sensitive data:

< ?php // ** MySQL settings ** // define('DB_NAME', 'WPDB'); // The name of the database define('DB_USER', 'MyBlogMgr'); // Your MySQL username define('DB_PASSWORD', 'MyDBPassword'); // ...and password define('DB_HOST', 'localhost'); // 99% chance you won't need to change this // You can have multiple installations in one database if you give each a uniqu $table_prefix = 'prfx_'; // Only numbers, letters, and underscores please! ?>

Closet is a logical, referring to some location on the system that is inaccesable from the webserver (there is no mapping so the server will not be able to connect to it):

$ DEFINE/SYSTEM CLOSET SECDISK:[SECURED]

and have the directory W:E protection, and all files W:R.

Now the blog is normally accessable, and the sensitive data is hidden for the world.

13-Nov-2007

Closed a security hole
The blogs reside on the public area, and when scanning the report on unwanted accessed as derived from the webserver logs, I notices that some way, the full path has been exposed. This means any user has access to the configuration file – that contains database access information. The file needs to be accessable by the web-user (HTTP$NOBODY) – READ at least – to allow database access. There is no esy way to get around it, and certainly not in a short period.
So the only solution was to get the database access data out of that file and store it in a safe place, that cannot be accessed using the webserver directly. It’s a minor change in the PHP code: just include a file containing the sensitive data.
This has been done now -a dn the access data has changed.

This is a change to be proposed to the wordpress team.

MySQL slower – but more stable
At least, I didn’t notice any MySQL breakdown in the past weeks. It’s quite a bit slower – all buffers half as big as before – but considereing the problems encountered, the current preference is stablity above speed.
The batchjob that keeps an eye on MySQL runs every 15 minutes but hasn’t find a MySQL-Server process missing, so far.