Aaron Reynolds – The ramblings of a tek ‘ed

I'm not a PHP developer – never have been. I've had to fix problems in PHP sites before now and hence I've picked up a little knowledge of the language.

I've recently been helping my GF to rebuild something using MySQL and PHP and it makes me glad I moved on to using an IDE for server-side programming. It also makes me glad that I can use MS-SQL.

MySQL (we are talking about one of the web-based interfaces here by the way not the actual database) is pretty lousy-looking and difficult to find the features that you need. I know the database has many powerful features but the particular implementation I was using left a lot to be desired.

It's also been a few years since I used Dreamweaver to do any programming but without it I wouldn't have got far very fast in PHP. I'm sure that PHP is far more powerful than classic ASP – in fact I know it is because I've had to do some classic ASP recently. I don't miss using classic ASP though it has to be said.

When I offered to fax something to a friend recently they declined and said they didn't live in the 80s. Classic ASP, like faxes have their uses in todays world but I don't really wanna use them if I don't have to.

I would have to say that anyone moving into web-site server-side programming should look at both camps (PHP and language.NET) before deciding on their path because to be honest once you are used to using one language or system, you'll probably stick with it until it becomes obselete.

The question is when will ASP become obselete?

Although I have researched SQL-Injection attacks before, as with any securty issue its important to see if new attacks have emerged.

Since I mainly develop in .NET and T-SQL a lot of the recommended input-checking etc is the same story as usual: parse input and where possible limit the characters allowed.

For many developers these kind of things are ignored initially because of the trial and error approach that they use in developing. I develop class-based and tier-based solutions and therefore any cleansing necessary can be easily implemented without duplication of code.

As a recommendation to all working on new projects, I would recommend creating separate classes or layers for data-pulling and pushing (to and from the DB). In this way, most cleansing can be done in one place and the format of the destination fields can be used to determine the limit of characters for submission to the database.

Where possible use Stored Procedures and very importantly, handle errors so no clues are returned to those attempting unauthorised access. Secondly, log failed attempts, the contents of those attempts and their originating IPs so you can adapt any methods you have in place for dealing with them.