Revision: 4286 is old, please update to the latest version in our SVN which has lots of bug fixes.
On Mon, Apr 23, 2012 at 12:44 PM, You Know My Name, My name is Bond, James Bond <[email protected]> wrote: > Re: W3af stoops after scanning 21.60% or crashes > > Hi Andres, > Please see the messages which I copied from the terminal till the point of > crash: > Starting w3af, running on: > Python version: > 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit (Intel)] > GTK version: 2.22.0 > PyGTK version: 2.22.0 > > w3af - Web Application Attack and Audit Framework > Version: 1.1 (from SVN server) > Revision: 4286 > Author: Andres Riancho and the w3af team. > Traceback (most recent call last): > File "C:\Program Files\w3af\w3af\core\ui\gtkUi\main.py", line 640, in > startSca > nWrap > self.w3af.start() > File "C:\Program Files\w3af\w3af\core\controllers\w3afCore.py", line 441, > in s > tart > self._realStart() > File "C:\Program Files\w3af\w3af\core\controllers\w3afCore.py", line 542, > in _ > realStart > self._fuzzableRequestList = self._discover_and_bruteforce() > File "C:\Program Files\w3af\w3af\core\controllers\w3afCore.py", line 352, > in _ > discover_and_bruteforce > discovered_fr_list = self._discover( tmp_list ) > File "C:\Program Files\w3af\w3af\core\controllers\w3afCore.py", line 774, > in _ > discover > result = self._discoverWorker( toWalk ) > File "C:\Program Files\w3af\w3af\core\controllers\w3afCore.py", line 846, > in _ > discoverWorker > pluginResult = plugin.discover_wrapper( fr ) > File "C:\Program > Files\w3af\w3af\core\controllers\basePlugin\baseDiscoveryPlug > in.py", line 48, in discover_wrapper > return self.discover( fuzzable_request_copy ) > File "C:\Program Files\w3af\w3af\plugins\discovery\allowedMethods.py", > line 98 > , in discover > self._check_methods( domain_path ) > File "C:\Program Files\w3af\w3af\plugins\discovery\allowedMethods.py", > line 14 > 2, in _check_methods > i.setId( [non_exist_response.getId(), get_response.getId()] ) > File "C:\Program Files\w3af\w3af\core\data\kb\info.py", line 257, in setId > raise Exception('All request/response ids have to be integers.') > Exception: All request/response ids have to be integers. > > > > ________________________________ > From: "[email protected]" > <[email protected]> > To: [email protected] > Sent: Monday, April 23, 2012 5:23 AM > Subject: W3af-users Digest, Vol 57, Issue 9 > > Send W3af-users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/w3af-users > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of W3af-users digest..." > > > Today's Topics: > > 1. Re: [W3af-develop] does w3af can scan the new vulnerabitiy > HTML5 - ClickJacking attack detection (Taras) > 2. Re: W3af stoops after scanning 21.60% or crashes (Andres Riancho) > 3. Re: [W3af-develop] does w3af can scan the new vulnerabitiy > HTML5 - ClickJacking attack detection (Andres Riancho) > 4. Re: [W3af-develop] does w3af can scan the new vulnerabitiy > HTML5 - ClickJacking attack detection (Taras) > 5. Re: [W3af-develop] does w3af can scan the new vulnerabitiy > HTML5 - ClickJacking attack detection (Taras) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 23 Apr 2012 15:21:50 +0400 > From: Taras <[email protected]> > Subject: Re: [W3af-users] [W3af-develop] does w3af can scan the new > vulnerabitiy HTML5 - ClickJacking attack detection > To: Andres Riancho <[email protected]> > Cc: [email protected], > [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Andres, > >>>> If we analyze 5 (self._vuln_limit = 5) and those 5 don't have >>>> protection, that doesn't mean that all don't implement it. >>> >>> Agree, but please re-read this piece of code. There is no >>> self._vuln_limit >>> checks here. >> >> Yes, but self._vuln_count size strictly depends on self._vuln_limit > > No, that I'm trying to prove you! Please re-read logic of grep method. :) > >>>> I would completely remove "self._vuln_limit" as it doesn't make >>>> logical sense to only analyze "a section of the application" if we can >>>> analyze all of it. Also, by removing "self._vuln_limit" you'll see >>>> that the memory usage of "self._vulns = []" will grow linearly with >>>> the application's size (if there is no protection) which is no good, >>>> so I recommend using a temp_shelve. >>> >>> Hmm, the aim of self._vuln_limit is mostly to make report easy to read. >>> If >>> 15 or more requests are vulnerable do we need to store and show all these >>> 15 >>> requests to the user? >> >> We're reporting two vulnerabilities: >> * All are vulnerable, in which case we don't even need to add URLs >> since *all* are vulnerable >> * Some are vulnerable, in which case we should print all URLs in >> the vulnerability description (annoying in some cases... but needed in >> my opinion). > All or not all - it is discussable. Let's for the first make single > conclusion about self._vuln_count and self._vuln_limit. > > > > > > -- > Taras > http://oxdef.info > > > > ------------------------------ > > Message: 2 > Date: Mon, 23 Apr 2012 08:24:34 -0300 > From: Andres Riancho <[email protected]> > Subject: Re: [W3af-users] W3af stoops after scanning 21.60% or crashes > To: "You Know My Name, My name is Bond, James Bond" > <[email protected]> > Cc: "[email protected]" > <[email protected]> > Message-ID: > <ca+1rt65w+kwvaul3ea8poa3gv_jz+dxbuwxrcwfhqr4hkf5...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > It seems that your target application is doing something odd such as > closing connections with a WAF, or there is a lot of network delay, > etc. Are you sure you're using the latest w3af version from our SVN? > With our latest version you should be able to run w3af --version and > get something like this: > > dz0@dz0-laptop:~/workspace/w3af$ ./w3af_console --version > w3af - Web Application Attack and Audit Framework > Version: 1.2 > Revision: 4923 > Author: Andres Riancho and the w3af team. > > > On Sun, Apr 22, 2012 at 10:41 PM, You Know My Name, My name is Bond, > James Bond <[email protected]> wrote: >> Hi Andres, >> >> The following is the crash report that I am getting every time that I am >> starting to run W3af Version 1.1 on Linux, Ubuntu distribution: >> >> Traceback (most recent call last): >> File "/usr/share/w3af/core/ui/gtkUi/main.py", line 590, in startScanWrap >> self.w3af.start() >> File "/usr/share/w3af/core/controllers/w3afCore.py", line 417, in start >> self._realStart() >> File "/usr/share/w3af/core/controllers/w3afCore.py", line 602, in >> _realStart >> self._end( e ) >> File "/usr/share/w3af/core/controllers/w3afCore.py", line 676, in _end >> tm.join( joinAll=True ) >> File "/usr/share/w3af/core/controllers/threads/threadManager.py", line >> 119, >> in join >> self._threadPool.wait( ownerObj, joinAll ) >> File "/usr/share/w3af/core/controllers/threads/threadpool.py", line 260, >> in >> wait >> self.poll(block=True, ownerObj=ownerObj, joinAll=joinAll) >> File "/usr/share/w3af/core/controllers/threads/threadpool.py", line 245, >> in >> poll >> raise result >> w3afException: w3afMustStopException found by _send_404, someone else will >> handle it. >> >> Any help will be greatly appreciated. >> >> Sincerely >> >> James >> >> ________________________________ >> From: Andres Riancho <[email protected]> >> To: "You Know My Name, My name is Bond, James Bond" >> <[email protected]> >> Cc: "[email protected]" <[email protected]> >> Sent: Sunday, April 22, 2012 6:15 AM >> Subject: Re: [W3af-users] W3af stoops after scanning 21.60% or crashes >> >> Sorry but I didn't read your email just the subject, which w3af >> version are you using? Which OS? >> >> On Sat, Apr 21, 2012 at 10:02 PM, You Know My Name, My name is Bond, >> James Bond <[email protected]> wrote: >>> Dear Andr?s, >>> >>> I am writing this email to you requesting your assistant in helping me in >>> troubleshooting problems with W3af. Your kindness and response to my >>> email >>> will be immensely appreciated. >>> >>> I have been using W3af for the past two weeks very extensively. I am very >>> excited about the program and I can see how the program can stand up to >>> its >>> promises. But, unfortunately, I have not been able to complete even a >>> single >>> operation with the W3af due to crashing and or to program suspending >>> operation. >>> >>> Initially I have used W3af on Linux, Ubuntu distribution, which I have >>> downloaded directly from the Ubuntu package archives. Unfortunately, the >>> program kept on crashing shortly after starting. I was thinking that >>> perhaps >>> I have misused or misconfigured the W3af, which now I do not believe is >>> the >>> case. I have read the w3af User Guide, Document version: 2.0 many times >>> and >>> watched videos on YouTube and on W3af website. >>> >>> Just before giving up on the program I decided to install W3af on Window >>> 7. >>> The program runs without crashing, but it seems to stop all the time when >>> reaching 21.60%. I have left the program running for 3 days assuming that >>> the warning, which is clearly stating in the w3af User Guide -- it is >>> going >>> to take long time and perhaps days -- might be relevant to my case. >>> >>> On a positive note, W3af managed to discover with only 21.60% numerous >>> "MD5" >>> hash and to detect other vulnerabilities. However, by conducting several >>> deferent scans I have gotten different results.? In a way of example W3af >>> found deferent number of hashs on the same website. >>> >>> I could not manage to decode any of the MD5s using the tools provided in >>> W3af. Those Hashs are: >>> >>> ??? D41d8cd98f00b204e9800998ecf8427e >>> >>> ??? 6fa5720fad59de166d01936dc0982d61 >>> >>> ??? faa166cdbdb7d5ea61dae46bbf4db088" >>> >>> SHA1 da39a3ee5e6b4b0d3255bfef95601890afd80709 >>> >>> aptchaKey=1ae0fcc6e08bb30eeeed7bb7fc00da80 >>> >>> I am taking this opportunity and thanking you in advance for taking your >>> time to read this email and eagerly waiting for your prompt reply. >>> Sincerely >>> >>> James >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> For Developers, A Lot Can Happen In A Second. >>> Boundary is the first to Know...and Tell You. >>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >>> http://p.sf.net/sfu/Boundary-d2dvs2 >>> _______________________________________________ >>> W3af-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/w3af-users >>> >> >> >> >> -- >> Andr?s Riancho >> Project Leader at w3af - http://w3af.org/ >> Web Application Attack and Audit Framework >> >> > > > > -- > Andr?s Riancho > Project Leader at w3af - http://w3af.org/ > Web Application Attack and Audit Framework > > > > ------------------------------ > > Message: 3 > Date: Mon, 23 Apr 2012 08:31:32 -0300 > From: Andres Riancho <[email protected]> > Subject: Re: [W3af-users] [W3af-develop] does w3af can scan the new > vulnerabitiy HTML5 - ClickJacking attack detection > To: Taras <[email protected]> > Cc: [email protected], > [email protected] > Message-ID: > <CA+1Rt65FNKyUSPeMVpq=tdzs9qc1nbdspimtrmiemb2x20y...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Taras, > > On Mon, Apr 23, 2012 at 8:21 AM, Taras <[email protected]> wrote: >> Andres, >> >> >>>>> ? ? If we analyze 5 (self._vuln_limit = 5) and those 5 don't have >>>>> protection, that doesn't mean that all don't implement it. >>>> >>>> >>>> Agree, but please re-read this piece of code. There is no >>>> self._vuln_limit >>>> checks here. >>> >>> >>> Yes, but self._vuln_count size strictly depends on self._vuln_limit >> >> >> No, that I'm trying to prove you! Please re-read logic of grep method. :) > > OHHHH! Now I get it! self._vulns is strictly related, not self._vuln_count! > > 55 if len(self._vulns) <= self._vuln_limit\ > 56 and response.getURL() not in self._vulns: > 57 self._vulns.append(response.getURL()) > > All right, now it all makes more sense. With this new information, I > still think that we should give the user the complete knowledge of > which URLs are vulnerable. Lets think about a use case: > > - User runs w3af and finds that some URLs in his site (a,b,c,d,e) are > vulnerable to clickJacking > - User sends email to developers to fix the vuln in (a,b,c,d,e) > - User runs w3af to verify the fix and now finds that his site is > vulnerable to clickJacking but now in URLs (x,y,z,w,j) > - User sends email to developers to fix the vuln in (x,y,z,w,j) > - User runs w3af to verify the fix and now finds that his site is > vulnerable to clickJacking but now in URLs (k,l,m,n,o) > - User hates w3af :) > >> >>>>> ? ? I would completely remove "self._vuln_limit" as it doesn't make >>>>> logical sense to only analyze "a section of the application" if we can >>>>> analyze all of it. Also, by removing "self._vuln_limit" you'll see >>>>> that the memory usage of "self._vulns = []" will grow linearly with >>>>> the application's size (if there is no protection) which is no good, >>>>> so I recommend using a temp_shelve. >>>> >>>> >>>> Hmm, the aim of self._vuln_limit is mostly to make report easy to read. >>>> If >>>> 15 or more requests are vulnerable do we need to store and show all >>>> these >>>> 15 >>>> requests to the user? >>> >>> >>> We're reporting two vulnerabilities: >>> ? ? * All are vulnerable, in which case we don't even need to add URLs >>> since *all* are vulnerable >>> ? ? * Some are vulnerable, in which case we should print all URLs in >>> the vulnerability description (annoying in some cases... but needed in >>> my opinion). >> >> All or not all - it is discussable. Let's for the first make single >> conclusion about self._vuln_count and self._vuln_limit. >> >> >> >> >> >> -- >> Taras >> http://oxdef.info > > > > -- > Andr?s Riancho > Project Leader at w3af - http://w3af.org/ > Web Application Attack and Audit Framework > > > > ------------------------------ > > Message: 4 > Date: Mon, 23 Apr 2012 14:58:13 +0400 > From: Taras <[email protected]> > Subject: Re: [W3af-users] [W3af-develop] does w3af can scan the new > vulnerabitiy HTML5 - ClickJacking attack detection > To: Andres Riancho <[email protected]> > Cc: [email protected], > [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Andres, > >> Could you please explain me this comment? "# TODO need to check >> here for auth cookie?!" > > Simply, does web app vulnerable to ClickJacking if it hasn't user's area? > In other words do we need here to check auth state like in CSRF > detection? In ideal case we need it. > >> Instead of the following: >> >> 49 headers = response.getLowerCaseHeaders() >> 50 for header_name in headers: >> 51 if header_name == 'x-frame-options'\ >> 52 and headers[header_name].lower() in ('deny', >> 'sameorigin'): >> 53 return >> >> You could do something like: >> >> headers = response.getLowerCaseHeaders() >> x_frame_options = headers.get('x-frame-options', None) >> if x_frame_options and x_frame_options in ('deny', 'sameorigin'): >> return > Agree, will fix it. > >> This is actually not true: >> >> 76 if self._total_count == self._vuln_count: >> 77 msg = 'The whole target ' >> 78 msg += 'has no protection (X-Frame-Options header) >> against ClickJacking attack' >> >> If we analyze 5 (self._vuln_limit = 5) and those 5 don't have >> protection, that doesn't mean that all don't implement it. > Agree, but please re-read this piece of code. There is no > self._vuln_limit checks here. > >> I would completely remove "self._vuln_limit" as it doesn't make >> logical sense to only analyze "a section of the application" if we can >> analyze all of it. Also, by removing "self._vuln_limit" you'll see >> that the memory usage of "self._vulns = []" will grow linearly with >> the application's size (if there is no protection) which is no good, >> so I recommend using a temp_shelve. > Hmm, the aim of self._vuln_limit is mostly to make report easy to read. > If 15 or more requests are vulnerable do we need to store and show all > these 15 requests to the user? > >> Sorry if I'm being too strict, but I think we can do better than this >> :) > There is no problem with criticism for me :) > -- > Taras > http://oxdef.info > > > > ------------------------------ > > Message: 5 > Date: Mon, 23 Apr 2012 16:25:16 +0400 > From: Taras <[email protected]> > Subject: Re: [W3af-users] [W3af-develop] does w3af can scan the new > vulnerabitiy HTML5 - ClickJacking attack detection > To: Andres Riancho <[email protected]> > Cc: [email protected], > [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Ok, you win :) > We will show all requests to the user. > > On 04/23/2012 03:31 PM, Andres Riancho wrote: >> Taras, >> >> On Mon, Apr 23, 2012 at 8:21 AM, Taras<[email protected]> wrote: >>> Andres, >>> >>> >>>>>> If we analyze 5 (self._vuln_limit = 5) and those 5 don't have >>>>>> protection, that doesn't mean that all don't implement it. >>>>> >>>>> >>>>> Agree, but please re-read this piece of code. There is no >>>>> self._vuln_limit >>>>> checks here. >>>> >>>> >>>> Yes, but self._vuln_count size strictly depends on self._vuln_limit >>> >>> >>> No, that I'm trying to prove you! Please re-read logic of grep method. :) >> >> OHHHH! Now I get it! self._vulns is strictly related, not >> self._vuln_count! >> >> 55 if len(self._vulns)<= self._vuln_limit\ >> 56 and response.getURL() not in self._vulns: >> 57 self._vulns.append(response.getURL()) >> >> All right, now it all makes more sense. With this new information, I >> still think that we should give the user the complete knowledge of >> which URLs are vulnerable. Lets think about a use case: >> >> - User runs w3af and finds that some URLs in his site (a,b,c,d,e) are >> vulnerable to clickJacking >> - User sends email to developers to fix the vuln in (a,b,c,d,e) >> - User runs w3af to verify the fix and now finds that his site is >> vulnerable to clickJacking but now in URLs (x,y,z,w,j) >> - User sends email to developers to fix the vuln in (x,y,z,w,j) >> - User runs w3af to verify the fix and now finds that his site is >> vulnerable to clickJacking but now in URLs (k,l,m,n,o) >> - User hates w3af :) >> >>> >>>>>> I would completely remove "self._vuln_limit" as it doesn't make >>>>>> logical sense to only analyze "a section of the application" if we can >>>>>> analyze all of it. Also, by removing "self._vuln_limit" you'll see >>>>>> that the memory usage of "self._vulns = []" will grow linearly with >>>>>> the application's size (if there is no protection) which is no good, >>>>>> so I recommend using a temp_shelve. >>>>> >>>>> >>>>> Hmm, the aim of self._vuln_limit is mostly to make report easy to read. >>>>> If >>>>> 15 or more requests are vulnerable do we need to store and show all >>>>> these >>>>> 15 >>>>> requests to the user? >>>> >>>> >>>> We're reporting two vulnerabilities: >>>> * All are vulnerable, in which case we don't even need to add URLs >>>> since *all* are vulnerable >>>> * Some are vulnerable, in which case we should print all URLs in >>>> the vulnerability description (annoying in some cases... but needed in >>>> my opinion). >>> >>> All or not all - it is discussable. Let's for the first make single >>> conclusion about self._vuln_count and self._vuln_limit. >>> >>> >>> >>> >>> >>> -- >>> Taras >>> http://oxdef.info >> >> >> > > > -- > Taras > http://oxdef.info > > > > ------------------------------ > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > > > ------------------------------ > > _______________________________________________ > W3af-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/w3af-users > > > End of W3af-users Digest, Vol 57, Issue 9 > ***************************************** > > -- Andrés Riancho Project Leader at w3af - http://w3af.org/ Web Application Attack and Audit Framework ------------------------------------------------------------------------------ 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-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/w3af-users
