PHP Security - General PHP setup Gotchas

My first post in a series dealing with security in PHP apps

This is my first in a series of 9 posts dealing with PHP Security, my plan is to cover some of the broad topics associated with certain aspects of developing secure PHP applications in plain English.

Whilst I will be providing examples throughout I will not labour on certain points, I will however attempt to provide many sources that you can use to read up more on the various topics.

For this post I want to talk about some general PHP setup Gotchas that you might want to look out for. There is a tendancy amongst some people (especially if they haven't had to install PHP) to assume that the default setting that their hosts provided them is the most secure. There are three things wrong with thinking like that.

  1. It is lazy (and worst of all, boring)
  2. The standard settings may not be the most secure for your setup.
  3. Who said they gave you the standard settings?

You should always check out your Apache/MySQL/PHP settings on any new server.

Register Globals

The first setting you should be looking up in php.ini is register_globals and making sure it is set to 0. This is the default setting but it is worth having a quick look because this little blighter could get you into a world of trouble (if you are a bad coder).

The reason I say if you are a bad coder is because there is nothing inherently wrong with having it turned on but if your code isn't tight enough then having register_globals on can let people type something like...

http://yoursite.com/page.php?newVar=h@xx0r

This newVar variable is now set in your code, it doesn't take a security expert to realise what crap that could land you in.

If you don't have access to the php.ini file on your server you can include that parameter in your .htaccess file that should be located in the root of your web folder. The line you would need to add is..

php_flag register_globals on

Whilst it is best practice to turn them off in order to try and keep your code a little less vulnerable you should really be turning on Error Reporting to point you in the right direction from time to time, which leads me very nicely onto my next heading...

Error Reporting

Error Reporting is concerned with what errors PHP will record, where it will store them, and if it will display them.  There are four settings we should be concerning ourselves with, like with register_globals these can be set in php.ini, in a .htaccess file or in your php code.

  • error_reporting (Which I think should be set to E_ALL | E_STRICT *)
  • display_errors (On for an internal DEV server or your home setup, Off for a client setup)
  • log_errors (You should always have this set to On)
  • error_log (You set this to where you want the logs to be stored eg /location/to/log **)

*E_ALL in it means report everything, E_STRICT means be damned strict about it, errors and warnings alike will be picked up by PHP.

** Your logs shouldn't be anywhere close to being inside the www folder, error notifications could really help a potential hacker.

You can set up your own error handling within PHP, but my suggestion would be use a framework to do this for you, only roll your own if you are confident in your abilities because if there is an error in your error handler, well...

Closing Up

You could write a small book on how to securely set up a server, and of course by the time you have written it the tips will be obsolete.  I will leave this post here with those 2 categories for now because these are the main ones that keep cropping up when people mention PHP setup and Security.

When I start writing my next post (entitled Forms and Filtering) there will be a lot more content to get your teeth into, because if you can write bullet proof code your app should be able to stand up on all but the most flaky of server setups!

Resources

If you thought this post was in any way useful, please share it amongst others who you think would also benifit.


Recent posts View all

Ruby

Forcing a Rails database column to be not null

How you can force a table column to always have something in it with Rails

Writing Marketing

We've deleted an article's worth of unhelpful words

We've improved several pages across our site by removing words that add no value, and often detract from the article.