NYCPHP Meetup

[John Zabroski]

If that is what you call input validation, then you'd be wrong.

SQL Injection is a subset of all attacks based off input vulnerability.  As an example, input validation can include calculating and effectively using string length to avoid a buffer overrun or truncation attack.  Come to that, the notion of SQL Injection is a subset of all SQL attacks.

As a general observation, input vulnerabilities are usually the most heinous when the human mind can't possibly fathom how something could go wrong.  Usually, this manifests itself in the form of a limit.  Strings have all sorts of limits, most of which are subtle.  Strings have beginnings and ends, they may have delimiters, they may have special terminating characters, etc.  Limits are where nasty bugs tend to cluster, mostly because the human mind doesn't work in such a way that when we add 1 to +32767 we think "overflow!"  Instead, we think 32768.  It doesn't matter how good of a programmer you are.  You have a Ph.D. from Carnegie Melon and still get tripped up by limits (see: http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html).

Also, validation does concern "sense of input" in many cases.  Echo the wrong thing back to an unsuspecting user and the consequences could be horrific.  Sending an e-mail out to the wrong user because you didn't validate the send-to address could be horrific, etc.

We should always say what we mean, and always question what we mean.  I can guarantee you I learned this the hard way.

David Krings <ramons at gmx.net> wrote: John Campbell wrote:
> On a similar subject:
> If your solution is to "validate input" or "input filtering", you are
> going about things all wrong.  Validating input is for the birds;
> prepared sql and output escaping is the way to go.  I don't give a
> shit if my user's use names like "" ,
> just like my web email client doesn't filter it from this post.  I
> default to escaping the html automatically when I send it to the view,
> and all queries are prepared.  It makes coding much easier, and I
> don't have to worry about forgetting to call esc() once.
> 
> When coders hear "don't trust user input" it foolishly gets translated
> to "validate the user's input" and that is one of the primary problems
> with php coders today.  I trust all user input and just escape it for
> the db and display.  I occasionally validate the input, but that is
> just to make sure the user didn't make a typo.

That is what I still would call input validation. The validation is not 
about the sense of the input, but about it being valid for processing by 
the system. At leat you and I mean the same thing. When I say "all input 
is evil" then I mean that you need to check it for being fit for queries 
and display. So yes, if a user wants to be refered to by "
href='javascript:blahblah'>" then I'd not stop them from it.

David
_______________________________________________
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


       
---------------------------------
 Check out  the hottest 2008 models today at Yahoo! Autos.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070927/cf80bcdc/attachment.html>