[Owasp-webscarab] Design assistance required
lists at dawes.za.net
Thu Aug 17 04:00:19 EDT 2006
Steve Lang wrote:
> Hi Rogan.
> From what you have described, and what I see in the screenshot that you
> have, it looks damn good to me.
I just want to make it clear:
What I have described below is what I am thinking of doing. What I have
done so far (i.e. the screenshot) is nowhere near that in functionality,
and is going to need a significant rewrite to get to what I have described.
So, what I REALLY need from people is storyboards describing workflow
(need a screen showing this, this and this, and I can click on this and
do that, and right click on that and do this, etc)
>> -----Original Message-----
>> From: owasp-webscarab-bounces at lists.owasp.org
>> [mailto:owasp-webscarab-bounces at lists.owasp.org] On Behalf Of
>> Rogan Dawes
>> Sent: Wednesday, 16 August 2006 7:53 p.m.
>> To: owasp-webscarab at lists.owasp.org
>> Subject: [Owasp-webscarab] Design assistance required
>> Hi folks,
>> Even though I have been working on WebScarab-NG for a few months
>> already, I am now looking at redesigning it ;-) And to do that
>> successfully, I need your help.
>> Lots of people complain that the existing WebScarab is non-intuitive.
>> The features/plugins are pretty much isolated from each other, and do
>> not make an integrated tool. So, I am looking for suggestions
>> on how to
>> improve this situation.
>> At this stage, I am aiming for conceptual descriptions of how it will
>> work. Let me give my suggestions, followed by the places
>> where I need help:
>> I am thinking of having two major areas of focus, namely interactive
>> testing and automated testing.
>> Interactive testing
>> This area would cover things like the intercepting proxy, as well as
>> manually creating or editing and replaying requests. The WebServices
>> plugin would probably fit well in this area too, since it is
>> simply an
>> "assisted" manual request. I also plan to have a module that shows
>> detected forms (parsed from observed HTML), and allows you to
>> fill them,
>> submit them, and observe the results. Again, this would probably
>> classify as "assisted" manual request, I guess.
>> I anticipate having a unified conversation list for conversations
>> resulting from these modules, which could be reviewed, annotated,
>> replayed, etc. There would be a table column indicating the source of
>> the conversation, much as we see now in the original WebScarab.
>> Automated testing
>> This area would cover things like the spider, automated checking for
>> backups/zips of files/directories, automated checking for directory
>> index pages, the fuzzer, automated checks for Cross Site Scripting or
>> Header injection, and any other automated testing (Nikto-style,
>> perhaps?), SQL injection brute forcing, OPTIONS testing, etc
>> I anticipate having individual conversation lists for each of these
>> modules, possibly filtered by batches (e.g. the most recent fuzz
>> results). Alternatively, it may make sense to have a unified list of
>> automated conversations, filterable by module, and batch?
>> Common functions
>> All conversation lists would have common functionality:
>> Search - The ability to reduce the number of visible
>> conversations based
>> on certain criteria. These criteria may be a simple iTunes-like text
>> filter, or it may be as complex as a BeanShell script (as
>> exists in the
>> current WebScarab)
>> Compare - shows the degree of similarity between an indicated "basis"
>> conversation, and the other conversations in the list. This
>> will allow
>> you to identify "interesting" conversations amongst a group of mainly
>> identical responses. This is most useful in a fuzzing
>> situation, I guess.
>> Authorisation detection/tagging - The idea here is to annotate
>> conversations with information about the user or role that the
>> conversation was executed under. By identifying (manually
>> initially, by
>> rule eventually) "transition points" where a session is
>> timed out, etc, we can indicate what user/role was in force when a
>> particular conversation occurred. This should be useful to highlight
>> access to information by anonymous users, access to sensitive
>> information by less-privileged users, etc. I expect that we should be
>> able to handle HTTP authentication, session cookies, and form
>> without too much difficulty. One thing this might be used for is to
>> construct an "access matrix", showing what "functions" each user
>> accessed, and whether that access was successful or not.
>> Marking bogus conversations - one unfortunate result from
>> automated (as
>> well as manual) testing, is the introduction of "bogus"
>> This is most prevalent when the server returns "friendly"
>> error messages
>> - i.e. "200 Not found", instead of "404 Not found". It would
>> be useful
>> to be able to either detect these automatically, or mark them
>> so that they would not be considered by some of the other plugins, or
>> not clutter up the conversation lists.
>> Marking findings - Ultimately, what WebScarab is intended to do is
>> support a user in finding vulnerabilities. These vulnerabilities
>> manifest themselves in (sequences of) conversations, which
>> comprise the
>> evidence of the vulnerability. This feature will allow the user to
>> aggregate conversations into a finding, as well as describe
>> the nature
>> of the finding. This will then be able to be reported on, or
>> reviewed, etc.
>> User interface elements
>> I plan to have right-click menus for all editable text fields
>> which will
>> allow the user to replace the selected text with
>> versions. This is effectively the Transcoder, but immediately
>> so you don't have to do so much copy and pasting.
>> So, that was a fairly random brain dump of functionality that is
>> eventually planned for Webscarab. What I'd love to get back
>> from you all
>> is commentary on whether this looks like functionality that would be
>> useful in your testing, how you would like to see it
>> presented (UI), etc.
>> You may have seen the screenshot of the current version of
>> <http://dawes.za.net/rogan/webscarab/ws-ng.png>. Does this
>> look like a
>> good interface? What would you like to see? If you could make
>> mockups of
>> the desired interfaces, that would be most excellent, but even just
>> descriptions of how you would like it to work would be valuable.
>> If you are interested in adding functionality to WebScarab yourself,
>> tell me what functions you'd need in order to do so.
>> At this stage, I am considering a ground-up rewrite (even abandoning
>> most of the existing WS-NG), so now is the time. ANYTHING
>> goes. Let me
>> have it!
>> Owasp-webscarab mailing list
>> Owasp-webscarab at lists.owasp.org
More information about the Owasp-webscarab