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"
