Another assumption is where the URL maybe contains a page ID to display and the developer has assumed that this page ID isn't going to be tampered with. I've written in the past about Secure PHP and SQL Injections, and I've seen people secure the input where they know it could be a mix of alphanumeric characters and symbols, however I've also seen people assume that a variable should just be an integer therefore they don't secure it.

These are both common mistakes and the wrong ones to make!

Securing Integers

If you know that a value being passed to a script should only be an integer then you can easily secure this by saving the variable and using the (int) cast. This is used as follows:

$a = (int)$_GET['pageid'];

The value of $a will then only be an integer and not contain anything else. If the pageid variable is tampered with and contains any other characters then the result will either be that $a will equal 0 or $a will equal a value providing that value is the first part of the variable. Sounds confusing doesn't it. Let me explain by example:

$b = "I have 10 green bottles";
$a = (int)$b; // would make $a equal to nothing
$b = "10 green bottles";
$a = (int)$b; // would make $a equal to 10

So as you can see, the first version of $b contains text first so the (int) cast would make $a equal to zero. However the second version of $b has the integer at the start, so everything after this would be stripped out, leaving $a equal to 10.

Of course, if you rely on $a having a value then you need to check it still has one after the cast. Putting this into an if statement is then easily done. Let's say for example your site uses the pageid variable to determine which page to display. If the pageid variable is zero then we'll want the front page displaying, however we'll also want to make sure the visitor is on the front page, so we can redirect them.

if ((int)$_GET['pageid']) :
$id = (int)$_GET['pageid'];
else :
$id = 1;
endif;

This simple statement checks to see whether the integer of the pageid variable is valid. If the result of using the (int) cast is greater than zero then the $id variable will get the pageid value saved to it, else it will get the value of 1 which is assumed to be your index page. This could also be written as:

$id = (int)$_GET['pageid'];
if (!$id) :
$id = 1;
endif;

Remember, if a variable is equal to zero then as a boolean it is considered as false, it is also considered as empty (annoying when you have a required form field and someone enters a zero as the value).

So that's variable casting. It's a quick and easy way to secure any integer input.

Check for the Expected

Going back to my original example, imagine a form that has a select list. Let's say it's a simple contact form and at the bottom it has a list to allow people to select one option to say how they found the site (a waste of time in my opinion but clients still request it!). So your HTML code would look like the following:

<label for="findus">How did you find us?</label>
<select id="findus" name="findus">
<option value="Search Engine">Search Engine</option>
<option value="Another Site">Another Site</option>
<option value="From a Friend">From a Friend</option>
<option value="Other">Other</option>
</select>

In a safe and kind world we would just expect that someone would complete the form and the script that processes it would just need to accept the $_POST['findus'] value and perhaps input it into a database table or put it in an email. However, we don't use a safe and kind internet unfortunately. We live in a world where 15 year old kids want to hack sites, inject rubbish into our database tables, or spammers want to submit their rubbish via every form going, regardless of whether you need a new fake Rolex or various tablets

There are 3 ways to process this data. The naive route, assuming that the only data that the $_POST['findus'] variable will contain is one of those 4 options. I see this all the time on sites I take over from others, or people asking for help with their code and you cringe when you read their PHP. Do not assume the form posted is yours!!! Okay I've said it now. You cannot assume the form that is posted will contain the HTML that I wrote above. If your action URL is say http://www.yoursite.com/contact-us.php then any form or spam program on the web can post to that. Just because you've said that the findus variable is a select list on your form, doesn't mean that Spammer A or Hacker B is going to treat the variable with the same respect. So you need to secure everything, not just text inputs, especially if you're going to enter this information into a database table.

The second way to process this data is to run the variable through an escapeString function. This will then secure the variable before entering it into a database table (note, if you're just emailing the information then this method of securing isn't really needed).

However, the third and most suitable process is to check that what has been submitted is what has been expected. Spammers will often submit the correct form variables but they will contain completely different values than they should. If you have a select list of 4 items then why not just compare the value received with one of these values to make sure there is a match? This is easily done with an array. First off you store the values in an array:

$findusValues = array("Search Engine", "Another Site", "From a Friend", "Other");

Then in your processing script you can use the in_array() to check to see if the value of the posted variable exists in the findusValues array.

if (!in_array($_POST['findus'], $findusValues)) :
//value isn't in the array so create error message here
endif;

If the value of $_POST['findus'] contains anything other than what is in the array then the if statement will be false and your error processing should take over. Of course it would be silly to leave the HTML for the select list as above as a simple typing error could cause problems for people. Plus why repeat something when a few lines of code will take of it?

<label for="findus">How did you find us?</label>
<select id="findus" name="findus">
<?php
foreach ($findusValues AS $value) :
echo "<option value='".$value."'>".$value."\n";
endforeach;
?>
</select>

Of course this means that the array $findusValues needs to be defined in the page that contains the form. I general tend to have a form submit to itself and the processing goes on above the HTML doctype. This way if there is a problem it's easy enough to redisplay the values in the form and allow the user to correct their mistakes. So the order of the page would be

• Define Array
• Form processing script
• HTML output including form

Summary

I'll admit that I've been naive in the past. When I first learnt PHP I didn't realise such things as SQL injections existed. The book I learnt from never told me that. Then when I was introduced to the addslashes() function I was the same as most newbie PHP developers and assumed that radio buttons, checkboxes and select lists, all values that were predefined, would be fine and not need checking. As a newbie PHPer I certainly wish someone had told me these things earlier on.

Direct SQL Command Injection is a technique where an attacker creates or alters existing SQL commands to expose hidden data, or to override valuable ones, or even to execute dangerous system level commands on the database host. This is accomplished by the application taking user input and combining it with static parameters to build a SQL query.

So what does this mean? When you have a form on a page requesting user input and then use this input in MySQL queries you must not rely on what the user has entered. 99% of the time when you ask a user for their username and password, they will enter this. However along comes someone who wants to crack your system, suddenly you won't be receiving a username and password through the form but most likely code aimed to inject extra operations into your MySQL query. Perhaps it's easier to understand by way of example. My own logins usually accept a username and password from a form. The usual method is to accept a username and password and then run a SELECT statement to count the number of records that contain both the username and password. If the result is zero then the username and/or password is of course incorrect. A loosely written PHP script could be:

Insecure code to control user login

1. $sql = mysql_query("SELECT COUNT(*) FROM users WHERE username = '".$_POST['username']."' AND password = '".$_POST['password']."'");
2. $count = mysql_fetch_row($sql);
3. if ($count[0] == 0) {
4. // user/password combo incorrect
5. $errormsg = "Your Username and/or Password are incorrect. Please try again";
6. } else {
7. // user/password combo correct proceed with login
8. header("Location:http://www.domain.com/secret/logged-in.php");
9. exit;
10. }

As you can see from the above, the user input from the $_POST array is entered straight into the query. Oh and

Insecure code to control user login

1. $username = $_POST['username'];
2. $password = $_POST['password'];
3. $sql = mysql_query("SELECT COUNT(*) FROM users WHERE username = '".$username."' AND password = '".$password."'");
4. …

is no different

So how can this be an issue? Well, all of your registered users will most likely enter their username and password. No issue there. Your MySQL statement would look like this:

SQL Statement

1. SELECT COUNT(*) FROM users WHERE username = 'sarah' AND password = 'sunshine'

However, a visitor wanting to crack your system could enter the following information:

username: sarah
password: ' or '1'='1

Which would give:

SQL Injection Code

1. SELECT COUNT(*) FROM users WHERE username = 'sarah' AND password = " or '1' = '1'

The above would return the total number of records in the table. So going by the very loosely written PHP script above, the if statement of

IF Statement

1. if ($count[0] == 0) {
2. …
3. } else {
4. …
5. }

would provide a value from $count[0] to be above zero (providing there were records in the table), thus giving someone a login without a proper username or password.

Okay so yes, the example is a highly unsecure example, but it does happen. Plenty of people believe that providing there is no direct link to a file on a server, it won't be found out. Trouble is it can be. So pulling the above example apart the first steps security would be

1. Ensure all restricted pages check that the member is logged in by using cookies or sessions or both.
2. Switch the if statement to ensure that only one record is found and allow the user to log in from that, otherwise assume the username/password is wrong and prevent the login.
3. Escape the user entered data.

At this point I'll briefly mention Magic Quotes which is a setting in the php configuration file that can be set to on or off. If set to on then it will escape all user entered data, using the same method as the function addslashes(). It was introduced due to the amount of people who don't escape their user entered data, however it causes nightmares for most PHP developers and is even stated on the PHP.net site that most developers will choose to turn it off, preferring to escape the data when required. However on most shared hosting it's not necessarily easy to do this as you have no control over the php.ini file, so the best way is to check to see if Magic Quotes are on, clean the variable if they are (using stripslashes() function) and then escape the variable. The function that I use (courtesey of Khalid is:

escapeString Function

1. function escapeString($string) {
2. if (get_magic_quotes_gpc()) $string = stripslashes($string);
3. return mysql_real_escape_string($string);
4. }

Here this function uses the mysql_real_escape_string() built in function. The function will add a backslashes to the beginning of any of the characters \x00, \n, \r, \, ', " and \x1a. This will protect you from any SQL injections thus protecting your database.

However don't be fooled into thinking that when I say "user entered data" that I just mean text inputs. Going back to the site I secured last week the original developers had not thought about a couple of issues, which could be have been used in conjunction with one another and allowed someone to wreak havoc on the site or in the database. Considering the site accepted money this is even more important to ensure its security. What was wrong?

Firstly they were storing the user's id and password in cookies. Not necessarily a problem however they were then taking the raw data from the cookies and using it to query the database. Cookies can be edited therefore must be escaped. Then some user entered data was being escaped (but not as securely as the function above will do) but other data wasn't. The site had even had a security update before me and there was still an emerging pattern. When a page had some secured data on it, the unsecured data wasn't secured because the form variables were from checkboxes, radio buttons or a select list. I admit, when I first start out writing PHP I figured that this information couldn't be tampered with therefore didn't require securing. However take a normal form that's there for people to complete and the details go into a database. A questionnaire for example. Plenty of input boxes, radio buttons, check boxes and select lists. The form is submitted to perhaps the same page or another page. We know full well that another completely unrelated site could submit to that php script as well. Take the same form names, which are plain to see in the HTML source, but then instead of a radio button having a prespecified value suddenly someone could submit to the processing script a radio button with their own value.

The simple rule is, never trust data that could have been tampered with. If it's coming from $_GET, $_POST, $_COOKIE or even $_SERVER (after all if the user agent or http referrer can be altered who knows what it would be altered to?) then escape it. These are the 4 I deal with, if there are any further global arrays that should be escaped feel free to add to this list.

For people who use ASP, this Site Point article will be of use.

However the other day I received an attempt to use my web form to spam others. Below is a copy of the email I received, with the intended recipient's email blanked out. I've added an X in the middle of my domain to prevent other spambots picking it up, and XXX to the IP recorded.

From: sift4526@3emediaX.co.uk
Company: sift4526@3emediaX.co.uk
Telephone: sift4526@3emediaX.co.uk
Mobile: moonlight
Content-Type: multipart/mixed; boundary=b3b8beb3795e1c824f717fcad62d230f
MIME-Version: 1.0
Subject: the
bcc: cxxxxxxxx9@aol.com

This is a multi-part message in MIME format.

–b3b8beb3795e1c824f717fcad62d230f
Content-Type: text/plain; charset=\"us-ascii\"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

pa apers ivry mornin . ayciption at th hite ouse. mong th casulties was so
–b3b8beb3795e1c824f717fcad62d230f–

.

Fax: sift4526@3emediaX.co.uk
Location: sift4526@3emediaX.co.uk
Country: sift4526@3emediaX.co.uk
E-mail: sift4526@3emediaX.co.uk
Query: sift4526@3emediaX.co.uk

IP: XXX.174.190.170

So that's what I received. Why didn't it work? Well I control the headers of my script and set it to come from my web site and not the address entered in the from box. I originally did this because I don't believe that everyone has an email address (my Dad doesn't for a start!) and also just because I decided I wanted to control the headers more to be recognisable in my spam programs. However after a check with a very knowledgeable friend I've also learnt my script is more than secure (yay!). It sounds bizarre maybe that I'm saying this but until the above email I've never had or seen an attempt on what is commonly known as a header injection. Since the spamming happened I started to grab the IPs of the users too so the attempt has been emailed to the abuse address of the IP owner and the IP has now been blocked from my web site.

Last week I had a client email me in a panic. A form mailer that his previous developer had set up had been disabled by his host as it was being used for spamming and sure enough there was the typical, most used method of sending email using PHP:


mail("client@hisdomain.com", "Web Form Results", $msgbody, "From: $name <$email>");


I changed this to


mail("client@hisdomain.com", "Web Form Results", $msgbody, "From: client@hisdomain.com");


So how can you be careful? Well in my opinion the best way to be truly careful is to prevent anything that is associated with visitor input to go into your email headers. This way you have complete control and there are no security risks whatsoever. However that is not always how clients want it, they like to just be able to hit reply to an email and reply back to the potential customer. So therefore some extra security checks or spam traps as I like to call them, need to be in place.

Instead of writing out various methods of what to do there's a great page from Khalid that offers a few validation functions which should help you check the email given is valid.

There are other methods and checks that can be made. More will be introduced in my PHP Learning category as and when I get to the functions involved. But for now secure your scripts as much as possible!

Khalid over at Jelly and Custard has started to write a few tutorials on this subject. To save me writing them too, go read his post on Variable Casting