Martin,

On Wed, Feb 24, 2010 at 4:18 PM, Martin Holst Swende <mar...@swende.se> wrote:
> Hi all,
>
> I was browsing through the code for the xss-module, when I came upon a
> strange thing :
>
>       # Analyze the response
>        allowed = []
>        if response.getBody().count(list_delimiter) == 2:
>           ...[checks for what chars are available]...
>        else:
>            raise w3afException('The delimiter was not echoed back!')
>
>
> What if the input parameter is echoed twice on the page, resulting in 4
> list_delimiters?

    You're completely right! That was completely my fault, but at most
this breaks a performance enhancement, not xss detection.

> Also, when checking if echo occurs, this is used - which I guess checks
> the whole response object (incl headers) :
>
>        # Analyze and return response
>        if rndNum in response:
>            om.out.debug('The variable ' + mutant.getVar() + ' is being
> echoed back.' )
>            return True
>
> However, when checking for our xss, only the body is checked, as shown
> above.

    Your guess is incorrect, "foo in response" will only check if foo
is in the response body.

> I created a spin-off from xss.py called xssLite.py. It is basically a
> stripped down xss.py which only stores to kb if
> any of a set of special characters are echoed back to the page: < > ' "
> So it checks only four characters (and could probably skip '>' since it
> usually is treated (encoded dropped or left alone) exactly as '<' by the
> server.
> It has the option to test each character separately, increasing the
> chance of not getting filtered.

    This could be a good idea... but... isn't it the same thing I'm
trying to do with the performance enhancement of sending the
separators, etc.?

> I also shortened the resulting payload string by placing all chars
> between random value :  <RND1>C<RND2>D<RND3>... , so all random parts
> can be
> used by two times, once as suffix and once as prefix. (match for d =
> body.find("<RND2>D<RND3>")). And fixed the error with if the stuff is
> echoed back several times.
>
> Personally, I prefer using it this way (i.e: getting to know what chars
> are unfiltered) without totally relying on the framework to deduce
> exactly what vector can be used or not.

    I understand why you could prefer this... is it because the list
of vectors is reduced and maybe you could actually exploit a XSS
without entering a > in some cases, or without entering a " in others?

    What I think is missing from the XSS plugin is the ability to know
WHERE the user controlled information is echoed back. By where I mean
x or y:

<tag parameter="x">y</tag>

    When the plugin identifies that the user controlled information is
being used in x, then it should check if it is possible to escape from
the parameter string using another " (in some cases another '), if its
not possible because the character is escaped, then xss is not
possible (correct me if I'm missing some edge case here). In the y
case, the plugin should check if it is able to send < AND > and they
don't get escaped.

    I think that it would be really cool to add this logic to the
plugin, which will transform the act of sending the vectors in a
"proof of concept" because the plugin will already know its
exploitable in some way.

    Got my idea? What do you think?

Regards,

> Regards,
> Martin Holst Swende
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> W3af-develop mailing list
> W3af-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/w3af-develop
>
>



-- 
Andrés Riancho
Founder, Bonsai - Information Security
http://www.bonsai-sec.com/
http://w3af.sf.net/

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
W3af-develop mailing list
W3af-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/w3af-develop

Reply via email to