NYCPHP Meetup

[Anthony Ferrara]

First off, I do $name = $_GET['name']. I filter when I know what's
going to happen with it (such as when it gets bound against a data
model).

Filter_input is literally the wrong tool for the job. Around 95% of
the time at least.

It's a horrific API.

It's not secure.

It's broken.

It lies to you.

Example: you're using filter_var with FILTER_SANITIZE_STRING. Do you
know what that *really* means under the hood?

It's really no better than running strip_tags. And we know that we
shouldn't be running strip_tags, right?

Instead, we need to FILTER IN, ESCAPE OUT.

Filter input, means **validating**. Not "sanitizing". And there's no
generic way to validate arbitrary data. It requires understanding of
what you're trying to do. It requires understanding of the data model.

And that's why a solution like you're proposing is bad. It conflates
filtering with escaping. And that's **always** a bad thing.

Input should be verified (that it adheres to the data domain). Output
should be encoded (or escaped) **at the point of output**,
specifically for the method of output being used. You wouldn't DB
escape when you output to a webpage, so why are you html escaping when
you output to the database?

Give this post a read:
http://blog.ircmaxell.com/2011/03/what-is-security-web-application.html

And instead of using filter_var, I'd suggest a library that doesn't
conflate filtering with escaping. Something like (I know I am biased):
https://github.com/ircmaxell/filterus

Anthony

On Wed, May 21, 2014 at 1:43 PM, Gary Mort <garyamort at gmail.com> wrote:
>
> On 05/21/2014 01:22 PM, David Krings wrote:
>
> On 5/21/2014 11:09 AM, Gary Mort wrote:
>
> $name = $_GET['name'];
> $get = function($varName) {
>    return filter_input(INPUT_GET, $varName, FILTER_SANITIZE_STRING); }
>
> These 2 lines create a function to remove any HTML tags from a query string
> variable and return it.
>
>
> First of all, thanks for the explanation. But what would one do if the
> string is supposed to contain HTML tags? Just because we want to remove HTML
> tags from some input we might not want to remove it from all input. Also,
> maybe we want to employ different types of filters?
>
>
> My target is a simple cut and paste for tutorials and teaching PHP - where
> FILTER_SANITIZE_STRING is sufficient for most use cases[ie echo "Hello
> $name" where $name comes from a query variable].
>
> Personally, I don't think tutorials should EVER use super global variables.
> They should instead have written:
> $name = filter_input(INPUT_GET, 'name', FILTER_SANITIZE_STRING);
>
> However, there are lots of books already written, and lots of people who are
> simply cut and pasting from those books and tutorials and then modifying to
> suite their need.
>
> So my goal is a simple "before you being, always use this instead of $_GET".
> I think it would probably be best to make sure the explanation is actually
> on a seperate page...ie most new programmers don't know or care how PHP
> creates the $_GET supervariable - so their just as unlikely to care about
> why I'm using closures or how filter_input works.  Instead they can simply
> use $get as a 'magic function' to make their code more secure.
>
> I resisted mightily the desire to expound on why I used FIXME  - it's a
> commonly used string tag which all programming IDE's will automatically
> provide a list of all FIXME notes in the code[PHPStorm for example defaults
> to prompting me if I try to commit code to git with TODO and FIXME notes in
> it].
>
>
> Maybe the right thing in a tutorial is to first demo $name = $_GET['name'];
> and then explain why using input_filter is a good idea and which other
> filter options there are, such as first sanitizing for email and then
> checking for a valid email address format (that is neat!). Cleaning or
> filtering input is a second step.
>
>
> Yes, I agree.  A tutorial should always go into filtering input at the same
> time it introduces retrieiving input.   What sparked my code here though was
> discovering that Zend published a long, detailed PHP101 article this
> year....and they don't bother to discuss filtering input until long after
> retrieiving input and placing it into a database.
>
> So for the lazy writer who doesn't want to go into it, they can give their
> readers 4 lines of code to make things a little better.
>
> _______________________________________________
> New York PHP User Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/show-participation