NYCPHP Meetup

[Dan Cech]

John Campbell wrote:
> 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 "<a href='javascript:blahblah'>" ,
> 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.

+1

Input filtering is for enforcing program/business logic, not for
'protecting' against 'bad data'.  So long as all the data you use is
appropriately escaped/encoded, the content of that data is irrelevant.

For the majority of php applications this means using prepared queries
(or proper sql escaping), html output escaping, url encoding and proper
email encoding (especially headers).

All of these are very easy to achieve, and when used in the correct
manner yield an application which is invulnerable to the attacks input
filtering is supposed to prevent.

Dan