On Mon, Apr 23, 2012 at 9:25 AM, Taras <ox...@oxdef.info> wrote: > Ok, you win :)
Hhahaha, it is not about winning, it is about doing the best for the users :) PS: Wiiiiiii ! I 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<ox...@oxdef.info> 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 -- 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-develop mailing list W3af-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/w3af-develop
