NYCPHP Meetup

[Jeff Siegel]

Well argued. The bottom line, if I've correctly understood your
arguments, is that it is not necessarily wrong to do it the way I
proposed (functionally speaking). However, it is "bad practice" in
general and a type of practice that should not be encouraged. Further,
it can introduce, for lack of a better term, "sloppy thinking" in terms
of application architecture and can create a sense of "security" (laxity
may perhaps be a better word) among developers - vis-à-vis client data -
when developers should *always* be wary of client data. And, of course,
it plays havoc with any other session data that may exist. 

Jeff Siegel

-----Original Message-----
From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org]
On Behalf Of Chris Shiflett
Sent: Friday, October 03, 2003 2:34 PM
To: NYPHP Talk
Subject: RE: [nycphp-talk] handling forms (relative newbie)


--- 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
_______________________________________________
talk mailing list
talk at lists.nyphp.org
http://lists.nyphp.org/mailman/listinfo/talk