[OWASP-TESTING] WAVA vs Pentest
stephen.venter at gmail.com
Fri Jun 24 04:41:08 EDT 2005
When I raised this point before, I didn't get much in the way of
responses. Perhaps you all might take a moment now to comment on or
discuss these suggestions of mine?
I also refer you to:
Basically I am proposing that it could be better to use the term
Application Vulnerability Assessment (AVA), or in this specific case:
Web Application Vulnerability Assessment (WAVA), instead of the term
So we'd call the guide the "OWASP Guide to Web Application
Vulnerability Assessments" instead of the "OWASP Guide to Web
Application Penetration Testing", and within the guide we'd use
headings like (see: the template1.htm published with the latest
- Anonymous or Unauthenticated user perspective [short version: Anonymous]
- Authenticated or logged in user perspective [short: Authenticated]
- Auditor or Full access perspective [short: Auditor]
- Black Box; and
- White Box
Some motivations for these ideas, including:
1. I find that customer non-technical executives understand the term
"Vulnerability Assessment" better than "Pentest"
2. Pentest has more connotations of a negative nature, or associations
with terms like "hacking" and "trying to break the system", whereas
"Vulnerability Assessments" is a term that seems convey more positive
ideas like what we're really trying to do here: i.e. help identify
weaknesses so they can be resolved effectively.
3. Also, terms like "Anonymous", "Authenticated" and "Auditor" are
understood better by non-technical people than the terms "Black Box"
and "White box"
Also, following on from this, there would obviously be a need to
explain the terms within the Testing guide introduction / overview
Also, I feel that the template1.htm (published with the latest
"Testing_Guide_II_structure.doc") could be updated to include the
How to Test -> Anonymous perspective; Authenticated perspective; and
instead of currently: How to Test -> Black Box; and White Box
Also, the "Short Description of Issue" section could include a "Short
statement with reference to Anonymous, Authenticated and Auditor
perspectives" after the basic outline of the issue - for example an
SQL Injection issue identified in an ASP page that you cannot access
unless you have successfully authenticated, then the issue (as well as
the remediation measure) are not applicable for the anonymous user
perspective [but it does expose the system to serious risk with
respect to authenticated users].
Also, couldn't there perhaps be another section like "Short
description of the remediation options", e.g. input validation
controls to be build into the application, or an application firewall
/ filter, or better password complexity checking, or things like that?
Perhaps this section could also consider the differences between
Anonymous, Authenticated and Auditor perspectives – e.g. when testing
for SQL Injection in an ASP page that you cannot access unless you are
authenticated, then the issue as well as the remediation measure are
not applicable for the anonymous user perspective, but if the SQL
injection occurs in the login screen / page of the app, then it places
the system and organisation at risk from anonymous users.
More information about the Owasp-testing