[Owasp-webscarab] Design assistance required

[Rogan Dawes]

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 authenticated, 
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 variables 
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" conversations. 
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 manually, 
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 alternatively-encoded 
versions. This is effectively the Transcoder, but immediately accessible 
so you don't have to do so much copy and pasting.

Summary
=======

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 WebScarab-NG 
<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!

Rogan