Andres, ping! :)
On 03/19/2012 12:34 AM, Taras wrote:
> Andres, what is status of new XSS.py?
> Where can we get it to test?:)
>
>
>> your scenario looks good! But don't forget to notify user that xss.py
>> have found potential XSS flaw (as info) if on the second stage we will
>> not get good result from second response.
>>
>>> 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.
>> We can determine it by searching backwards for HTML special chars from
>> echoed point.
>>
>>> 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
>> + simple ATTR without quotes?
>>> 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)?
>> old one and new smart? I think we can regard new one as evolution
>> version and save only it:)
>>
>>> [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
>>>>>>
>>>>>> ------------------------------------------------------------------------------
--
Taras
http://oxdef.info
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
W3af-develop mailing list
W3af-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/w3af-develop
