Andres,
2009/1/21 Andres Riancho <andres.rian...@gmail.com>:
> Sasha,
>
> On Wed, Jan 21, 2009 at 6:41 AM, Alexander Berezhnoy
> <alexander.berezh...@gmail.com> wrote:
>> Hi Andres!
>>
>> 2009/1/21 Andres Riancho <andres.rian...@gmail.com>:
>>> List,
>>>
>>> I've created a task in the TODO list for v1.0 some time ago, that
>>> basically says [0]:
>>>
>>> """I should separate discovery plugins into two different types:
>>>
>>> - The ones that find new URLs
>>> - The ones that find things about the site"""
>>>
>>> A clear example of a plugin that finds new URLs is the webSpider,
>>> and a clear example of a plugin that "finds things about the site" is
>>> the hmap plugin, which fingerprints the remote webserver. I've been
>>> thinking, and I'm pretty sure that w3af is going to have a plugin
>>> family called "crawl" for the plugins that "look like webSpider",
>>> but... I'm not sure how to call the other plugin family. Anybody has
>>> ideas? Please share =)
>>
>> Would not be reasonable then, to join the "grep" plugins with the
>> second new type ("The ones that find things about the site")
>
> No, because grep is passive and this new type is completely active.
> They do the work in different ways.
>
>> I'm agree with Steve that finding URL's and crawling them could be an
>> other task for the split.
>
> What about what I said about plugins that are run more than once, with
> different input, and always return the same result?
Ok, let's consider all the properties a plugin can have, like
- Active/passive
- Audit phase
- Run once / Run always
- Intention:
- find something in existing data
- initiate new requests
- generate probes
- What parts of kernel and kb are used?
etc...
Then we could try to find a suitable classification.
As for me, I'm happy with the existing one. What is the purpose of the
new classification:
1) Make usage more easy and intuitive
2) Make development more convenient
3) Any long-term plans for refactoring?
Sasha.
///////
>
>> I think, we need to publish a complete plugin list and discuss their
>> classification. Probably, the same plugin could be dedicated to the
>> several groups.
>
> I disagree with the fact of having a plugin in more than one category.
> It would be a mess for the final user, and a mess in the core
> implementation.
>
>> Sasha.
>>
>> ///////
>>
>>>
>>> [0]
>>> https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=147178&group_id=170274&group_project_id=48542
>>>
>>> Cheers,
>>> --
>>> Andres Riancho
>>> http://w3af.sourceforge.net/
>>> Web Application Attack and Audit Framework
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by:
>>> SourcForge Community
>>> SourceForge wants to tell your story.
>>> http://p.sf.net/sfu/sf-spreadtheword
>>> _______________________________________________
>>> W3af-develop mailing list
>>> W3af-develop@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/w3af-develop
>>>
>>
>>
>>
>> --
>> Alexander (Sasha) Berezhnoy
>> http://sandals-on-my-head.blogspot.com
>>
>
>
>
> --
> Andres Riancho
> http://w3af.sourceforge.net/
> Web Application Attack and Audit Framework
>
--
Alexander (Sasha) Berezhnoy
http://sandals-on-my-head.blogspot.com
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
W3af-develop mailing list
W3af-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/w3af-develop
