Proposal for a VulnXML web interface (VXWI)
From: http://www.owasp.org/vulnxml/proposal.txt

Author:   Ingo Struck
Mailto:   ingo@ingostruck.de
Date:     2002-09-19
Revision: draft

1. preface

The VulnXML web interface is a tool necessary to manage
the well-regulated growth of the VulnXML (static) web attack
data base. It enables the webapp sec community to contribute
to the VulnXML db (VXDB) and the OWASP staff to coordinate,
edit and approve the upcoming and changed entries.

2. user profiles

The application is expected to cope with three types of users:
  i) webappsec community member (CM)
ii) OWASP vulnxml editor       (ED)
iii) OWASP vulnxml admin        (OA)

For each user a typical workflow of the VXWI use is modelled.

  i) A CM primarily wants to get a list of static security
	   checks applicable to a class of web applications.
		 If a CM has got more experience than the average user, he
		 may want to add additional checks that he discovered.
		 Thus a CM may
		 - browse through the published VulnXML db
		 - filter the published VulnXML against special constraints
		 - download the VulnXML db as whole or partially according
		   to the constraints used
		 - add some proposals for checks that are not yet contained
		   in the db

ii) An ED usually reviews the incoming proposals, tries to match
     them against existing entries to drop duplicate entries and
		 checks the proposal for conformance to the syntactic and
		 semantic VulnXML demands. He may want to:
		 - update / review existing entries
		 - review and format upcoming entries
		 - match new and existing entries for certain criteria
		 - merge some entries
		 - approve reviewed entries
		 - import batches of entries from other static check db formats

iii) An OA has to be able to publish a new VulnXML db release
     officially. He may need to do some auxiliary administration
		 concerning the users known to the VXWI.
		 An OA may need to
		 - add and remove registered users and adapt the access rights
		 - approve reviewed entries for publishing
		 - "remove" obsolete entries

As a matter of course all the functions are cumulative, i.e.
an ED can do everything what a CM is allowed to and an OA can do
everything what CMs and EDs can do.


3. user structure

The user structure for the VXWI is quite simple.
What is needed basically is the attribute set
[uid,passworddigest,email,role]
For convenience this may be augmented by the
attributes [firstname,surname,orgname] to simplify
the generation of the copyright entries.
To enable a good integration into the OWASP portal
the user structure and database will be agreed upon
among the OWASP portal and the VXWI developers.



4. vuln xml db

The vuln xml db will perspectively contain a small to middle
number of entries (5000 to 50000). Therefore the underlying
db is not necessarily required to be of very high performance.
For an easy integration of the XML data structures and the
sake of adaptability (the VulnXML format can well be expected
to change massively within the next two years due to its early
stage of usage) it is recommended to build the data base upon
the toolkit JAXME. If more performance is needed in a stage of
maturity than the XML db could be converted to something more
powerful like openisis or something similar. A simple textual /
plain text db is adequate for the VulnXML structures anyway.
The vuln xml db should work history based, i.e. no entry will
be deleted but a copy of each published release will be kept.
If someone "modifies" a published release of an entry, a copy
with a higher revision number will be created and marked as
"reviewed." The new entry must undergo the approval process
before it is marked as published.

5. web interface

For reasons of portability, ease of use and performance the
VXWI will be built using plain vanilla JSP / servlets without
any further framework. The non-anonymous connections will be
done via SSL. A necessary prerequisite for access control and
some of the proposed features is a stateful (i.e. session based)
VXWI.


6. forms to be used (with necessary access level in parentheses)

a) entry browser (anonymous)

This form provides a short list view of VXDB entries, modelled
quite like a sourceforge tracker list.
The head will contain some standard filter criteria as well as
some rudimentary sort functions.
The list view contains

[id,date,class,author,platform,webapp]

Maybe one should consider to split "platform" to "platform,os"
as the VulnXML DTD implies.
The user will be able to view a list sorted by one of the
displayed attributes as well as to download an excerpt from the
vulnxml db according to the filters set.
It has to be worked out, if "unreleased" records should be
filtered out for download/view generally or not.
If so, the anon/CM user could only access "released" entries.
If not, one should consider to add a "maturity level" filter
that could be denoted by the background color of each entry
(like the priority color of the SF tracker).
The filters can be set against any number of the attributes.
Each filter list contains any of the values available for that
attribute.


b) entry detail (anonymous)

The entry detail view form contains a complete VulnXML record.
It will be processed through an XSL filter for display.
References will be rendered as Hyperlinks if possible.
Optionally the entry detail provides some feedback form
that can only accessed by a CM who logged in and will be used
to gather additional information considering that entry and
will be made available to EDs.


c) entry proposal (CM)

The entry proposal form provides an input for a complete VulnXML
entry, except for versioning and release attributes.
The main problem here is to render a good solution for the
multiple attributes, especially the specific description of the
attack (connects etc.)
The best idea here would be a "self-expanding-list" with a blank
input module for each repetitive attribute. Each "add" to such
an input module would not submit the new VulnXML record as a whole
but loop to the input form with a list of the formerly added attrs.


d) edit queue (ED)

The edit queue is a specialized entry browser with a filter for the
"maturity level" set to "proposed|rejected*". This attribute should
remain an internal attribute within the VulnXML db and always
filtered out on external (DTD conformant) VulnXML exports.
Each entry of the edit queue provides a link to the edit form.


e) approval queue (OA)

The approval queue is modelled quite like the edit queue.
The filter is set to "maturity=reviewed|approved".
Since it is always a good idea to have anything triple-checked,
an entry should be published only if at least to OAs approved
it. The mechanism for this should go like this:
maturity: proposed->reviewed->approved-{uid}->published.
If an OA approves an entry that already has been approved by
someone else, it will be rendered "published".
Each entry of the approval queue will provide the two actions
"approve" and "reject". The "rejected" state as well as the
"approved" state will be suffixed with the uid such that the
other EDs and OAs notice who approved / rejected the entries.


f) entry editor (ED)

The entry editor will be built quite similar to the proposal (b)
but will make accessible every VulnXML entry attribute.
The same mask can be used either in an edit or a search mode,
such that the editor can access a record according to an attribute
based full-text search. The search mode should provide a simple
"star" (*) expansion mode.
The form will contain a [search|clear] link for each attribute
and the whole entry. If a search result is ambigous, the edit
queue (d) will be displayed, filtered according to the search
criteria.
Using this technique an ED can fetch an upcoming entry into the
entry editor, and subsequently broaden the search for similar
entries iteratively.
The form will a save and approve link for any entry with a
status lower than published.


g) batch upload (ED)

The batch upload form contains a simple upload form where the
editor can upload some data files that contain checks in other
(known) formats. The batch will be converted on the server-side
to "upcoming" records. A report of success / failure of the
import containing a list of the successfully imported / failed
foreign format entries will be generated after each upload.


h) dumb download (anonymous)

The download form will provide some standard links to
well-defined subsets of the vuln db:
- approved release (only latest, published entries)
- approved complete release (all published revisions)
- beta release (all latest entries)
- full version (all entries)
The form will designed in such a way that the average user
understands that the approved release is the "official" OWASP
trusted and branded version.


i) to ?) all user management forms

...will be designed in accordance to the user management system
that is established for the whole OWASP portal.


7. issues

- The concept of a history based db model implies that no records
  can be removed from published status once they got there.
  It should be worked out, whether the "delete" function should be
	established or not.
	(istr)

- ADD YOUR OWN ISSUES HERE, MARKED WITH YOUR PERSONAL TOKEN
DR>  David Raphael (DR):

DR>  Regarding User DB and Structure - I vision the Portal to
DR>  provide some type of generic authentication interface.  I would
DR>  love to implement an LDAP based profile/authentication management,
DR>  with some kind of XML coupling.  This would allow a consolidation
DR>  of user info for the various 'portlets/feeds' or whatever resources
DR>  are being tapped.

DR>  something like this:

DR>	First Name
DR> 	Last Name
DR>	username
DR>	email
DR>	Company/Organization
DR>	password digest
DR>	[demographics]
DR>	profiles[]
DR>		VulnXML - [role, enabled, etc...] <-- This would be
DR>		manipulated through the basic site framework from
DR>		the VulnXML app.
DR>
DR>		WebScarab
DR>		news...
DR>		etc...

DR>  Being LDAP, this should provide a lightweight service for user
DR>  management while keeping the burden of user info on the Portal side.
DR>  The Portal will also provide the necessary authentication service.
DR>  The authentication implementation can then be implementation
DR>  transparent to the other services - ie VulnXML. We can provide a
DR>  global (OWASP Portal-wide) authentication / user administration
DR>  logic.

DR>  Please give me your thoughts on this.  I know this may be a little
DR>  off topic, but it seemed like a good time to start getting some
DR>  feedback on the user info management structure for the Portal.




==== end of doc ===