Re: [W3af-develop] Bug in XSS plugin + an alternative xss plugin

[Martin H. S. <ma...@sw...>]

Hi,

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

I have now implemented the above mentioned scenario, except 8, 8b and
8c. It uses a ContextParser based on the python HTMLParser to keep track
of where a particular payload was reflected. Based on that, a list of
interesting characters are generated. After that, it basically works
like before, except I didn't add back the actual xss-vectors. Notes:
* If reflection occurs several times, like

<input value="foo"/><p>You searched for foo</p>

the generated list will be " and <>. When test next step tests [",<,>]
and the server responds with

<input value="%22<>"/><p>You searched for "&lt;&gt;</p>

The current logic will think this is XSS. It would be easy to use the
same context-parser in this step aswell to eliminate those false
positives. However, since the input the second time most likely will
contain 'broken' html, the parser will throw errors when parsing it...

* The response body (and payload) is made lowercase before searching to
make the searches case insensitive. When I tested the plugin against
some sites, I noticed that one of them capitalized my input in a title tag.

Regards,
Martin Holst Swende