Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.
This is the new thread from the Thread With No Subject Line
What are the common threats and problems related to PHP web applications?
SQL Injection
Session hijacking
Bogus data in FORMs
Malformed URL's
Slipping HTML into FORM data
Invalid data types coming from FORMs
What have I missed? How we would address them in code?
Would you implement a security object that would analyse all the data being sent to a PHP script? Would this object walk GET and POST data, do fix up and put the data back in the original variables? Would you access the object instead so you can type the data that is returned.
Let's get the party started...
BTW - To keep code posts clean, if you revise your code put it back in the original post and make a mention of the edit at the bottom. This will keep us from playing with older versions of the code.
I'll write some more soon - first I need to refine some ideas I've been working on about a request model (which contains validation rules amongst other things) accessed via a RequestGateway class. Basic idea is that raw GPC should never be accessed directly. Instead, the gateway always provides safe, validated values: a single front door is easier to guard.
Architectural decisions aside, validation code will have to:
- check all of GPC
- support arrays up to 2D (in practice I think that will be sufficient)
- apply multiple validation rules to values
- define lists of required and optional keys, then check for missing or alien keys (I don't think many people do this but key checks can detect certain types of hacking attempts).
- provide error lists for logs or for the form redisplay case
- differentiate between the form redisplay case and bad request syntax
The last maybe needs some explaining.
Suppose a form submission has a missing entry for a required field. The request has a valid syntax - the user may simply have forgotten to enter a value. However, the submission is not valid to the form-processor: lacking a required value, the submission is not processable.
Another example: a form submission has an "alien" key (ie a field not contained in the original form). Extra keys cannot legitimately exist in a form submission and so this is almost certainly a hacking attempt ie "bad request syntax".
This is all very much tied to ApplicationController logic. An ApplicationController might have to decide whether to dump the user in a 400 page (bad request syntax), redisplay the form (syntax OK but unprocessable), or process the form (all OK).
You probably guessed I was going to be pattern heavy...