NYCPHP Meetup

[Chris Shiflett]

Cliff Hirsch wrote:
> See: http://www.phpbuilder.com/columns/weiner20050831.php3 
>  
> Beside the primary validation content, the article uses the
> following example, which I often see:
> <input type="text" name="email" value="<?=$_POST['email']?>" />

This is really a big problem within our community. I can't think of a 
more obvious XSS vulnerability, but here it is in an article that 
numerous developers will read and apply to their own development.

In the past, I have made a conscious effort to contact the author of any 
article that teaches poor practices like this, but I very rarely get a 
response. I can only think of one article that was ever corrected - Zend 
removed one of their articles at my request. I've considered blogging 
about (or otherwise making public) the problems with an article such as 
this, but I don't like to spread unfriendliness - after all, the 
friendly nature of the PHP community is what I like about it.

> First, can't $_POST['email'] create an error, since on first pass,
> the 'email' key would not exist.

Yes, and although there are many ways to deal with this, none have ever 
seemed very elegant to me. The lesser of evils is to initialize elements 
within $_POST that you reference in this way, but I don't like modifying 
anything in $_POST, ever. I often see people using error supression, 
which I really hate:

<?=@$_POST['email']?>

In fact, this was in some courseware from which I was teaching once. I 
couldn't believe it. Not only is it not a very good practice to be 
teaching, but imagine being new to PHP and trying to digest that 
statement one character at a time:

<
?
=
@
$
_

Good grief!

If I wanted to write code like that, I'd be using Perl. :-)

> Second, how do you set default values? You would be setting the
> Post array, which changes the source of the value from a form post
> to a program. Doesn't seem right to me.

Me neither. :-)

> Third, if you do want to "scrub" the input, that implies modifying
> $_POST['something'], which is in direct conflict with Chris
> Shiflett's $clean_array approach.

I think this article neither filters input nor escapes output, despite 
the fact that it's supposed to be an article about input filtering.

> Ok, so what's the harm in letting a user send him/herself a
> potential <nastystuff> script -- still seems wrong to me.

I usually give examples that use $_GET in an attempt to solicit this 
question - who cares if the user attacks himself? Well, with $_GET, 
clearly the malicious content can be embedded in a link to your 
application. With $_POST, it's not quite as easy, but it's still 
possible - a "link" to your application can really be a form submission.

So, it sounds like you have good instincts. :-)

Chris

-- 
Chris Shiflett
Brain Bulb, The PHP Consultancy
http://brainbulb.com/