Taras,
On Tue, Jun 19, 2012 at 12:40 PM, Taras <ox...@oxdef.info> wrote:
> Andres,
>
> Yes, I plan to spend this week coding of xss plugin:)
> My idea is to have opportunity to find out current HTML context of payload
> and determine can our XSS payload can break this context.
Perfect, that's really what we need.
> If it can then we have possible XSS flaw.
Yep!
> I **hope** that number of requests to detect possible XSS flaw will be
> decreased to only 1 request
My opinion is that it won't be possible to do it with 1 request
AND have a good heuristic that will work when some filters are in
place. For example, if you send a payload that has ALL que special
chars; the filter only tries to match against SOME of them and if they
are found it will stop processing the whole request, you would miss
some XSS that are possible without the special char that is in the
filter.
> with complex XSS payload per request's param.
> For example, we have URL http://target/test.php?a=1&b=2&c=3
>
> w3af will send 3 requests (by number of params) + 1 for stored XSS
> detection. All the magic will be on w3af's side without needing to send big
> number of requests.
>
> I also hope to code it without regex :)
That sounds possible, once you've got the payload in the HTTP
response body, you start iterating forward/backwards in order to find
special characters that tell you in which context you're. That
function is PERFECT for unittesting before even integrating into the
plugin. I can provide some unittests if you want me to.
Question: Are you thinking about the case where the payload is
echoed in the page more than once? Also, it might be in different
contexts in each position; and different filters applied to it on
each. (damn. I just ruined your day).
> Current state: I'm coding in XSS branch context detection logic with
> unittests for it.
Yes, yes, unittests, I love those.
> Will be glad to read any comments and ideas.
>
>
> On 06/19/2012 06:00 PM, Andres Riancho wrote:
>>
>> @List: I've shared this file with Taras 3 or 4 weeks ago and we talked
>> face to face about it, we decided that he was going to be working on
>> the XSS plugin improvements and he just created a branch for it.
>>
>> @Taras: Please share your progress regarding the XSS plugin with us in
>> the w3af-develop mailing list :) Maybe starting another thread? Please
>> remember to test your XSS plugin against WAVSEP test cases in order to
>> make sure we're detecting all of them.
>>
>> Regards,
>>
>> On Wed, Apr 25, 2012 at 1:19 PM, Taras<ox...@oxdef.info> wrote:
>>>
>>> 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
>>
>>
>>
>>
>
>
> --
> Taras
> http://oxdef.info
--
Andrés Riancho
Project Leader at w3af - http://w3af.org/
Web Application Attack and Audit Framework
Twitter: @w3af
GPG: 0x93C344F3
------------------------------------------------------------------------------
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
