NYCPHP Meetup

[Chris Shiflett]

--- Jeff Siegel <jsiegel1 at optonline.net> wrote:
> I'm not exactly clear *why* it matters if you just do $_SESSION =
> $_POST? (Perhaps I overlooked something in the thread?) 
> 
> Assuming that the data has been "cleaned" before you dump post into
> session, and assuming that when you pull the data out you don't
> blindly grab all the post vars but handle them by name, e.g.,
> $_POST['myname'], etc., and even if someone put some bogus additional
> post var in there you wouldn't be handling it (since you are handling
> the post vars by name), so, what's the source of the potential harm?

Well, one potentially bad thing is that your session becomes only what was in
$_POST. So, if you had other important data in there, you would overwrite it.
Of course, I doubt I'm saying anything that isn't obvious here.

The other risk is more ... vague. If your software architecture is such that a
developer can screw up and create a security vulnerability, it is a good idea
to see if it is possible to design your application such that this is not the
case. Of course, this is not always possible, and depending on how badly the
developer screws up, there may be nothing in the design that can help.

In general, naming conventions are very important. Developers need to see
$_POST and immediately be suspicious about the data. If they begin to get used
to data in $_POST being filtered, then they might mistakenly use tainted data
(thinking it was filtered).

In addition, consider something like this:

1. Validate $_POST['foo']
2. Validate $_POST['bar']
3. $_SESSION = $_POST
4. $_SESSION['blah'] is used somewhere important

So, there are two problems here. One problem is that step 3 should send red
flags to an alert developer. If this sort of assignment is allowed, you're
deteriorating this natural security-conscious instinct that you want to foster.

The second problem is, of course, that $_SESSION['blah'] is tainted data. Yes,
it is tainted because of a failure on the part of the developer, but imagine
this instead:

1. Validate $_POST['foo'] and store it in $clean['foo']
2. Validate $_POST['bar'] and store it in $clean['bar']
3. $_SESSION = $clean
4. $_SESSION['blah'] is used somewhere important

The developer makes the same mistake here by failing to filter $_POST['blah'].
However, now the only harm is that there is no $_SESSION['blah'] - better than
it being tainted! Also, depending on your error reporting (which you should set
high), you will be alerted to this error. This is much safer.

Also, your developers don't have to tolerate seeing $_POST being trusted. They
can continue to always be suspicious of client data.

Hope that helps.

Chris

=====
My Blog
     http://shiflett.org/
HTTP Developer's Handbook
     http://httphandbook.org/
RAMP Training Courses
     http://www.nyphp.org/ramp