Difference between revisions of "OWASP Browser Security ACID Tests Project"

Revision as of 02:34, 4 March 2011

Main

Welcome!

Welcome to the Browser Security Acid Tests project. OWASP has adopted this project with the goal to create an in-depth suite of test cases for highlighting security issues in web browsers. By highlighting such issues, we can help browser vendors adopt appropriate security controls and implement new security features in a more consistent manner. We can also help raise public awareness about various security issues while providing objective data on the current status of browser security.

The project is under active development. Please take a look at TBD for ways you can contribute.

Purpose

Web browsers are *very* complicated pieces of software. The landscape of functionality provided by modern browsers is pocketed with security concerns, both large and small. This project was started in order to help people get a better understanding of what these issues are while also providing browser vendors a forum to compare strategies, vulnerabilities, and new features.

...

Approach

In order to get a feel for the security landscape of modern browsers, it's essential to be able to create have a wide range of test cases covering both high and low level security issues. In order to keep things as objective (and simple) as possible, we've opted to focus on automation as much as possible. To run these automated tests, a powerful and generic framework is needed that can run in as many browsers as possible. Fortunately, OWASP has adopted the Web Browser Testing System Project, a testing harness originally developed and contributed by Isaac Dawson.

...more details...

Current Status

This project is under active development. We are currently working to establish the scope of the project, adopt a sensible testing framework, and gather support from interested browser vendors.

This roadmap is being developed to help establish project scope, goals, needed contributions, and so forth.

Phase 0: Project Setup

• Adopt testing framework
  • Isaac's WBTS
  • Configure/setup/tweak framework for internal (project contributors) use
  • If we're adopting Isaac's framework, he/we will need to finish the rewrite

• Establish test case generation/submission process
  • figure out how to integrate automated and manual tests
  • clarify what a test case is exactly
  • crowd-sourcing test cases (potentially, if so, we'll need a submission portal)
  • confirm key team members contributors including "tainted" people key reviewers who are vendor neutral
  • crowd-source component (?)

• Clarify categories/scope for test cases
  • ensure separation between funded test case work and unfunded "edge-case" work (e.g. fuzzing tests which qualify for bounty rewards)

• Establish communication policy between project and browser vendors
  • disclosure policy for vulns identified in any given browser

• Establish deliverable output format
  • Presumably a website which the public can visit to run all automated tests and view results of manual tests
  • Clarify what deliverable items funding browser vendors can expect (if any)

• Secure funding
  • Establish website development requirements

Phase 1: Project Work for Basic Test Cases

• Establish test case areas to cover
  • Prioritize these areas

• Develop Test Cases
  • have a meetup for primary contributors to hammer out test cases (potentially)

• Develop website for running test cases and viewing results
  • may include a submission portal

• Execute test cases
  • Disclose failing test cases to appropriate vendors

• Deploy website
  • establish hosting location (say in amazon cloud)
  • domain name

• Complete/deliver any other deliverables to funding entities

Phase 2: Periodic Updates

• Develop new test cases

• Rerun all test cases

• Bug Fixes

• Update Website and Test Cases

• Market website

Get Involved

You can help by...

Proposal to Browser Vendors

Build test cases...

About