Hi,
Andres Riancho wrote:
> 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.?
>
Yes and no. It is basically the same thing, but yours did not report to
the kb and did not allow for testing one char at a time. The main reason
I made a new one was to experiment a bit, but I think we should merge it
into a new and better one (see below) .
>
>> 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?
>
Yes, partly, also because maybe there is a WAF which filters a
particular vector because it contains "<script>", while "<script%00>"
would have worked fine.
> 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?
>
Yes, it sounds like a great idea! This is the way I think it *should*
work :
1 Send out reflector probes (as right now)
2 Check responses, if reflected continue (as right now)
3 Check in what context the reflection occurred (may be several - each
one must be tested for):
<tag param="a" param='a2'>b</tag>
special case :
<script>foo="c" ; baz = 'c2'</script>
4. Based on context, determine what characters are needed to break
context (if needed) and possibly execute xss. In examples above :
a: "
a2:'
b:<>
c:" or <>
c2: ' or <>
5. Test the generated list of characters clumped together
6. Optional step (thoroughtest) : If the parameter was not reflected at
all this time, test each character separately
7. Report any findings where context can be broken
8. Optional step (xss-vector): Check extra chars such as () and others
needed to construct a vector
8b: Test xss-vectors based on allowed chars
8c: Report xss
Would you agree?
Then only one xss module is needed, if it can be configured to do only
up to step 8 (and always reports if markup can be broken).
/Martin
> Regards,
>
>
>> Regards,
>> Martin Holst Swende
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® 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
>>
>>
>>
>
>
>
>
------------------------------------------------------------------------------
Download Intel® 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
