jemjabella

PHP Security Tips

Because you can never know too much, and it’s about time I wrote a follow-up to my PHP Script Checklist article.

1. Never include sensitive data in a .inc

When I started my current job, one of the first things I did was move all of the database connection details (yes, that includes passwords) from .inc to .php files. It shocked me back then, but the more time and money I spend enhancing my PHP security knowledge, the more I realise why it’s not uncommon. Many of the most popular articles on PHP security don’t touch on it — instead favouring SQL injection, cross site scripting, etc. So, note to all: .inc files display their contents when viewed in the browser (unless configured by Apache not to do so, and this is rarely the case). That means that those passwords in the files I mentioned? Viewable to all and sundry. Not good.

2. Never trust the data in $_SERVER

There’s a popular misconception amongst PHP beginners that because the contents of the $_SERVER superglobal array are generally set by the web server, they are untouchable, trusted and secure. This is not the case. The contents of certain $_SERVER elements are manipulable like any variable, so be sure to sanitise them instead of using them blindly.

3. Never trust client-side validation

I have talked about not trusting user data before and yet people still write their scripts with little or no validation of data, instead relying on crap like the maxlength attribute and drop-down menus. Of course, to your average Joe Bloggs a drop-down menu means they can only pick the options in front of them. To a spam bot, or any sensible/knowledgeable user it’s another method of input and the drop-down part is irrelevant. Even the Firefox Web Developer toolbar can convert <select>s to <input />s (which means anything can be entered).

The other problem is reliance on JavaScript… consider the logic of checking and cleaning your data with something that the user can turn off!

4. Use mysql_real_escape_string over addslashes

Don’t take my word for it, Chris Shiflett (a leader in the PHP security industry) wrote about it: addslashes() Versus mysql_real_escape_string().

Despite the use of addslashes(), I’m able to log in successfully without knowing a valid username or password. I can simply exploit the SQL injection vulnerability.

Clean your data, check it with regular expressions etc and then prepare it with mysql_real_escape_string().

5. Read my blog

Where else can you get such a witty and intelligent outlook on life, coding, etc? Yeah, yeah, couldn’t think of a decent number five :)

2 Responses so far

1. 

   Rajah says: December 14, 2009 at 11:25 am # ·

   Thanks for this. I am just starting to use PHP to pull data from a database and security will be an issue.