Charles Rowe dot com

This post could also be titled reason number 5,233,456 for why you shouldn’t develop on your production server.

The reasons why developers arent allowed on production servers:

1. To prevent circumvention of version control systems in the development environment
2. To prevent those moments of hubris that begin with words: “Oops a teeny bug, Let me fix that quickly before anyone notices”

We are interested in item #2. Basically, the more you futz around in a system, the greater the opportunity for a security vulnerability. Your production web server is not an IDE, and it is not a great idea to develop using it.

Whenever Apache encounters a file that it doesn’t have a directive for, it will serve up the contents of that file as text.
This is why servers have something similar to the below code in their httpd.conf:

<Files ~ "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</Files>


This tells Apache to never serve up files who have an extension starting with “ht”. This is so that someone trying to view your .htaccess or .htpasswd files won’t be able to gain the sensitive information within those files.
This is a great start, but the list needs to be expanded upon. What happens when someone views your php script with the wrong extension? They get to see everything. Besides being able to look at possibly proprietary code, If your database password is included within the script you could be in for some trouble. By quickly trying the various common file extensions below on all the visible files on a website, an attacker can come up with some interesting results if the users have been editing and backing up on the go.

Tip #1: Block insecure file extensions from being served up
For brevity, I am only going to list the file matching line. You can apply the rest.
<Files ~ "\.tmp$">
<Files ~ "\.temp$">
<Files ~ "\.bak$">
<Files ~ "\.sav$">

This first group are all common file extensions people use as a poor man’s backup before committing a significant change.

<Files ~ "\.*~$"> - An Emacs backup file (this option can be turned off by the user)
<Files ~ "\.*#"> - A file that was in the process of being edited when something happened (such as a disconnect)
<Files ~ "\.save$"> - A Pico/Nano save file after a disconnect.

<Files ~ "\.old$"> - This is a typical file for when people want to release a new file version but they aren’t comfortable with removing the old one.

Blocking these files will take about 2 minutes, and it is a great safety net to insure that you aren’t exposing any confidential information. This leads us into Tip #2…

Tip #2: Protect your database connections
If someone is able to view your source code through exploit, vulnerability, or sheer accident, it is a good idea to have your database information stored in an include file. By doing this, your database and username are not exposed.

The best place to put this file is outside of your web accessible path

. If your script was in the web root, you could store your PHP $username and $password variables in a file below your web root:
include('../db.php/');
By doing this, even if someone knows exactly where your server credentials are stored, they are going to have a hard time getting to them because they are inaccessible by Apache.
Lastly, don’t use the root database account for your web scripts. I know everyone knows not to do this, but I keep consistently seeing it.
I feel better just reiterating that point.