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 Project Requirements
- 2 Project Requests
- 2.1 P001 - OWASP Open Threat Modeling Process
- 2.2 P001 - OWASP Teachable 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 Corporate Application Security Rating Guide
- 2.7 P001 - OWASP Security Facts Label
- 2.8 P001 - OWASP Security Test Automation
- 2.9 P001 - OWASP Security Unit Test Framework
- 2.10 P001 - OWASP Client-Side Browser Fingerprint Project
- 2.11 P001 - OWASP CLASP Refresh
- 2.12 P001 - OWASP .NET Refresh
- 2.13 OWASP SiteGenerator
- 2.14 OWASP Security Refactoring Project
- 2.15 P001 - OWASP BlackTop - Runtime Coverage Analysis Tool
- 2.16 P0001 - OWASP .NET Access Control Tool
- 2.17 P0001 - OWASP AppSensor - Detect and Respond to Attacks from Within the Application
- 2.18 P0001 - OWASP Classic ASP Security Project
- 2.19 P001 - JStatic - Invoking Static Analysis from JUnit Test Cases
- 2.20 P001 - OWASP Server Side Security Scanner
- 2.21 P001 - OWASP Access Control Rules Tester
- 2.22 P001 - OWASP Code Review Browser
- 2.23 P001 - OWASP Attack Surface Metric
- 2.24 P001 - OWASP Positive Disclosure Project
- 2.25 P001 - OWASP Java Sandbox Policy Tool
- 2.26 P001 - OWASP Application Security Verification Standard
- 2.27 P001 -
- 2.28 P001 -
Global Project Requirements
- 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
- Projects must not advocate the use of any particular product, although classes of tools may be referenced.
P001 - OWASP Open Threat Modeling Process
- Project description: Document a methodology for 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. The threat model should produced should include the security relevant details of the application architecture, the threat agents, attack vectors, vulnerabilities, security controls, technical impacts and business impacts. All the common security areas should be represented across identity and authentication, session management, access control, input validation, encoding and canonicalization, error handling, logging and intrusion detection, availability, integrity, concurrency, etc...
- 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 (as an option) 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 Teachable Static Analysis Workbench
- Project description: Build a security analysis workbench that allows the security analyst to teach the tool about the application. In particular, the analyst would teach the tool about the different security controls, such as input validation, authentication, access control, etc... The tool will use this information to help the analyst verify that the application has the appropriate mechanisms and that they are used properly in all the right patterns.
- As the analyst provides information, 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.
- For example, when the analyst indicates where the input validation controls are located, the tool should show the analyst where they are used, and whether they are used in all the places they should be. Another example - by indicating where the business functions are located, and where the access control mechanism is located, the tool should find instances of business functions that do not check access.
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.
- Create a tool that generates a realistic application for dynamic testing (scanning or pentesting) based on a number of inputs, such as the number of pages, types of pages, functions, security controls, and backend systems. Most importantly, the tool should allow specification of the types and number of vulnerabilities to embed in the application. A tracking mechanism would be helpful to allow measurement of whether the vulnerability has been discovered by the security tool.
- Alternatively, build a tool that generates source code for a working application. Such a tool would be very useful for evaluating static analysis tools and could be used for dynamic analysis as well. Like the dynamic benchmarking environment, the static environment should allow an application to be generated based on a number of parameters.
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 distro should be based on the existing Live CD project, but refreshed to include the latest versions of all the tools, documents, and projects at OWASP and beyond.
- The goal of the project is to make the tools as organized and obvious to use as possible.
- The project must find a good place for OWASP to host the distro that doesn't cost too much and can handle a significant number of downloads.
P001 - OWASP LiveCD Education Project
- Project description: Produce training materials that show users how to use every part of the OWASP Live CD. 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.
- The training materials should include a roadmap to help people find the right tool for the job that they're trying to accomplish.
- The training materials should make the Live CD useful to application security specialists and other interested parties, including those without extensive application security experience. The training materials should show developers and software testers in particular how to use the OWASP tools, methodologies, and documents.
P001 - OWASP Corporate Application Security Rating Guide
- Project description: Help us benchmark the application security practices of the corporate world. Assess 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: Design a security facts label methodology and supporting tool. 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. Also create a label generation program that reads the XML and creates a beautiful label.
P001 - OWASP Security Test Automation
- Project description: Create a tool that generates, records, and plays back security test cases (think JUnit) to enable regression testing for security. This could be based on WebScarab, Selenium, HTTPUnit or something else. But it would create test cases that are custom for a particular application, not a generic scanner.
- The tool should have wizards for common security related use cases, such as login, change password, authorized access, unauthorized access, etc... The tool should combine these security use cases with a set of predefined security tests to generate a custom set of security tests for an application. A simple example is that the tool would record the login transaction, and generate a security test to verify that the session cookie is changed (to defeat session fixation).
- The tool could also use the output from static analysis to create 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 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 server application can track changes to the client-generated fingerprint and request additional authentication if the fingerprint changes too radically.
- The tool should be configurable to 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: Reorganize and update the materials in the OWASP CLASP project to be more complete and comprehensive. Each of the activities must include detailed methodologies, so that they can be practiced repeatably by anyone with the appropriate background.
- The activities should include all the related job aides and materials to perform the activity, such as worksheets, report formats, databases, etc...
- No proprietary methodologies can be used as a part of CLASP.
P001 - OWASP .NET Refresh
- Project description: Organize the current OWASP .NET Project in a similar way to the Java Project. The goal is a complete independent (unbiased) set of materials showing how to build secure applications that use .NET technology. Cross reference the .NET material in the other OWASP projects (Testing Guide, HoneyComb, etc...) and add more articles specific to .NET security.
- This project will require recruiting and organizing a volunteer team to create articles and verify the accuracy of the content available. The project lead must be a great project manager with the communication skills to lead this project, not necessarily the most advanced technical security researcher.
- Project description: Bring the OWASP SiteGenerator project to release quality. 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.
- The enhancements should include the ability to save/log all requests receive, and should include multiple Sample Reports (namely for the current OWASP tools).
- Produce documentation and articles about SiteGenerator, and work to evalutate current tools against generated applications to test their abilities.
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.
- The project must produce an open source, release quality application, including a GUI and documentation.
- 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.
- The project must produce an open source, release quality application, including a GUI and documentation.