NYCPHP Meetup

[Kenneth Downs]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20071214/d58b17ec/attachment.html>