In this world of bad guys and hackers and crackers, us developers have to be on our guard against all sorts of stuff that tries to break our websites. Validating input using JavaScript alone is not sufficient to gurad against the baddies as it can be worked around by building their own custom forms to interact with your site and/or disabling JavaScript.
What this means is that every piece of data you accept from a user should be validated against a set of rules for that datatype.
Some general validation rules
If it’s a text string, does it contain any less than or greater than brackets?
If it’s a date, are it’s day, monthy, year parts valid numbers?
If it’s a credit card number, is there an online number validation algorithm you can use to verify it?
Regular Expressions in PHP
In order to validate your user-input, you’ll generally find yourself resorting to regular expressions. In PHP there are two options.ereg and preg. ereg is older, less sophisticated and somewhat slower than it’s younger brother. My preference is to use the preg options even though they’re a little more complicated, the end results is betterer(sic).
An example of using preg to validate a date:
$month = $_GET['cardmonth'];
$year = $_GET['cardyear'];
if (!preg_match(”/^[0-9]{1,2}$/”, $month)) die(”Invalid month, please re-enter.”);
if (!preg_match(”/^[0-9]{4}$/”, $year)) die(”Invalid year, please re-enter.”);
An online manual is available from the main php website at http://www.php.net/manual/en/ref.pcre.php
And some lessons explicitly on how to use the preg function is available here http://www.php.net/manual/en/function.preg-match.php
No Comments // Posted on 10 October, 2006 // Software Development
I’ve worked on a bundle of web based applications over the years and time and time again I’ve seen the recurring problem of the slash. Yes, we’ve probably all seen it in one or more forums where the apostrophe some user entered, probably with the name O’Brein ends up as O\\Brein.
Why does this happen in sites running on PHP? The answer is a duplication of escapes. Yep, a Houdini Supreme.
Firstly a systems administrator has installed PHP and set the value for magic_quotes_gpc = on in the system’s php.ini (usually located in /etc/). This will automatically add slashes to all GET/POST/COOKIE data. This makes it safe before writing it to a database. Mr O’Brein becomes Mr O\\’Brein when magic_quotes_gpc is set to on.
Secondly, a programmer has come along and thinking they’re doing the right thing takes all user input and uses the addslashes() funtion to escape all quotes. This results in a doubling of the escapes so, Mr O’\\Brien now becomes MR O\\\\’Brein.
When this data is rendered, we see the automatic removal of only one set of escapes but the other set is left behind…yuck!!
When programmers see this they think…”I’ll just use the stripslashes() method, I mean, that’s what it’s there for”. As the light from the idea bulb fades, they realise they’re fixing a problem that should never have occurred in the first place. You need to go to the source of your data and clean it up, make sure you’re either using magic_quotes_gpc=on OR addslashes. My preference is to use addslashes all the time and turn magic_quotes_gpc off, this way the logic of your code explicitly sets user input to be what you want.
No Comments // Posted on // PHP, Software Development