The topic of website security is seldom brought up among non-programmers and those who may not be technically inclined, yet if you operate a website, it is an issue of substantial concern to you.

Addressed in this article is a nearly universal problem, it affects almost every single PHP or CGI script I’ve ever seen. We won’t delve into the technical issues too far, this is intended for the web site owner, someone who might install the occasional PHP file or CGI script. I will assume you are not a software developer.

A general rule I like to follow when installing php scripts or web applications is this: If it doesn’t need to be on the web, it shouldn’t be there. This is obvious, but it has implications that are not always clear.

What we are mainly referring to is configuration and to a lesser extent, program libraries and source code. It may also apply to files and other resources that are controlled through a script interface. An example of this would be scripts that charge money for downloading files or set up newsletters. Lets start with an example, we’ll call it program.php. In our example, program.php is a database application using mysql to store information.

For our script to do it’s job, it will need access to your mysql password and user-name. It may also need access to many other program files and so-forth.

During installation, a control panel probably asked for your mysql credentials, it may even have asked you to change the file permissions on a configuration file of some sort. You’ve probably been through this type of install process at one time or another.

What it will do next, is write your database password and other private information to a configuration file. This usually happens without your knowledge, it is also where our problems begin.

Most people don’t catch this right away, if the configuration file is in the same directory (or sub-directory) it is web accessible. Quite often it is a php file, usually with write permissions turned on.

The extension .php does afford some degree of protection, under normal circumstances these files aren’t sent to a visitors browser but it is still unsafe.

If someone makes a slight mistake in the configuration or .htaccess file, it will dump the actual contents of “conf.php” to the users web browser, complete with your database password and other private information.

As anyone who has been around web servers very long can tell you, this is a common occurrence. I’ve personally seen it happen on several occasions.

Furthermore, many other web editing tools need to create backup files, resulting in something like config.php.BAK or perhaps config.php.tmp.

We now have a file ripe for hackers and other would-be intruders to gain access to your mysql database passwords as well as any other private information kept there.

What is most alarming is that almost every single off the shelf web based program exhibits this very problem in some form or another.

The topic of website security is seldom brought up among non-programmers and those who may not be technically inclined, yet if you operate a website, it is an issue of substantial concern to you.

Addressed in this article is a nearly universal problem, it affects almost every single PHP or CGI script I’ve ever seen. We won’t delve into the technical issues too far, this is intended for the web site owner, someone who might install the occasional PHP file or CGI script. I will assume you are not a software developer.

A general rule I like to follow when installing php scripts or web applications is this: If it doesn’t need to be on the web, it shouldn’t be there. This is obvious, but it has implications that are not always clear.

What we are mainly referring to is configuration and to a lesser extent, program libraries and source code. It may also apply to files and other resources that are controlled through a script interface. An example of this would be scripts that charge money for downloading files or set up newsletters. Lets start with an example, we’ll call it program.php. In our example, program.php is a database application using mysql to store information.

For our script to do it’s job, it will need access to your mysql password and user-name. It may also need access to many other program files and so-forth.

During installation, a control panel probably asked for your mysql credentials, it may even have asked you to change the file permissions on a configuration file of some sort. You’ve probably been through this type of install process at one time or another.

What it will do next, is write your database password and other private information to a configuration file. This usually happens without your knowledge, it is also where our problems begin.

Most people don’t catch this right away, if the configuration file is in the same directory (or sub-directory) it is web accessible. Quite often it is a php file, usually with write permissions turned on.

The extension .php does afford some degree of protection, under normal circumstances these files aren’t sent to a visitors browser but it is still unsafe.

If someone makes a slight mistake in the configuration or .htaccess file, it will dump the actual contents of “conf.php” to the users web browser, complete with your database password and other private information.

As anyone who has been around web servers very long can tell you, this is a common occurrence. I’ve personally seen it happen on several occasions.

Furthermore, many other web editing tools need to create backup files, resulting in something like config.php.BAK or perhaps config.php.tmp.

We now have a file ripe for hackers and other would-be intruders to gain access to your mysql database passwords as well as any other private information kept there.

What is most alarming is that almost every single off the shelf web based program exhibits this very problem in some form or another.