|
Posted by Michael Ruebner on April 28, 2008, 5:13 pm
Please log in for more thread options
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
|
|
Posted by Joost Diepenmaat on April 29, 2008, 3:24 am
Please log in for more thread options
> 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/
|
|
Posted by Michael Ruebner on May 1, 2008, 7:11 am
Please log in for more thread options 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
|
|
Posted by Chris Morris on May 1, 2008, 7:23 am
Please log in for more thread options > 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.cookie)</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
|
|
Posted by Michael Ruebner on May 2, 2008, 8:20 am
Please log in for more thread options 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
|
| Similar Threads | Posted | | receipt of form values by an HTML page | October 10, 2007, 2:56 pm |
| User hits back button - has to enter form values from scratch | January 31, 2008, 8:39 pm |
| sending hidden values AND option values at the same time ? | September 12, 2006, 12:52 am |
| tag to provoke reload | February 12, 2007, 2:18 pm |
| Memory clearing and reload. | January 23, 2005, 3:00 pm |
| how to reload only part of html ? | July 24, 2005, 12:42 am |
| opera doesn't reload iframe | August 8, 2006, 6:28 am |
| Smallest Possible | width values | April 1, 2005, 6:02 am |
| Class attribute values | November 7, 2005, 7:27 am |
| splitting long attribute values | February 16, 2007, 10:05 pm |
|
XML Sitemap