[OWASP-TESTING] Paper review

Nick Randolph randolph at seawa.org.au
Tue Dec 3 23:29:38 EST 2002

David and others

Firstly I would like to apologise for not having taken an active role in this project until now.  I have however just looked at the latest release and it appears to be very impressive.

A couple of initial comments:

1)	Coming from a software engineering background (rather than a purely testing and/or security background) one of the areas that we focus on is the integration of testing into product development.  In line with most Agile product development methodologies we believe that testing should be done in parallel (if not before - ie preparation of test cases) with product development.  From what I have read to date, it appears as if there is a focus on post-development security testing.  In fact, to quote (pg 17 - Implementation review) - "An implementation review assumes the tester actually has a "finished" web application/component/service to use as his 'target'".  Whether this was the intention or not, it conveys the message that this should be done after the development has been completed.

2)	The section titled "Implementation Review" is essentially where the actual testing is done.  Is the word "review" appropriate.  Development life cycles typically follow the requirements-design-build-test cycle (even with the Agile methodologies that use micro cycles).  Would it not be appropriate to have a similar flow eg.  Application review (determines testing requirements), Test design and planning (develops Test plan), Test execution (equivalent to Implementation review) and Results Analysis.

3)	The section entitles "Security Management Review" is really a review of the processes in place within the organisation to ensure security is maintained and improved over time.  It might be better to reflect this in the title with some mention of Process Improvement (countless Quality/Process standards can be quoted here!!)


-----Original Message-----
From: zeno [mailto:zeno at cgisecurity.net]
Sent: Wednesday, 4 December 2002 8:54 AM
To: David Endler
Cc: 'owasp-testing at lists.sourceforge.net'
Subject: [OWASP-TESTING] Paper review


"Regulatory requirements"

You wanted some examples of country regulations. Why don't we mention crypto export limitations?
Great example that should be covered. Maybe something about the bill passed in the 1990's about
illegal export of strong encryption outside the USA bla bla bla .

Moving on (nice graphs BTW :p)

The image looks fine near the Intro to owaps testing methodology. Anyone else object?

Interviewing the stakeholders is a nice touch.

*maybe* have a flowchart containing "Obtaining documentation".
 People like perty easy to understand pictures :)

 Under obtaining source code perhaps mention that gaining sourcecode via blackboxing may be possible.
A simple example could be exploiting a perl script and having it load itself bah.pl?file=../bah.pl.
This can happen with other interprated languages also like ASP, perl, python, etc..
Nothing to talk to much in detail though.

Under preparing tools in that list maybe we should mention something in regards to checking
for permissions of files? File handle monitors seems broad like "I am monitoring what is used" but
doesn't immediatly ring the bell of "should check permissions in regards to local, roaming, and public(everyone) users.

Under listening http ports

You give tips for checking ports 80 and 443. Perhaps mention 8080 since it usually is a proxy port,
or alt webserver port. Perhaps "test for proxy usage" *maybe*

Under server versioning I would include "http banner order, default error pages, max connections, etc..)
I'm actually working on a NICE big detailed paper on fingerprinting webservers. It will cover manually
and Ihope fr it to be rather extensive. (also see whitehatsec.com blahat server fingerprinter tool)

HTTP Server extensions

Also add apache modulkes to this. Seems a little to IIS'ish to me.

HTTP Methods supported

You ask if we should provide examples on each. Obviously it could be helpful. Perhaps include
HEAD, GET, and POST. As much as I'd like to learn more about TRACE this document is a web security paper
and unless we dedicate
alot of time (like lan mapping/cache networks) perhaps we should limit it to the 3 most popular/used methods.

Old, Backup or un-referenced files

Include that smome editors create files like file.txt~ when being edited. Perhaps include a general "editor" reference.

File extension Handling

It mentions http://www.host.com. May want to do http://host/ for legal reasons? Same with rest of document.

Unsafe modules

Everything from SQL access, usernames/passwords to sections of your site, to paths to important files can be obtained both locally, and in some cases(when specifically allowed) remotely.

perhaps make (when specifically allowed, or misconfigured). People don't say "Hey why don't I misconfigure
my machine for people to hack me with".

Page 38

n this example we are going to send a request to a news application which includes data from other file and displays it.

I assume is

"includes data from another file and displays it"

Direct OS commands

Nice use of showing which functions to watch out for. 

I would also perhaps add more flowcharts or something along those lines. Yeah it sounds silly but
when I'm reading a 60+ page document flowcharts are a nice break and re etterate what I just read.
If I'm sounding like a moron just let me know I'm tired :p

- bob

ps: looks good

This SF.net email is sponsored by: Microsoft Visual Studio.NET 
comprehensive development tool, built to increase your 
productivity. Try a free online hosted session at:
owasp-testing mailing list
owasp-testing at lists.sourceforge.net

More information about the Owasp-testing mailing list