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

Reply via email to