Difference between revisions of "Section 1: Introduction"

Revision as of 06:28, 26 October 2008

Background

ModSecurity is an open source web application firewall that can work either embedded in an Apache web server or as a reverse proxy. The new features in version 2.0 and version 2.5 (released in February 2008) allow for a highly configurable capability that can address vulnerabilities (e.g. discovered during black-box penetration testing) on a per-application basis. ModSecurity provides for free a broad set of generic Core Rulesets that cover areas such as protocol compliance, malicious client software detection, XML protection, error detection, and generic attack detection ("Detect application level attacks such as described in the OWASP top 10"). However, the Core Set rule documentation (see README in modsecurity-core-rules_2.5-1.6.0.tar.gz) cautions that since attackers may examine the freely-available core rules to get around them, some core rules should be viewed more as a "nuisance reduction" mechanism instead of a security mechanism.

The lessons in WebGoat 5.2 detail over 30 different types of attacks on the WebGoat application (see the WebGoat v5 User & Install Guide).

Purpose

The purpose of this project is to create custom ModSecurity rulesets that, in addition to the Core Set, will protect WebGoat 5.2 Standard Release from as many of its vulnerabilities as possible (the goal is 90%) without changing one line of source code. To ensure that it will be a complete 'no touch' on WebGoat and its environment, ModSecurity 2.5.5 will be configured on Apache server as a remote proxy server.

For those vulnerabilities that cannot be prevented (partially or not at all), I will document my efforts in attempting to protect them. Business logic vulnerabilities will be particularly challenging to solve.

The opportunity, challenges, issues or need this project addresses:

• Provides application-level protection for those web applications that cannot be touched
• New custom rulesets can be added as new attack types are discovered
• This solution is programming language and platform agnostic
• With outside help from consultants, this solution can be used by companies that have zero knowledge of software security
• A possible unintended side-effect: introduce software security awareness into an organization, which may lead to software security development lifecycle practices for future projects
• Common types of business logic vulnerabilities (this will be a challenge)

Tasks and deliverables

• Set up and test the development environment. The initial Reverse Proxy server OS will be Kubuntu 7.10.

• Identify WebGoat vulnerabilities and exploitation methods. Publish to wiki for review, feedback, and modification.

• Develop rulesets for 50% of the vulnerabilities, starting with the low-hanging fruit. Deliver user documentation. Publish progress to wiki as each vulnerability is addressed.

• Peer review, feedback, modification at 50% project completion (Milestone 1)

• Develop rulesets for the 2nd 50% of the vulnerabilities. Publish progress to wiki as each vulnerability is addressed.

• Test final rulesets and ModSecurity Reverse Proxy on two other Linux distros.

• Produce final rulesets and documentation.

• Peer review, feedback, modification, deliver final product (Project completion)

Future development and long-term vision

(TBD - depends on feedback from the project reviewers and anybody else)

Contributors

Project team: Stephen Evans

1st reviewer: Ivan Ristic (Curriculum) & Breach Research Labs (Ryan Barnett, Brian Rectanus)

2nd reviewer: Christian Folini (Curriculum)

Special thanks go out to the reviewers for graciously volunteering their time for this project.

Other contributors:

• Dinis Cruz, who sculpted the original project proposal into something useful.
• Paulo Coimbra, who exhibits extreme patience in his dealings with the project team.
• Bruce Mayhew of the OWASP WebGoat project.