OWASP Request for Proposal List
OWASP is currently requesting proposals for all the following OWASP projects.
Please review the details on how to apply. Your proposal is the key factor in deciding whether to award funds - unprofessional applications will not be accepted. The typical project delivery time is 3 months and the payment will be made in two 50% parts (one at the 50% mark and one at 100% mark as judged by an independent reviewer).
You can, of course, submit an unsolicited proposal for any idea that will help OWASP achieve its mission. The requested projects should help you understand the range and depth of projects that are likely to be funded by the OWASP Foundation.
- 1 Global Requirements
- 2 Project Requests
- 2.1 P001 - OWASP Open Threat Modeling Process
- 2.2 P001 - OWASP Dynamic Static Analysis Workbench
- 2.3 P001 - OWASP Application Security Tool Benchmarking Environment
- 2.4 P001 - OWASP Live CD 2008 Project
- 2.5 P001 - OWASP LiveCD Education Project
- 2.6 P001 - OWASP Application Security Training Materials
- 2.7 P001 - OWASP Corporate Application Security Rating Guide
- 2.8 P001 - OWASP Security Facts Label
- 2.9 P001 - OWASP Security Test Case Generation Project
- 2.10 P001 - OWASP Security Test Automation
- 2.11 P001 - OWASP Security Unit Test Framework
- 2.12 P001 - OWASP Client-Side Browser Fingerprint Project
- 2.13 P001 - OWASP CLASP Refresh
- 2.14 P001 - OWASP .NET Refresh
- 2.15 OWASP Site Generator
- 2.16 OWASP Security Refactoring Project
- 2.17 P001 - OWASP BlackTop - Runtime Coverage Analysis Tool
- 2.18 P0001 - OWASP .NET Access Control Tool
- 2.19 P0001 - OWASP AppSensor - Detect and Respond to Attacks from Within the Application
- 2.20 P0001 - OWASP Classic ASP Security Project
- 2.21 P001 - JStatic - Invoking Static Analysis from JUnit Test Cases
- 2.22 P001 - OWASP Server Side Security Scanner
- 2.23 P001 - OWASP Access Control Rules Tester
- 2.24 P001 - OWASP Code Review Browser
- 2.25 P001 - OWASP Attack Surface Metric
- 2.26 P001 - OWASP Positive Disclosure Project
- 2.27 P001 - OWASP Java Sandbox Policy Tool
- 2.28 P001 - OWASP Application Security Verification Standard
- 2.29 P001 -
- 2.30 P001 -
- The project home page must be on the OWASP wiki
- The software baseline for any tools must be hosted at SourceForge or GoogleCode
- Any tools created must be open source, release quality applications, including a GUI and documentation
- All documentation produced must be hosted on the OWASP wiki, and will be available for anyone to update
P001 - OWASP Open Threat Modeling Process
- Project description: Document an approach to threat modeling that is simple, consistent, and reproduceable. The documentation should make it possible for a developer to create a threat model and begin to identify risks. While some level of expertise in application security is required to identify risks, the approach should allow anyone to gather all the relevant information, organize it, and prepare for an expert's participation.
- The approach should make it possible for risks to be identified by starting with threat agents (Microsoft approach), or by starting from business impacts and working backwards (threat/attack trees). The approach should also allow for a security controls oriented approach (like NIST 800-53).
- The project could include an open threat modeling tool like Microsoft's but not so cumbersome. A visual threat modeling approach is greatly preferred to spreadsheet or quantitative approachs.
- The project should build on the information in the OWASP Application Security Desk Reference.
P001 - OWASP Dynamic Static Analysis Workbench
- Project description: Dynamic static analysis – the idea here is that the analyst *interacts* with the tool, telling it where validation, access control, etc… are located. The tool has to dynamically (fast) adjust and recalculate its results. This would allow the analyst to visually “see” where the security mechanisms live, as well as graphically move them to where they belong on the threat model. Then they can isolate certain mechanisms and validate that they’re correct.
P001 - OWASP Application Security Tool Benchmarking Environment
- Project description: OWASP's SiteGenerator is a good start towards generating a sample application containing vulnerabilities. But we need more and better tools to evaluate the performance of security tools. A tool that could generate source code for a working application would be very useful for evaluating static analysis tools.
- The project must produce an open source, release quality application, including a GUI and documentation.
- The tool
P001 - OWASP Live CD 2008 Project
- Project description: Create the next version of 'OWASP Live CD' to contain a useful supply of working tools and documents.
- The project must produce an open source, release quality application, including a GUI and documentation.
- The project must find a good place to host the distro.
P001 - OWASP LiveCD Education Project
- Project description: The LiveCD project is a phenomenal idea. What it needs to really take flight is information that educates the user on every aspect. This project will generate text tutorials, video tutorials, and other learning media that will help users learn how to use the LiveCD along with the tools which it encompasses.
P001 - OWASP Application Security Training Materials
- Project description: Create Training materials for OWASP projects (from tools to guides)
- The project should create open source, release quality training materials from the other materials, presentations, and documents available at OWASP or other places on the net.
P001 - OWASP Corporate Application Security Rating Guide
- Project description: Help us examine the application security practices of the corporate world. This project is to assessing the top 50 companies and top 50 software companies for their practices. The goal is to make public what companies are doing in this area. OWASP Corporate Application Security Rating Guide has some sample materials for this project.
- The project will assess all public materials (interviews, presentations, briefings) for details
- The project will link to all source material used in creating the rating
P001 - OWASP Security Facts Label
- Project description: Build a security facts label methodology and tool. This could get a lot of attention.
- Define a set of concrete meaurable factors to include in the label
- Factors should cover the application itself as well as the people, teams, processes, tools, libraries, and supporting technologies that created it
- Build a survey application to gather data and store in an XML file
- Build a label generation program that reads the XML and creates a beautiful label (http://www.owasp.org/index.php/Types_of_application_security_metrics).
P001 - OWASP Security Test Case Generation Project
FIXME: sources could be static analysis, dynamic analysis, reading code, manual site interaction with a script, etc...
- Project description: Write a tool that takes the output of static analysis and turns it into penetration test cases. A smaller scale project would be a research paper that shows exactly how one can use the details from static analysis to generate scanner/pentest cases.
P001 - OWASP Security Test Automation
- Project description: Make a tool that generates, records, and plays back security test cases (think JUnit) so that you can do regression security testing. This could be based on WebScarab, Selenium, HTTPUnit or something else. But it would be custom for a particular application, not a generic scanner.
- The tool should have wizards for common security related use cases, such as logon, change password, access something, unauthorized access, etc...
- The tool should combine use cases with a set of predefined security tests to generate a custom set of security tests for an application
P001 - OWASP Security Unit Test Framework
- Project description: Create a wizard that will generate security-specific JUnit test cases for all the security controls in your security library. The tool should ask questions about security methods and generate appropriate test cases.
- At a minimum, the tool should be able to generate test cases that validate the that the validation methods canonicalize and encode properly, that the encoder does not use a blacklist, that the logging methods handle injection, that the hash algorithm is salted, that logout invalidates the user's session.
- The tool's coverage should roughly line up with the security methods defined in the OWASP ESAPI project.
P001 - OWASP Client-Side Browser Fingerprint Project
- Project description: Develop and document a technology that will create a "fingerprint" for a user's host/browser that can be used to detect when an attacker attempts to hijack their account.
- The tool should tolerate expected changes in host/browser configuration, such as a browser update.
- The tool should flag when the host/browser changes in an unexpected way.
P001 - OWASP CLASP Refresh
- Project description: Integrated security activities across the lifecycle. Currently people are talking about “touchpoints” and “activities” but there’s no unifying line of sight or theme.
P001 - OWASP .NET Refresh
- Project description: Organize the current OWASP .NET Project in a similar way to the Java Project
- Cross reference the .NET material in the other OWASP projects (Testing Guide, HoneyComb,etc...) and add more articles specific to .NET security
- Expand Dinis Cruz' research on .Net partial trust and create a Proof of Concept application showing how .Net's Partial Trust Sandbox can be used to mitigate against most Web Application Attacks (extra bonus points if a Java demo is also delivered :)
OWASP Site Generator
- Project description: Add more vulnerabilties (and document them using ORG)
- Implement the new engine (http based using interfaces) which allows the use of any backend web technology
- Add ability to save / log all requests receive
- Write documentation and articles about it
- Fix bugs in the OWASP version
- Add multiple Sample Reports (namely for the current OWASP tools)
- Write documentation and articles about it
OWASP Security Refactoring Project
- Project description: Create a tool that refactors existing code to use safer versions of dangerous methods. For Java EE/JSP the code can be rewritten to use the safer alternatives available for many calls in the OWASP ESAPI project. For .NET, converters from unmanaged code to managed code (i.e. C++ to C#, VB6 to VB.Net, etc…).
- Project description: Code Rewriter
- SQL statement rewrite - JSP <% rewrite - Dangerous API rewrite ( options: wrapper, comment out, etc, examples: printStackTrace, main() )
P001 - OWASP BlackTop - Runtime Coverage Analysis Tool
- Project description: Develop and document a "blackbox" pen testing code analysis solution capable of providing runtime coverage analysis for applications written in Java and .NET. In order to ensure the solution does not require access to the applications' source code, the solution should use (for example) the AspectJ and PostSharp bytecode weaving frameworks.
- The tool should provide code level details and call trace information of all ingress and egress points of the application and be able to identify gaps in the "blackbox" testing to facilitate more accurate and complete pen testing. All output and configuration should be done using an open format (such as XML) and enable command line execution of the application.
- Either the Eclipse Public License or the Mozilla Public license is allowable.
- Funds available: 10,000 USD
- Sponsor: Ounce Labs
P0001 - OWASP .NET Access Control Tool
- Project description: Create a tool that enables the easy development and use of CAS and RBS (Role Base Security) and frameworks for securing an application’s Business-Logic (for example using a CAS to prevent the user account’s from being changed, or an bank account from being accessed)
P0001 - OWASP AppSensor - Detect and Respond to Attacks from Within the Application
- Project description: Research what applications should do to detect and respond to attacks themselves. It has proven far too difficult to teach external systems what is allowed and not allowed in a particular application. The application itself is in the best position to determine what is and what is not an attack.
- This project should propose a framework for the types of patterns and behaviors that represent attacks on the part of both authenticated and unauthenticated users of typical web applications.
- The framework should include a definition of each attack pattern, techniques for detecting the attack, any related thresholds or quotas, and suggested responses. Responses could include alerts, additional logging, logout, account disable, or honeypot behavior. See the IntrusionDetector class in OWASP ESAPI for a simple approach to intrusion detection and response.
P0001 - OWASP Classic ASP Security Project
- Project description: Create a guide and supporting tools to support people charged with securing classic ASP web applications. The coverage should include all of the OWASP Top Ten and other important topics from OWASP, such as those included in the OWASP ESAPI project.
- Native Http Pipeline for IIS 5 and 6 (similar to what seems that will happen in IIS 7). This will be very important to protect ASP Classic pages
- CAS demands for dangerous methods (for example methods and classes that allow SQL Injections, XSS, etc…). The current CAS permission’s model is designed to protect the server and the other co-hosted applications. This needs to be extended so that CAS can be used to protect the actual application from vulnerabilities in its code
- CAS demands for methods or code that ’should’ exist (for example data valiation checks, authorization, etc….)
P001 - JStatic - Invoking Static Analysis from JUnit Test Cases
- Project description: Create an extension to JUnit that invokes a "static analyzer", say grep, BCEL, the Eclipse Model, FindBugs, or PMD. You fail the test case if you use certain banned APIs. Or even better, if you have better static analysis, you fail the test case if you do something more complex - like not logging in the method that calls isUserInRole().
P001 - OWASP Server Side Security Scanner
- Project description: Build a server-side scanner in a Java Filter. The idea is that you can scan (or fuzz) way more effectively from inside the web container. Did you know you can generate multiple HTTP requests within a filter? You can. So I thought this could first scan the environment - parse web.xml, analyze the filesystem, do bytecode analysis, whatever to generate an attack plan. Then it could start scanning 1000x faster than a normal scanner. And (best of all) it can monitor the session object, filesystem, and/or the logs to see what works.
P001 - OWASP Access Control Rules Tester
- Project description: Another idea is a pentest/scanner/webscarab thing that you can use to do access control testing. It's not terribly complicated, but would be incredibly useful. It "spiders" a site (either manually or automatically) with multiple different users, and generates different sitemaps for each (because they have different access). Then it compares the sitemaps and shows you where they're the same and different - potential access control problems.
P001 - OWASP Code Review Browser
- Project description: A simple Eclipse plugin to build a "Reverse API" tree navigation system. Packages -> Classes -> Methods -> callsites. And let's add in a separate tree to search for other stuff in the code that isn't method calls. Wouldn't it be cool if we wrote a server piece so people could easily submit them and everyone could use them?
- Project description: Manual Code Review Support Tool
- List APIs used in a "reverse" tree (with # of occurrences) - List Entry Points (from web.xml and webcontent folders) - Better search window that allows you to see the matching line of code - A analysis work tree based on search (similar to the call tree/hierarchy) - Simple findings & dangerous calls (Honeycomb, such as printStackTrace, empty catch block, insecure configurations) - Concurrency issues (class member variable in Servlet)
Category Name Description Regex --------------- --------------- -------------- ----------- Code Quality Fixme Unfinished code (fixme|hack|bug) Authentication Password All access to credentials (password|username|credentials|key|certificate) Access Control JavaEE Possible authorization (isAdmin) Obscenity !$??%@*#$ Frustrated developers (censored)
P001 - OWASP Attack Surface Metric
- Project description: Define a useful method for describing the attack surface of a typical web application and produce tools or an easy methodology for calculating it on a real application.
P001 - OWASP Positive Disclosure Project
- Project description: Create materials that encourage organizations to disclose what they are doing (across people, teams, processes, standards, supporting tools/technologies, and management) to ensure that they are producing secure software. Related to the OWASP Corporate Application Security Rating Guide project, this project.
P001 - OWASP Java Sandbox Policy Tool
- Project description: Create a tool that facilitates the creation of accurate, useful Java security policy files.
- The tool should support a "learn" mode like a host based firewall that asks about any accesses it doesn't know about. You can do this by implementing an intercepting SecurityManager (instead of one that throws SecurityExceptions). The interface should allow the user to "generalize" the specific policy request to make a more general rule. For example if the request is for "/temp/file123.xls" you might want to generalize the policy to allow all access to the "/temp" directory.
- The tool should produce machine readable security.policy files that can be deployed with the application.
P001 - OWASP Application Security Verification Standard
- Project description: Create a standard that details the process for verifying the security of application and producing a report that details the risks identified.
Level 1: Scan – fully automated dynamic or static analysis. Level 2: Pen Test – negative approach – looks for common vulnerabilities Level 3: Verify – positive approach – verifies all security mechanisms
We would specify the requirements for a review to meet each level. The requirements would cover: - Requirements for the process to be followed - // Requirements for notification of highs/criticals - Requirements for deliverable (structure, content) - Requirements for the risk ranking methodology used - Requirements for protection of customer information including deliverable and work products - Requirements for qualifications of the people involved - Requirements for security coverage (include by reference to other standards) - Requirements for depth of analysis required – simple data, vulnerabilities, technical risk, business risk
Remediation reviews must follow the same requirements, except limited to the scope of the original findings.
- Project description: Create an XSS testing framework for JSP files. The framework should invoke the JSP with a request that always returns scripts of various forms. If the script runs in the browser, the browser should display exactly where the problem is.