Martin, Taras,
While trying to code the new xss.py I've found myself in a
situation where I see that it's difficult to cover all cases. Just to
make sure we're talking about the same thing, what we're trying to do
is to detect reflected XSS vulnerabilities with the lowest amount of
HTTP requests, lowest false positive and false negative rate. This is
the algorithm that I'm implementing and I would like to get your
feedback on:
* Send hN<97>97"97'97(97)hN or a similar payload [0]
* Analyze the HTML response and identify WHERE in the HTML
structure the payload is echoed back and WHICH special characters were
allowed in each context. The context is one or more of the following
places (taking into account that the input might be echoed more than
once):
TAG
ATTR_NAME
ATTR_DOUBLE_QUOTE
ATTR_SINGLE_QUOTE
TEXT
COMMENT
SCRIPT
CDATA
* This should give us a result similar to this:
[ (ATTR_NAME, ['<','>', '"' ...]) , (TEXT, ['"', '\'', '(', ')']) ]
* Then we could analyze that result and say: "For an XSS
vulnerability to appear in an ATTR_NAME I have to be able to send a
double quote". If it is possible in this case then the plugin should
send a specific payload for that case, something similar to --"
onload="foo()"--
* Finally, analyze the second response body and if there is an
attribute in one of the DOM objects that's called "onload" and it's
text is "foo()" then we have a XSS.
Ideas? Does this cover all major cases? Should we have two or more
XSS detection algorithms and run them all (configurable by the user)?
[0] The problem with this are filters that say: "If special char X in
input then don't echo anything", where "X" might be "<" and that
affects our possibility to detect if any of the rest of the chars are
allowed
Regards,
On Thu, Feb 16, 2012 at 4:13 PM, Martin Holst Swende <mar...@swende.se> wrote:
> On 02/16/2012 07:54 PM, Andres Riancho wrote:
>> <RANDOM><>"'(); and find the same string in the response, that doesn't
>> confirm a XSS (there might be a filter that removes the inputs with
>> "script" in it)
> That may be true, but if input can break HTML context - it's a
> vulnerability. Actually finding
> an XSS is the next step - exploitation of said vulnerability. I think a
> better scheme would be to
> first discover the vulnerability with a minimum of probes then go to
> the second stage where
> a lot of requests can be staged (better to massively bombard 1% of all
> functions than to medium
> assault 95% :)).
>
>
>>> Another suggestion is to try determine context of echoed back string:
>>> html (including attributes), js, css and so on [1]. Good illustration
>>> of such behavior is RatProxy [2]
> The stuff I was working on earlier is better described here :
> http://sourceforge.net/mailarchive/message.php?msg_id=24638992
> Looking at the ratproxy code, I see that it does a somewhat similar
> thing (but probably with more cleverness). It tries to determine the
> html context of the injection. I think the XSS plugin should do those
> steps as a preliminary, then move on to exploitaition (which I never
> implemented in my final version :
> http://sourceforge.net/mailarchive/message.php?msg_id=24682898 ) .
>
> Cheers,
> Martin
>
>
>> RatProxy's code is crazy, reading through it give me nightmares ;)
>> Just read through the XSS context detection [0] and I have some
>> concerns about how well that would work in real scenarios. What I was
>> trying to do in my code is:
>>
>> * Send the payload
>> * Get the HTML response DOM
>> * Iterate through the DOM items and verify (based on the DOM
>> objects) where I get the string echoed back
>>
>> I was just working on that last week, there are some issues with
>> the code I was working on so I simply left it in my local box. I'll
>> work some more today and send it in this email thread.
>>
>> [0] http://code.google.com/p/ratproxy/source/browse/trunk/ratproxy.c#428
>>
>>> [0]
>>> http://w3af.svn.sourceforge.net/viewvc/w3af/trunk/plugins/audit/xss.py?view=markup
>>> [1]
>>> https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
>>> [2] http://code.google.com/p/ratproxy/source/browse/trunk/ratproxy.c
>>>
>>> --
>>> Taras
>>> http://oxdef.info
>>>
>>> ------------------------------------------------------------------------------
>>> Virtualization & Cloud Management Using Capacity Planning
>>> Cloud computing makes use of virtualization - but cloud computing
>>> also focuses on allowing computing to be delivered as a service.
>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>> _______________________________________________
>>> W3af-develop mailing list
>>> W3af-develop@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/w3af-develop
>>
>>
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> W3af-develop mailing list
> W3af-develop@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/w3af-develop
--
Andrés Riancho
Director of Web Security at Rapid7 LLC
Founder at Bonsai Information Security
Project Leader at w3af
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
W3af-develop mailing list
W3af-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/w3af-develop
