NYCPHP Meetup

[Michael Sims]

On Thursday 01 September 2005 12:44, Cliff Hirsch wrote:

> 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 a cross-site scripting hole.

> Third, if you do want to "scrub" the input, that implies modifying
> $_POST['something'], which is in direct conflict with Chris Shiftlett's
> $clean_array approach. Ok, so what's the harm in letting a user send
> him/herself a potential <nastystuff> script -- still seems wrong to me.

Ah, but suppose the user didn't do it to himself.

Suppose I make a javascript function on my site.  The javascript on my site 
tells the web browser visiting my site to submit a form to YOUR site, with 
some POST variables.  Maybe the "email" variable in the POST request is set 
to, say:

"><script>alert('I just stole your cookies!')</script>

Now when the person browsing MY site executes that Javascript on MY site, 
his browser visits your site, submits a form, and the resulting page (which 
has access to the user's cookies) looks like:

<input type="text" name="email" value=""><script>alert('I just stole your 
cookies!')</script>" />

So the generated page, rendering on the user's machine and with access to 
the user's cookies for YOUR website, can now contain and execute ANY 
Javascript that *I* want to execute, which can easily send me your user's 
cookies (which may allow me to impersonate your user).

And again, all the user has to do is visit MY website with Javascript 
enabled in order for their cookies for your website to be stolen.

It is a conceptual error that content seen only by the user can't be a 
security hole.  It can.  DO NOT echo POST, GET, or COOKIE variables back to 
the user without AT LEAST escaping things like quotes, angle brackets, and 
so on.  The htmlspecialchars() or htmlentities() functions are a good 
start.


Michael Sims