GSoC2012 Ideas

Guidelines

Information for Students

The ideas below were contributed by OWASP project leaders and users. They are sometimes vague or incomplete. If you wish to submit a proposal based on these ideas, you may wish to contact the corresponding project leaders and find out more about the particular suggestion you're looking at. Being accepted as a Google Summer of Code student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out.

Adding a Proposal

Project:

Brief explanation:

Expected results:

Knowledge Prerequisite:

Mentor:

Ideas How to find ideas? Obvious sources of projects are the OWASP project wiki, bugs database, and project mailing lists.

Generic Sample Proposal

Accepted for GSoC 2011

Brief explanation:

KDE has developed a number of very interesting and powerful technologies, libraries and components but there is no easy way to show them to other people.

Expected results:

Something like Qt Demo but with KDE technologies.

Knowledge prerequisite:

C++ is the main language of KDE, therefore the demo should be in C++. The more you know about C++, Qt, KDE and scripting (for Kross and KDE bindings demos), the better. This idea encompasses so much different stuff the student is not expected to know everything before he starts coding (but will certainly know a lot when he's done!).

Skill level: medium

Mentor: Pau Garcia i Quiles as general mentor and someone to ask for directions. Specific help for each technology will probably require help from its developers.

OWASP Project Requests

ZAP Proxy

The Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications.

It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing.

ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

Website: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

Mailing List: http://groups.google.com/group/zaproxy-develop

Project 001 - Compare crawling sessions for authentication issues

Brief explanation: Develop a ZAP session crawler to be able to compare two crawling sessions of two logged in users and see what URLs or Actions could be performed from the other session.

Expected results:

ZAP will be able to recognise when requests are associated with different sessions.

ZAP should allow the user to view the crawled URLs for each session independantly, and show which URLs are unique to each session.

It should also be able to check if any of the 'unique' pages can in fact be accessed by the other session.

Knowledge Prerequisite:

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of crawlers and/or aplication security would be useful, but not essential.

Mentors: Simon Bennetts - OWASP ZAP Project Leader | Skyler Onken - OWASP ZAP Developer

Project 002 - Dynamically Configurable actions

Brief explanation:

ZAP provides various mechanisms which allow HTTP requests and responses to be changed dynamically. So (for example) a string in an HTTP request can automatically be changed to another string.

It also supports a scripting interface, which is very powerful but at the moment difficult to use.

This project would introduce something inbetween thess 2 options - a powerful way of defining (potentially) complex rules using a wizard based interface.

The challenge will be to make it as usable as possible while still providing a wide range of functionality.

Expected results:

This component would provide a set of highly configurable 'actions' which the user would see up via a wizard.

So they would initially define when the action applies, based on things like regex matching on request elements. And they should be able to define multiple criteria with ANDs and ORs.

Then they would define the actions, which could include:

• Changing the request (adding, removing or replacing strings)
• Raising alerts
• Breaking (to replace existing break points)
• Running custom scripts (which could do pretty much anything)

They would then be able to switch the actions on and off from the full list of defined actions using checkboxes

Knowledge Prerequisite:

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

Mentor: Simon Bennetts - OWASP ZAP Project Leader | Skyler Onken - OWASP ZAP Developer

Project 003 - Extend Web API to cover all of the ZAP functionality

Brief explanation:

ZAP provides a REST based API which can be used to control core aspects of the functionality provided by ZAP.

This project would extend that API to cover all/most of the ZAP functionality.

Expected results: Comprehensive Web API that will cover all of the ZAP Proxy functionality.

Knowledge Prerequisite:

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

Mentor: Simon Bennetts - OWASP ZAP Project Leader | Skyler Onken - OWASP ZAP Developer

Project 004 - Closer integration with OWASP AJAX

Brief explanation:

ZAP provides a basic spider that can be used to explore an application, however it is very limited, especially when used with AJAX based applications.

The OWASP AJAX crawling tool (https://www.owasp.org/index.php/OWASP_AJAX_Crawling_Tool) is specifically designed to crawl AJAX applications and can already use ZAP as a proxy.

This project would develop a ZAP plugin which integrates ZAP with the OWASP AJAX crawling Tool.

Expected results:

A new ZAP plugin would be produced which allows ZAP to crawl AJAX applications using the OWASP AJAX crawling tool.

The plugin would allow the 2 tools to be tightly integrated, while still allowing them to work completely independently.

Knowledge Prerequisite:

Both ZAP and the AJAX tool are written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML. Some knowledge of crawlers and/or aplication security would be useful, but not essential.

Mentor: Simon Bennetts - OWASP ZAP Project Leader | Skyler Onken - OWASP AJAX Tool Project Leader

ESAPI Swingset Interactive

The ESAPI Swingset Interactive is a web application which demonstrates common security vulnerabilities and asks users to secure the application against these vulnerabilities using the ESAPI library. The application is intended for Java Developers. The goal of the application is to teach developers about the functionality of the ESAPI library and give users a practical understanding of how it can be used to protect web applications against common security vulnerabilities.

Website: https://www.owasp.org/index.php/Projects/OWASP_ESAPI_Swingset_Interactive_Project

Mailing List: http://lists.owasp.org/pipermail/owasp-esapi-swingset/

Project 001 - Implement a solid Authenticator class

Brief explanation:

Provide Swingset Interactive with a simple but fully functional implementation of the ESAPI Authenticator Interface.

Expected results:

Swingset Interactive comes with a rudimentary implementation of the ESAPI Authenticator Interface, a FileBasedAuthenticator. This implementation needs to be fixed or replaced in order to allow users of the Swingset Interactive application all of the ESAPI Authenticator methods, including registration, login, a "remember me" feature and a persistence beyond server restart.

Knowledge Prerequisite:

A basic knowledge of Java, Java Servlets is necessary, as is knowledge of HTML.

Mentor: Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

Project 002 - Upgrade to ESAPI 2.0.x

Brief explanation:

Adapt Swingset Interactive to work with ESAPI 2.0.x. libraries.

Expected results:

Make the current Swingset Interactive application compatible with ESAPI 2.0.x. Swingset Interactive currently comes with ESAPI 1.4.Various changes and improvements were made with ESAPI 2.0.x and it is generally recommended not to use 1.4 any more for Java EE Projects.

Knowledge Prerequisite:

A basic knowledge of Java, Java Servlets is necessary, as is knowledge of HTML.

Mentor: Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

Project 003 - Improve the Swingset look and feel

Brief explanation:

Various minor bug fixes and improvements.

Expected results:

Fix and solve a number of documented bug fixes and improvement suggestions for the Swingset Interactive and bring in your own improvement suggestions.

Knowledge Prerequisite:

A basic knowledge of Java, Java Servlets is necessary, as is knowledge of HTML.

Mentor: Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

Project 004 - Platform-independent Swingset Interactive

Brief explanation:

Adapt Swingset Interactive to work with any OS.

Expected results:

Swingset Interactive currently runs only under Windows. Modify the Eclipse project and installation scripts to be easily installed on any OS that runs Eclipse.

Knowledge Prerequisite:

Good knowledge of Java, Apache Tomcat and a broad knowledge of various Operating Systems are required.

Mentor: Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

Project 005 - Mavenize the Swingset

Brief explanation:

Create a new Swingset Interactive Maven Archetype.

Expected results:

Offer the Swingset Interactive as a Maven Archetype.

Knowledge Prerequisite:

Good knowledge of Java, and Maven are required.

Mentor: Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

Project 006 - New Lessons

Brief explanation:

Develop new coding lessons to learn the ESAPI Libraries.

Expected results:

A new set of interactive coding lessons for students to use.

Knowledge Prerequisite:

Good knowledge of Java, ESAPI, HTML and the Eclipse framework are required.

Mentor: Fabio Cerullo - OWASP ESAPI Swingset Interactive Project Leader

AntiSamy

The AntiSamy project provides a Java library for developers to accept innocent HTML markup without exposing themselves to possible cross-site scripting (XSS) vulnerabilities.

Website: https://www.owasp.org/index.php/AntiSamy

Mailing List: https://lists.owasp.org/mailman/listinfo/owasp-antisamy

Project 001 - Add a Functional Testing Suite

Brief explanation:

Create a set of positive test cases designed to generate assurance that AntiSamy correctly processes inert HTML.

Expected results:

As of today, AntiSamy has a large set of test cases that prove that AntiSamy is resistant to a number of known attacks. There are also test cases that make sure it doesn't crash when given bad data. There are very few test cases that ensure that it properly handles good HTML. A set of test cases that confirm how expected good data is processed by AntiSamy generates a lot of assurance that it is functional as well as secure.

Knowledge Prerequisite:

Comfort with Java, Maven, SVN and JUnit are required.

Mentor: Arshan Dabirsiaghi - OWASP AntiSamy Project Leader

Project 002 - Various Bug Fixes

Brief explanation:

There are around 30 open defects from the issue tracker.

Expected results:

A set of patches that address defects or implement features from the accepted issues in the issue tracker.

Knowledge Prerequisite:

Comfort with Java, Maven, SVN and JUnit are required.

Mentor: Arshan Dabirsiaghi - OWASP AntiSamy Project Leader

AppSensor

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into an existing application. Current efforts are underway to create the AppSensor tool which can be utilized by any existing application interested in adding detection and response capabilities.

Website: https://www.owasp.org/index.php/OWASP_AppSensor_Project

Mailing List: https://lists.owasp.org/mailman/listinfo/owasp-appsensor-project

Project 001 - SOAP web service server implementation

Brief explanation:

AppSensor is implementing a new service based architecture for the next version. This project would involve implementing a SOAP based web service (based on the WS-I Basic Profile standard) as a front-end to the AppSensor processing engine.

Expected results:

A new SOAP based web service would be produced which provides a front-end to the existing processing core built into AppSensor.

Knowledge Prerequisite:

AppSensor is written in Java, so a good knowledge of this language is recommended. Additionally, some knowledge of SOAP-based web services (particularly the WS-I Basic Profile standard) would be useful, but not essential. Finally, basic knowledge of application security would be very helpful.

Mentor: John Melton - OWASP AppSensor Development Leader

Project 002 - REST web service server implementation

Brief explanation:

AppSensor is implementing a new service based architecture for the next version. This project would involve implementing a REST based web service as a front-end to the AppSensor processing engine.

Expected results:

A new REST based web service would be produced which provides a front-end to the existing processing core built into AppSensor.

Knowledge Prerequisite:

AppSensor is written in Java, so a good knowledge of this language is recommended. Additionally, some knowledge of REST-based web services would be useful, but not essential. Finally, basic knowledge of application security would be very helpful.

Mentor: John Melton - OWASP AppSensor Development Leader

Project 003 - SOAP/REST web service client implementation

Brief explanation:

AppSensor is implementing a new service based architecture for the next version. This project would involve implementing SOAP and REST based web service clients in various languages to communicate to a back-end server that represents the AppSensor core engine.

Expected results:

New SOAP and REST based web service clients would be produced which communicate to a back-end server that represents the AppSensor core engine.

Knowledge Prerequisite:

AppSensor is written in Java, and the initial client will be for Java, so a good knowledge of this language is recommended. Proficiency in one or more of the following languages would also be beneficial: C#, PHP, Python, Ruby. Additionally, some knowledge of REST and SOAP based web services would be useful, but not essential. Finally, basic knowledge of application security would be very helpful.

Mentor: John Melton - OWASP AppSensor Development Leader

Project 004 - Detection Point Implementation Expansion

Brief explanation:

AppSensor has documentation outlining around 50 different detection points. We currently have an existing implementation that supports a small handful (5-7) of those. Implementing additional detection points would increase the value of the project.

Expected results:

Implementations of existing detection points would be produced. This could be done in any number of languages.

Knowledge Prerequisite:

AppSensor is written in Java, and the initial client will be for Java, so a good knowledge of this language is recommended. Proficiency in one or more of the following languages would also be beneficial: C#, PHP, Python, Ruby. Finally, basic knowledge of application security would be very helpful.

Mentor: John Melton - OWASP AppSensor Development Leader

Project 005 - Implement new configuration file format

Brief explanation:

AppSensor currently uses a properties file format for configuration. A new XML file format is planned. Moving to an XML format would simplify the configuration and make it easier to extend.

Expected results:

A new implementation of the configuration file would be created. An XML file format would be created, along with the code to process that file format, as well as an XSD to validate the file.

Knowledge Prerequisite:

AppSensor is written in Java, so a good knowledge of this language is recommended. Additionally, a basic understanding of XML and XSD would be useful, though not required.

Mentor: John Melton - OWASP AppSensor Development Leader

Project 006 - Trend Monitoring

Brief explanation:

Several of the detection point concepts for AppSensor revolve around the idea of trend monitoring within an application. There is a trivial implementation currently that provides very little utility. An enhanced trend monitoring capability would allow for the implementation of more detection points and expand the capabilities of AppSensor.

Expected results:

A new implementation of the trend monitoring module would be implemented.

Knowledge Prerequisite:

AppSensor is written in Java, so a good knowledge of this language is recommended. Additionally, basic knowledge of application security would be very helpful.

Mentor: John Melton - OWASP AppSensor Development Leader

Project 007 - Reporting

Brief explanation:

AppSensor currently has very weak reporting capabilities. Enhanced reporting would provide users with better insight into the health of the applications being protected by AppSensor

Expected results:

New APIs for reporting would be implemented as SOAP and/or REST based web services. Additionally, a reference implementation of a reporting client UI would be developed.

Knowledge Prerequisite:

AppSensor is written in Java, and the initial client will be for Java, so a good knowledge of this language is recommended. Some knowledge of REST and SOAP based web services would also be useful, but not essential. Additionally, some experience in a modern UI development framework would be beneficial, presumably an RIA style framework. Finally, basic knowledge of application security would be very helpful.

Mentor: John Melton - OWASP AppSensor Development Leader

ESAPI

ESAPI (The OWASP Enterprise Security API) is a free, open source, web application security control library that makes it easier for programmers to write lower-risk applications. The ESAPI libraries are designed to make it easier for programmers to retrofit security into existing applications. The ESAPI libraries also serve as a solid foundation for new development.

Website http://www.esapi.org

Mailing List: https://lists.owasp.org/mailman/listinfo/esapi-dev

Project 001 - Port ESAPI 2.0.x to ESAPI-PHP

Brief Explanation:

The ESAPI-PHP Project has become outdated and needs to be brought up-to-date with the latest ESAPI 2.0 specification.

Expected Results:

PHP-Library with ESAPI 2.x functionality.

Knowledge Prerequisites:

ESAPI 2.0.x is written in Java, so an understanding of the Java programming language is required as well as proficiency in PHP. Additionally, a basic understanding of application security would be desireable.

Mentor: Chris Schmidt - ESAPI Project Leader

Project 002 - Resolve Bugs for ESAPI 2.1.0 Roadmap

Brief Explanation:

There are several outstanding issues in the ESAPI Bugtracker (http://code.google.com/p/owasp-esapi-java/issues/list) that need to be addressed for the 2.1.0 release.

Expected Results:

Patches and unit tests to resolve the outstanding ESAPI issues.

Knowledge Prerequisistes:

Comfortable working in Java, writing unit tests using JUnit and creating patch files using svn.

Mentor: Chris Schmidt - ESAPI Project Leader / Kevin Wall - ESAPI Java Development Leader

Project 003 - Develop Struts2 Components

Brief Explanation:

Struts2 is one of the most widely used Java MVC frameworks, users of ESAPI are regularly looking for pluggable components that they can drop into their application to utilize ESAPI within the context of their application framework. The goal of this task is to create a set of pluggable components that integrate ESAPI into Struts2 to utilize ESAPI Encoders, Validation, and Intrusion Detection with the least amount of manual work and configuration.

Expected Results:

A standalone project that uses ESAPI Components in a Struts2 add-on.

Knowledge Prerequisites:

A solid understanding of Java and Apache Struts, comfort developing unit tests in JUnit and functional tests using Selenium as well as maintaining a Maven build.

Mentor: Chris Schmidt - ESAPI Project Leader

Project 004 - JSR-303 Bean Validation Provider

Brief Explanation

JSR-303 is a huge step forward in the way that validation is performed. There are currently 2 implementations of the JSR-303 specification - Hibernate-Validator and Apache BVal. Both of these libraries have demonstrated a lack of security driven validation and focused on using Constraints for business validation purposes. There are also key steps missing in the implementations, most notably - canonicalization of data prior to validation. The goal of this task will be to create a proof of concept implementation of the JSR-303 specification that passes all tests in the Java Compatibility Kit and utilizes the ESAPI Validators to implement constraints.

Expected Results:

A proof of concept implementation of the JSR-303 specification as a standalone JAR

Knowledge Prerequisites:

Comfortable in Java, especially utilizing advanced JDK5+ features such as Annotations and writing custom annotation processors.

Mentor: Chris Schmidt - ESAPI Project Leader

Project 005 - Mobile Service Provider

Brief Explanation:

The mobile platform continues to grow exponentially and there has been very little movement of exposing security functionality to mobile applications. Creation of a mobile service platform that exposes security controls to mobile applications would make great strides towards providing mobile application developers with the means to write more secure code on mobile clients.

Expected Results:

A WebService container (Jersey or SOAP) that exposes key controls (output encoding, input validation, secure logging, security policy, access control, authentication) to clients using a simple interface.

Knowledge Prerequisites:

Familiarity with Java and Apache-WS or Jersey. An understanding of the mobile platform would also be extremely useful.

Mentor: Chris Schmidt - ESAPI Project Leader