From:	 "Mark Curphey" <mark@curphey.com>
To:	 "bugtraq" <bugtraq@securityfocus.com>,
	 <webappsec@securityfocus.com>
Subject: Announcement : The Open Web Application Security Project
Date:	 Sun, 25 Nov 2001 23:45:51 -0800
Cc:	 <cwysopal@atstake.com>, <jblumen@xmission.com>,
	 <viega@securesw.com>, <greg@clicktosecure.com>,
	 <aleph1@securityfocus.com>, <bob@owasp.org>, <kevin@owasp.org>,
	 <bill@owasp.org>, <dwg@owasp.org>

We are extremely pleased to finally officially launch OWASP, the "Open Web
Application Security Project". For those that have been following the site
http://www.owasp.org or are on the webappsec@securityfocus mailing list for
the last 8 weeks you'll be a part of the 250,000 plus web hits, and this
will be nothing new; but given our new technical committee it made sense to
re-launch the efforts with some basic work already done.

That technical committee consists of some of the brightest minds in
application security including John Viega, Chris Wysopal, Greg Hoglund and
Elias Levy.

In short the project aims to help everyone build more secure web
applications and web services. We will be covering a wide range of related
work over the coming years and have initially defined two areas to
concentrate on. A schedule of work can be found at
http://www.owasp.org/projects/schedule.shtml

Attack Components - The Application Security Attack Components project was
started as an attempt to create common language and definitions for which
much of the other work planned at OWASP can later benefit. When describing
security issues in web applications or when attempting to model security it
is very easy to describe the same issue in many different ways, seemingly
creating new problems. When analyzing problems described on Bugtraq it is
evident that most problems are variants of common issues, but applied to
different applications or systems using different parameters or targets. The
aim is definitely not to build the biggest list of problems or describe
attacks like Nimda or Code Red; but to document the underlying primary
attack components that are used in attacks so people can learn to avoid
developing them and others can learn to test for them.

We have a good initial start although focused on mainly external attack
black-box type issues. The current list can be found at
http://www.owasp.org/projects/asac/. With our new team we hope to flesh out
this list to include internal "with knowledge" attacks as well as
cryptographic issues and any other classes we need to include. The work is
scheduled to take place in December of this year and will set a good
foundation for the Testing Framework.

Testing Framework - As with any emerging technology like web application
security where there is a lack of documented knowledge and experience, it is
hard to know how to be sure that security has been implemented correctly;
protecting the application, the data and the user. As in the early days of
network security some people would have you believe application security is
a black art. If you ask a security vendor to conduct an application security
review today, it could consist of anything from a consultant pressing "scan
now" on an automated tool designed to find holes in operating systems, to a
full blown line by line code review. What is the correct way to test
security of web applications and web services? The Web Application Security
Testing Framework is setting out to produce an industry standard blueprint
for how to methodically test the security of all web applications and web
services. The work is likely to include modeling security attacks (maybe in
XML) and is likely to use "Attack Trees" to define paths of attack. The
framework will be open to all and will be extensible to be able to be used
in all web applications scenarios. It will discuss the difference between
white-box testing and black box testing, describe tool and techniques as
well as describe how to conduct tests, analyze results, fix problems and
report findings. The framework will help everyone build more secure web
applications and web services. One ultimate goal that has been put forward
is to also produce a web service where all users can download sets of known
or experimental attacks (and possibly build them online) for import into
reference tools either developed by the project or commercial tools. The
specifications would be published and made freely available. The web service
effectively would de-couple the current situation where commercial tools
have both knowledge and techniques, thus making the security knowledge
available to everyone and the tools stand on the merit of the tools
themselves. This idea will depend on funding, probably from the government.

We will also be building some open source tools to support the Testing
Framework and an early release of WebSleuth is available from
http://www.owasp.org/resources/tools/. It is not intended to replace or
compete with commercial tools, and there is certainly no shiny red-button
automating attacks. However it is an investigative learning tool that with
some patience and knowledge, helps you to find and learn about issues you
may have in your web applications. It was written in Visual Basic to take
advantage of the MS Internet Explorer object avoiding the need for a reverse
proxy. It currently only runs on Win32 and should be seen as proof of
concept. Please save us all the bandwidth and only download the installer
package if you don't have the VB dll's. A new release this week will allow
the tool to test for cross-site scripting in all user input to web
applications. It works over SSL without the need for a proxy.

A special thanks to Kevin Jeong, Dave Zimmer and Dennis Groves for their
amazing hard-work !

http://www.owasp.org

Kind regards,

owasp@owasp.org

"Building Blueprints to Secure Web Applications"