Greetings,

Not one to second-guess users' intentions, I like to throw back at
them any text input that didn't make it through a couple of
basic preg_match()'d sanity checks. This means reloading the
form with the _unaltered_ input as respective 'value' attributes, combined
with a friendly error message for the merely befuddled. The downright
vicious may choke on their own pathetic attempts at XSS.

But, how sane is such an approach from a security perspective? Is there
anything that might come around and bite me in the ass?

Any input greatly appreciated.

Mike

Michael Ruebner <njus@lunchinglads.net> writes:

> Greetings,
>
> Not one to second-guess users' intentions, I like to throw back at
> them any text input that didn't make it through a couple of
> basic preg_match()'d sanity checks. This means reloading the
> form with the _unaltered_ input as respective 'value' attributes, combined
> with a friendly error message for the merely befuddled.

Sound good in theory.

> The downright
> vicious may choke on their own pathetic attempts at XSS.

*If* that's true, then the input can be used as an XSS attack -
they'll just have to lure some unsuspecting victim to the
error/feedback page you created.

> But, how sane is such an approach from a security perspective? Is there
> anything that might come around and bite me in the ass?

Either you stop things like Javascript injection with proper escaping
etc, in which case it won't be a problem, or this will definitely bite
you.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

Joost Diepenmaat:

> *If* that's true, then the input can be used as an XSS attack -
> they'll just have to lure some unsuspecting victim to the
> error/feedback page you created.

None of the returned values will ever be stored in a session (or make it
into the database), so I assume that hijacking and/or redirection will not
be an issue. Put another way around, if the attacker's browser will be the
only client to display rouge input, what's the harm to the rest of us?

Mike

Michael Ruebner <njus@lunchinglads.net> writes:
> Joost Diepenmaat:
> > *If* that's true, then the input can be used as an XSS attack -
> > they'll just have to lure some unsuspecting victim to the
> > error/feedback page you created.
>
> None of the returned values will ever be stored in a session (or make it
> into the database), so I assume that hijacking and/or redirection will not
> be an issue. Put another way around, if the attacker's browser will be the
> only client to display rouge input, what's the harm to the rest of us?

vulnerable.php => <?php print ($_GET['print']); ?>

<a href="vulnerable.php?print=<script>alert(document. )</script>">
Please follow this link</a>

The attacker is the person who creates the link (or form, if it's a
POST-based attack instead).
The victim is the person who gets tricked into clicking on it.
They don't need to be the same person.

Persistent XSS, where the value gets stored in the database and then
redisplayed, is *worse* than this because the victims just have to
look at the legitimate site, and the more that look, the worse it
gets. However, tricking someone into clicking on a link on a
relatively unrelated web page is not exactly difficult.

With most common web programming languages making it incredibly
difficult to avoid filling code with XSS bugs, it's not an easy thing
to ensure doesn't happen, but it's absolutely necessary.

http://www.cgisecurity.com/articles/xss-faq.shtml has a few more examples.

--
Chris

Chris Morris:

> The attacker is the person who creates the link (or form, if it's a
> POST-based attack instead).
> The victim is the person who gets tricked into clicking on it.
> They don't need to be the same person.

OK. Got it. I was stuck on persistent XSS and lost sight of the simpler
things in life ;-)

Thanks for your, and Joost's, input.

Mike