[Owasp-testing] Documented workflows
kingthorin at hotmail.com
Thu Apr 26 15:41:48 UTC 2012
I agree with Kevin on this.
In broad strokes I normally explain to process to
co-workers and clients as:
1) Recon - Surf the app (both automated and manual) [read
any user docs that may be available]. In order to find all the
pages/functionality to be tested. (Check xssed.com, etc)
2) Identification - Automated VA (AppScan, Burp Active,
Hailstorm, SkipFish, whatever).
3) Vulnerability Analysis - Manually validate the
automated results, see if you can turn them into interesting things (beyond
alert(1), LFI of win.ini, and SQL errors, etc). Browse through some passive assessment proxies (Fiddler, RatProxy, Burp, etc).
4) Penetration Testing/Business Logic Testing - Can you
push any of the identified issues any further? Command injection? Remote
shells (web shells)? Etc Are there business logic flaws? Can fictional Peter see fictional Joe's accounts/docs. Can I buy products for negative values, etc. JSON or XML data leaks, did they send me more than I actually get to see. Hidden functionality (style=display:none, did they hide things from me instead of actually just not including them in a page, etc). Is CSRF possible (Active scanners try to check for this but aren't "really" good at it. Check manually.) etc etc
That's the basic model I use and explain. Obviously it's not totally linear/chrono, I may loop back around through any step(s) as items are identified or new content/functionality is exposed.
From: owasp-testing-bounces at lists.owasp.org
[mailto:owasp-testing-bounces at lists.owasp.org] On Behalf Of Kevin Horvath
Sent: April 26, 2012 10:40 AM
To: Jonathan Cran
Cc: crib bar; owasp-testing at lists.owasp.org; Owasp asvs
Subject: Re: [Owasp-testing] [OWASP ASVS] Documented workflows
There really isn't a set specific procedure as each
owasp testing guide is to give you general guidance on
what should be tested and how it can be tested. A lot of testers have
their own methodology but at very high level I would
the following first,
Understand the application (purpose and functionality).
- Walk the application with a proxy at each user level
(unauthenticated all the way through all access
roles). This is
important to understand things such as session handling,
redirects, error handling, functionality at each level,
-Spider the app at each level to map it out
Once you have an understanding of the application and the
scope of it
then you can proceed to test things such as input
and with a scanner), session management, business logic,
ciphers, etc, etc.
Much of these can be tested without any
predetermined order usually but you definitely need to do
step mentioned above.
A lot this comes with experience of knowing
what to test first depending on what you see during your
walk of the
first step is critical when it comes to trying this
such as vertical and horizontal privilege escalation,
On Thu, Apr 26, 2012 at 9:56 AM, Jonathan Cran
<jcran at 0x0e.org> wrote:
> On Thu, Apr 26, 2012 at 8:07 AM, crib bar
<crib.bar at hotmail.co.uk> wrote:
>> Does anyone have any sort of documented workflow
on the steps you take
>> when performing a web application assessment. I
know often it's a
>> combination of tools and manual assessments when
performing the audit, but
>> there must be some sort of logical workflow you
follow when doing an audit,
>> i.e. 1) do this first .. 20) wrap up testing and
write the report.
> Isn't this the OWASP testing guide?
> Owasp-testing mailing list
> Owasp-testing at lists.owasp.org
Owasp-testing mailing list
Owasp-testing at lists.owasp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-testing