Taras,
On Mon, Jun 25, 2012 at 12:53 PM, Taras <ox...@oxdef.info> wrote:
> Andres, thanks for feedback!
>
>
>> * context.py:
>> - There are a lot of locations where something similar to this
>> is done: "if data.lower().rfind('<script')" , what if the tag is in
>> upper-case? or what about cases like "< script" ? Are we applying this
>> logic after the lxml parser that sanitizes this? If so, does it make
>> sense to work with that version of the response or with the original
>> version that came from the network?
>
> Upper case tag is ok. HTML is not case sensitive (because of it I use
> lower() everywhere in the code) and yes, here I need raw body from response.
> I use response.getBody(). Does this method return clear body without lxml
> changes?
Yes, it will return the HTTP response body that came from the network
after it was decoded using the charset specified in the HTTP response
body.
>
>> - While reading, testing, analyzing the code I migrated the
>> unittests to a different module in core/data/contexts/tests/ . If you
>> want to see the test output when running them with nosetests you can
>> use the -s flag that will allow you to see any debug "print" that you
>> put. Please "svn up" ASAP so you get these changes and can work on top
>> of them.
>
> Ok.
>
>
>> - The code worked amazingly well, even with some broken HTML
>> tests that I tried!
>
> Great! :)
>
>>
>> - Have you checked with WAVSEP's XSS examples to see if we
>> have all the contexts required to pass those tests? I've looked at the
>> list of all available contexts in context.py and it seems very
>> detailed but maybe they have something else.
>
> Not yet. But I have planned it.
Great,
>>
>> - Just for clarity I would rename Comment() to HTMLComment()
>
> Agree, and Text -> HtmlText, too.
Great,
>>
>> - Add more tests to test_context.py , the code seems VERY
>> good... tried to make it fail and only succeeded in one "strange" test
>> case! (see test_payload_script_single_quote) Congrats!
>
> Let's see how we will pass WAVSEP examples.
>
>>
>> - In "Text(HtmlContext)" , shouldn't can_break have both< and>
>> ?
>
> Nope, because we can change context having only '<', e.g. insert
>
> <hr onmouseover="alert(1)"/
>
> and browser will eat it and render hr!
Ahh! Nice. That works in all browsers?
>
>> * xss.py
>>
>> - In all places where something like this is done:
>> oldValue = mutant.getModValue()
>> mutant.setModValue(rndNum)
>> ...
>> # restore the mutant values
>> mutant.setModValue(oldValue)
>>
>> I think that it would be possible to do something like:
>> mutant = mutant.copy()
>>
>> And then DON'T restore the value. Not confirmed, please verify.
>
> What is advantage of using mutant.copy()?
Less lines of code. Clearer code.
>
>> - Not sure if I would keep the _is_echoed() , maybe simply
>> start testing? Maybe the application doesn't echo the value if it is
>> an alfanumeric but it will echo it if it has special characters? I've
>> seen this in many apps:
>>
>> if input_is_fine(input):
>> process(input) # no xss here
>> else:
>> print "Invalid input", input # xss here!
>>
>> - Liked _search_simple_xss() , it should catch 80% of the XSS
>> vulns
>
> Exactly! The idea of this method is to catch big part of XSS cases and
> "save" requests.
>
>> - If we remove is_echoed() , we would end up with 5 HTTP
>> requests per parameter, correct? 1 for simple_xss and 4 for the
>> payloads?
>
> Yes, and I hope in most cases it will be only **one** request (made by
> simple_xss).
If the parameter is vulnerable, in "80%" of the cases it will be 1
request. But remember that most parameters are NOT vulnerable, so we
need to think about that case and how to make that one faster.
> I think, that we can remove is_echoed because number of test
> payloads is really small.
Perfect,
>>
>> - Is there any way to prove (and add it to a unittest) that
>> the payloads in xss.py are covering all cases of can_break in
>> context.py ?
>
> Hmm, I will think about it. Please also take into account existing of
> need_break() method. Sometimes we don't need to change current context.
>
>>
>> The whole code ended up being very nice. What I'm thinking about
>> now is the possibility of having two plugins, one for persistent-xss
>> and one for reflected xss. That would allow us to have nicer code in
>> both. What do you think? (no real need to do this now)
>
> I don't think that it will have real advantages over keeping XSS detection
> logic in one place.
Maybe its because I'm thinking about rewriting persistent xss
detection in a more advanced way :) What I want to do is to inject
unique identifiers (alnum) into all parameters, then crawl the
application again, find those identifiers and create a very clear map
of src->dst , and then start fuzzing the src and check the dst (with
context) to check if there is a persistent XSS.
>
>>> + Taras is also working on web20Spider which gives w3af possibility to at
>>> least crawl modern web apps with heavy usage of AJAX. I think PoC will be
>>> finished in the nearest days. I use PhantomJS/CasperJS for browser
>>> iterations. Currently the code can crawl states of web app (clicks on a
>>> and
>>> img objects).
>>
>>
>> Which branch? What's the environment needed to test this?
>
> branch is called webapps. In the nearest days I will add some related code
> in it and begin coding of discovery.web20Spider. For this time you can look
> on PhantomJS [0] and CasperJS [1]. It are really good tools for automated
> web UI testing. The first one is headless WebKit with JavaScript API, and
> the second one is toolkit over the first one. The decision to use these
> tools is not final but it is good opportunity for the first step forward
> browser integration.
Great! I'll take a look into that later today
> [0] http://phantomjs.org/
> [1] http://casperjs.org/
>
> --
> 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
