If you write a script in PHP, it's one thing handing benign user inputs, and quite another "bullet proofing" your script against awkward characters (of the "less than" and "double quote" type) entered into form fields where they can lead to problems of the SQL error, echo display corruption and injection attack style.

I use the following diagram on PHP courses to remind trainees of the need to clean us EVERY user entry variable and to process EVERY string that's send out to a database or as part of the HTML response:



Remember that PHP was designed to handle web page work, so this string cleansing can be done with built in functions - there's a function to do that as we say during courses!

Just be aware ... that there are other issues as well as the ones shown in our diagram. If you're looking to write cast iron (squaddie proof) PHP, you'll need to use regular expressions to check that the inputs made of are of the format your program expects, you'll have to ensure that register globals is off or that every variable is initialised, and you'll need to check that users don't enter file names starting with "/" or "../".
(written 2006-02-03 06:16:16)

Commentator	says ...
john moylan:	Hello Graham. Just a quick note regarding your diagram. I thought that the preferred method of escaping prior to insertion into a database is to use database native functions. e.g. mysql_real_escape_string or pg_escape_string (comment added 2006-02-04 01:53:15)
Graham Ellis:	Yes, I would "go with" those alternatives sometimes, John. I always worry about using database native functions in case someone wants to change the underlying database though. My own, somewhat longwinded in a short post, pedant preference is to write my own wrapper function, keep it in a required file of helpers, and use it excluselively. This allows for future changes, sitewide, with just a single source edit. (comment added 2006-02-04 05:12:27)
john moylan:	Hello Graham. >> I always worry about using database native functions in case someone wants to change the underlying database though. Something you've taught me is to have a love of CPAN, this in turn has created a similar affection for PEAR. The PEAR DB module is great for this (think Perl's DBI) and its 'quotesmart' method does just this regardless of which db you use. (or change too) The strange thing now is when I read PHP books that have database code the code feels a little foreign as I never use the native mysql funtions anymore, in fact I never used them in anger at all in any production code. It's been one of the most timesaving modules I've found as I can code in PEAR DB pretty much as I did in CPAN DBI Also have a look at HTML_Quickform, I build all my forms with this now. (comment added 2006-02-05 11:43:23)

H107 - String Handling in PHP
H110 - PHP - HTML Web Page Data Handling

Back to Changing @INC - where Perl loads its modules

Previous and next or Horse's mouth home

Forward to Danny and Donna are getting married

Finding where the disc space has gone
NOT Gone phishing
Key facts - SQL and MySQL
Danny and Donna are getting married
Robust PHP user inputs
Changing @INC - where Perl loads its modules
Job vacancy - double agent wanted
Perl Regular Expressions - finding the position and length of the match
Looking for Python staff
Loosing breath with Gerald
Link to page ... 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33 at 50 posts per page


This is a page archived from The Horse's Mouth at http://www.wellho.net/horse/ - the diary and writings of Graham Ellis. Every attempt was made to provide current information at the time the page was written, but things do move forward in our business - new software releases, price changes, new techniques. Please check back via our main site for current courses, prices, versions, etc - any mention of a price in "The Horse's Mouth" cannot be taken as an offer to supply at that price.

Link to Ezine home page (for reading).
Link to Blogging home page (to add comments).