The really important thing about a lot of this stuff you hear is that it
is repeated over and over by people who do not necessarily understand
*why* it is a problem. Blindly following rules of thumb is always bad,
but in security it can be really bad.
The principle behind not returning $_POST (or $_GET) is /never trust
anything from the browser/. Assume that anything that came from the
browser may have nasty stuff in it. So, when sending back to the
browser escape out the HTML entities. When sending to a database
escape out quotes to prevent SQL injection. And of course *never*
execute it as code on the server because it could delete files, reveal
passwords, or anything else your process is privileged to do.
tedd wrote:
At 12:53 PM -0500 12/13/07, David Mintz wrote:
Once upon a time someone said it was a security risk to echo back
$_POST data unconditionally, even if you escape it, and even though
you are only showing them the very thing they just submitted to you.
But I forget what that risk was. Maybe I misremember.
I suppose if someone were to submit a string the length of War and
Peace, it would squander bandwidth if you sent it back without
truncating, but is that a true security risk?
--
David Mintz
Not that I experienced it, not that I'm correct, but the idea *I*
remember was that if you exceeded the length of a POST you could crash
the system and have your way with it. BUT, that was a long time ago
and things have changed.
Cheers,
tedd
--
Kenneth Downs
Secure Data Software, Inc.
www.secdat.com www.andromeda-project.org
631-689-7200 Fax: 631-689-0527
cell: 631-379-0010
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php