Okay, so before I start this next chapter, I have something very important to say.  There are a large amount of people out there who believe that PHP is a terrible language.  Their claims are based on the fact that 90% of applications built with PHP are of poor quality, don’t perform well, or are extremely vulnerable to attack.  This is, in no way, a fault of the language.  In-fact, it’s the crappy developers that are to blame.  While .NET languages do everything for you (drag a button, double click, change text), PHP developers have to do everything from scratch (write HTML code for button, intercept GET/POST data, display response).  This leaves a HUGE amount of room for error, poor design, and, of course, stupid mistakes.

Anyway, PHP is an awesome language, you just have to suck less when writing in it.  Now back to the chapter (Security and you!).

Users cannot be trusted!

This is the most important concept of Web Development – never trust the user!  Every input going into your PHP script cannot be trusted, all input to PHP can be intercepted and rewritten.  Files, form data, cookies, external RSS feeds, everything can be/is tainted.  The only thing that is safe is your session data ($_SESSION) as it is stored on the server, not the client.  The first step to accepting input is to filter it.  And there are two mindsets for filtering data: whitelisting and blacklisting.

The basic example is a forum post being submitted from a user.  To protect against users posting profanity, you can replace specific curse words from the incoming post  with ***s.  These specific curse words are listed beforehand and the act of removing these would be considered following a blacklist approach.  If you were to instead create a list of allowable words and filter the incoming post based on that knowledge, that would be following a whitelist approach.  These methods are situational, as even in this case, it’s obvious that a whitelist approach would be a terrible idea.

These methods don’t always apply to a list of words, it can also apply to things like letters/numbers.  A good example of this is a pin number, it should only contain numbers, a simple check for this could prevent a variety of dangerous attacks.

Escape displayed input

This follows along with the "don’t trust input" notion.  If you are displaying input sent by the user, it’s incredibly important to escape it first.  This means to properly display characters instead of allowing any code to be displayed.  This includes replacing any special characters "htmlspecialchars()" or html tags "htmlentities()."  Also, when submitting input to a database server you should escape it.  It’s easy with the *_escape_string() function (where * is any database driver; e.g. mysql).  Doing this will prevent quotation marks from screwing up various queries (more about SQL Injection tomorrow).

Finally, never… ever… EVER.. enable register_globals.  It is a terrible relic from before PHP 4 that should be banned (actually in PHP 6 it won’t exist anymore, yah!).  By default it is off, and leave it that way.  Basically it converts input variables (GET, POST, COOKIE) into actual variables.  For example: index.php?user_id=5 will set $user_id = 5.  Terrible, terrible, terrible.

Okay, so tomorrow I’ll get more into various ways to exploit your PHP code and how to protect against it.