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 <garyam...@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 _______________________________________________ New York PHP User Group Community Talk Mailing List http://lists.nyphp.org/mailman/listinfo/talk http://www.nyphp.org/show-participation
