[Owasp-webscarab] Design assistance required

[Rogan Dawes]

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)

Thanks,

Rogan

> 
>> -----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 
>> 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
>> _______________________________________________
>> Owasp-webscarab mailing list
>> Owasp-webscarab at lists.owasp.org
>> http://lists.owasp.org/mailman/listinfo/owasp-webscarab
>>
>