|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
From: Mark Curphey (mark
curphey.com)Date: Tue Jan 08 2002 - 00:11:20 CST
The Security Testing Framework is setting out to define a structured
framework to ensure that the appropriate security requirements have been
implemented by a web application. By providing a structured community
derived methodology covering both "white box" (source code analysis) and
"black box" (penetration test) analysis we hope to be able to improve the
quality of security testing for all web applications. Eventually this
project will also develop open source tools to support the actual testing.
To an extent this project should be the post-runner to the requirements
project also now underway, but as time is of the essence it seemed sensible
to start. If we get a significant amount of the content authored, then we
can retro fit it to work with the requirements at a later stage. We want to
seek widespread adoption of the framework, and are driving towards an
official standards body. This work will be able to be used by a variety of
people; from security professionals looking to adopt an industry derived and
proven methodology,through to system owners looking to conduct tests
themselves or seeking to ensure their consultants are comprehensively
checking their applications.
So exactly what should be included in a testing framework ? Well it seems
like thats the obvious starting point. We have taken some basic ideas and
put them into a table of contents on the site.
http://www.owasp.prg/projects/testing/
They cover the following sections.
What to Test ?
How to Test ?
Types of Tools?
Testing Specific Problems
Analyzing Results
Reporting
Clearly a large part of this work will be detailed technical descriptions of
how you check for specific problems like cross site scripting or buffer
overflows. Those descriptions will likely include some of the other work
like attack trees. A description for testing CSS for instance would include
an attack tree that describes how to find all CSS injection points, how to
systematically push CSS payloads into applications and what to watch for as
a result.
When we have a good outline for what should and shouldn't be included in the
framework, we will be developing a schedule of work over the next 6 months.
We will devote specific time periods for debate of specific topic on the
mailing list, which will be captured and written up by volunteers. An
editorial page like that for the ASAC project will be available to keep
track of drafts.
This project will take place predominantly on the mailing list and we will
be asking for volunteers to author write-ups like the ASAC project. I know
there are lots of really smart people who do web application testing for a
living so I am sure this is going to be a great piece project.
Check out the site http://www.owasp.prg/projects/testing/ and look for the
"So What Should Be in a Testing Framework ?" email next. Start contributing
with your thoughts now.
Cheers
mark
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]