[nycphp-talk] PHP Form Validation
Michael Sims
jellicle at gmail.com
Thu Sep 1 13:31:31 EDT 2005
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
More information about the talk
mailing list