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
<input />s (which means anything can be entered).
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 :)
Please note: this is an old post. I have been blogging for a really long time: since my childhood, in fact. Bear in mind that any opinions stated may have changed, any code snippets may no longer be considered safe or secure, and my personal circumstances are almost certainly different to what's contained herein. You have been warned...