[WEB SECURITY] Cross Site Scripting

[Arian J. Evans]

Tom -- ASP .NET request validator: this comes up about 3x per year on
this list. Search the archives and you'll find more. If you go to the
OWASP guide at owasp.org I wrote up some detail with links to the msdn
pages describing the general controls, but not *what* exactly it does
under the hood. I have a reverse engineered version of 1.1 I will
post, if I get around to it.

So the validators work fairly well, for what they are. However, they
get turned off often in my experience, or not consistently applied,
which puts you back into your "unsafe data handling" bucket when
<default_magic_control> that devs don't really understand exists gets
flipped into mode=off.

It's a really massive regex. You can easily view it. Comprehending it
is a different thing. In terms of bypassing it using IE's dynamic
properties, I found it was easier to fuzz using metacharacters padding
the (expression()) than it was to analyze the regex, but then again, I
was also evaluating the parser.

---

The big difference I find (re: metacharacter attacks) between 1.1 and
2.0 is the handling of the API in relation to HTTP verbs. 1.1 doesn't
enforce that the HTTP API is correctly submitted for the verb in
question, e.g. a POST is allowed to have name-value pairs or other
malformed data in the URI that gets processed. Somewhere around
2.something this gets locked down.

It's funny how long it's taken for folks to start addressing XSS as an
encoding problem, but even then, folks rarely tend to understand what
encoding types exist and are safe for what purposes. When I worked for
FishNet I think was recommending this back around 2003, and until
recently almost all the automated scanners, and many consultant
reports I'd see, would still have this "remove the bad characters"
game as their primary recommendation.

Output encoding won't solve if folks are allowing user-supplied HTML.

-- 
Arian Evans
software security stuff



On 9/20/07, Tom Stripling <tstripling at securityps.com> wrote:
>
>
>
> Question for the group.
>
>
>
> ASP.NET 2.0 has a built-in form of blacklist input validation that attempts
> to prevent attacks like cross-site scripting by checking for sequences like
> "<z" (where 'z' is any letter) and so on.  What do people think of the
> effectiveness of this defense?  What if developers rely on it exclusively
> for input validation?  Do you know of attack strings that will bypass it?  I
> know of some that work in specialized cases, but in the "vanilla" case where
> I'm just injecting straight onto the page, I don't know of a lot of attacks
> that will bypass the validation and still execute.  So, I'm curious to hear
> from others' experience.  I've done a miserable job of describing everything
> it actually does, so please don't rely on my description to come up with
> your counterexample.  I'm looking for something that works against the real
> thing.
>
>
>
> As a caveat, I agree with James that XSS is an output encoding problem.  I
> have always recommended a combined approach of input validation + output
> encoding, since omitting either will leave you vulnerable to various logic
> or injection attacks.  If you were going to point this out to me, you may
> now put down your keyboard and breathe a sigh of relief.
>
>
>
> - Tom Stripling
>

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]