Login

Reconsidering PHP variables

Php helps you to quickly build big applications and many times, its easy to neglect the security matter. Its easy to believe that security breaches could not happen to your software. But what if it does happen? For this reason, security in your applications should be kept in consideration from the beginning.

I have read in the past many scary things about PHP variables. Words like: be aware, take care or look again are still in my mind. And slowly, I have realized that it would be prudent to follow some steps when using PHP variables. I have tested many secure implementations and found no performance decrease when being processed by the PHP engine.

Here is a short list of things you can do to better protect the security of your applications:

Check the number of POST, GET and COOKIE variables handled by your applications.

Check if the variable content is of appropriate type.

Using REQUEST METHOD and REFERRER.

Check the variable content length.

Check a ‘secret key‘ inside one variable.

{mospagebreak title=Counting your cookies?}

Some people will be surprised to find out that you can check the number of POST or GET or even COOKIE variables. It’s actually quite simple. So simple, it is commonly overlooked. By utilizing the count() function, you can see the number of elements in each array. If you did not send any GET variable, the array would be empty.

<?$limit = count($_GET);echo $list;?>

// the echo is 0

If you are not expecting any GET variables and you have one in $HTTP_GET_VARS array, you can trap it accordingly. For example:

You know how many variables your application is expecting in most conditions. If there are less that means that some problem may have occurred. But there is rarely a time that you would receive more than expected.

The somevar variable is a string. Please note the importance of quotes.

You can check whatever is a string or an integer using is_integer(value) function that returns true if value is an integer. For example:

If (!is_integer($somevar)){echo (” Hacking Attempt “);exit;}

It is quite common to assign small integer values to your variables in a form. In this case, it is useful to check if your variable is an integer or a string. However, please notice that all variables sent using GET method are strings unlike variables sent using POST method that can be either strings or integers.

{mospagebreak title=A Method to your madness}

Checking the method that was used to invoke your script is also a good security practice. This will help to harden your applications against unwanted breaches. If you are expecting to use POST methods for your application, then don’t allow your script to be invoked with a GET method. For example:

Another thing you can do, is to check where the script is being invoked from. The server variable $HTTP_SERVER_VARS[HTTP_REFERRER'] contains the previous web page location. This can be very helpful blocking security problems, if you know your target audience. But, that being said, there are a couple of caveats. A hacker experienced in security intrusions may be able to spoof this to make it SEEM as if they came from the proper location. Also, personal firewalls such as Norton Personal Firewall or Zone Alarm block the referrer value by default. In that case, the client browsers don’t return any value for $HTTP_SERVER_VARS[HTTP_REFERRER']. So while this is a can be a great tool to secure your scripts, it can also be virtually useless.

{mospagebreak title=Its the size that matters}

Lets come back to the variables themselves. In addition to checking the type of variable, we can also check the size or length as well. One of the largest exploited issues among all types of software are ‘buffer overflow’ problems. This is when more data is passed than the variables expect, and the data starts filling in other memory and variable locations. If you check the length and size of your data, then you can harden yourself to this kind of exploit. For example:

<a href = index.php?action=1> Page1 </a>

Use this code to check if the variable content has more than one character.

In the same way you can check text. You can allow as many characters as you wish, and reject the rest. For example:

$length = strlen($_GET['text1'] );if($length>3000){header(” You can send up to 3000 characters “);exit;}

Notice that there are 3000 characters allowed including white spaces.

{mospagebreak title=Pssst… Whats the password?}

One of the tricks I like to employ when working on a script that will be called from an outside source of some kind, is to hide a password somewhere in the posted information.

For example, lets say you have a report that you’d like to get nightly. You have your web browser configured to connect every night at 1am and grab the report for the day’s activities. But, this information is sensitive, and you don’t want just anyone being able to see the report. Since it’s an automated task, you don’t want to require a challenge/response. Or, what if you are writing an interface to a different system, and need to be able to communicate between systems without leaving the door “wide open” for anyone who could ‘accidentally’ find the URL?

In a case like this, one way to add a little bit of security is to pass a hidden password or passcode, just to ensure the authenticity of the client side of the connection.

The above example becomes even more secure when coupled with an SSL connection.

{mospagebreak title=And in Conclusion…}

Obviously, it’s not necessary to use any of the code mentioned above. Even myself do not use all these strategies in any code I am writing. But it is quite possible that using some of these strategies can keep you out of some big trouble. No, having your scripts exploited is not a certain thing, but it is a possibility you must consider. And the above examples are, by no means, difficult to implement. Please do not read this and believe it is a complete guide for securing your PHP applications, it is just a small piece of a larger puzzle.