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. If it can then we have possible XSS flaw.
I **hope** that number of requests to detect possible XSS flaw will be decreased to only 1 request 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 :) Current state: I'm coding in XSS branch context detection logic with unittests for it. 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 ------------------------------------------------------------------------------ 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
