Difference between revisions of "GSoC2013 Ideas"

Revision as of 16:15, 19 March 2013

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.

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

OWASP PHP Security Project

Description: OWASP PHP Security project plans to gather around secure PHP libraries, and provide a full featured framework of libraries for secure web applications in PHP, both as separate de-coupled libraries and as a whole secure web application framework. Many aspects of this project are already handled, and are being added to OWASP.

Expected Results: Result of this project is much more security among PHP applications. Most PHP applications are vulnerable and there's no central approach to secure them (due to open source nature). Many people look at OWASP for such information.

Knowledge Prerequistics: Anyone with adequate PHP programming language experience (possibly web application development in PHP). There are hard and easy parts of this project. For tougher parts, familiarity with security concepts, advanced SQL, and advanced PHP and web server configuration is required.

Mentor: Abbas Naderi

OWASP ZAP: Dynamically Configurable actions

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.

Brief explanation:

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

Expected results:

• A new ZAP add-on providing the above functionality

The code should be:

• Clean and easy to follow
• Include a full set of unit tests
• Include good documentation

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

OWASP ZAP: Enhanced HTTP Session Handling

Brief explanation:

ZAP can currently manage multiple sessions. This development would allow ZAP to better handle HTTP Sessions to provide different views of a given target depending on the different user's permissions that the targeted site supports.

This implementation such provide a set of methods to answer questions such as: 1)What nodes(pages) are available to a group of users and not to other groups of users 2)What nodes are available to different users but these contain significant differences in the HTTP headers and/or in the body content.

This will allow ZAP to be used to detect access control issues which would otherwise require manual testing. Expected results:

• ZAP will have an understanding of both users and roles and be able to associate them with HTTP sessions.
• The user will be able to associate credentials with different roles allowing ZAP to automatically authenticate as any user / role.
• ZAP will be able to spider an application using a given user/role.
• ZAP will be able to report the differences between different HTTP sessions.
• ZAP will be able to show different views of the site in the site's tree tab with the pages visible for each session.
• ZAP will be able to attack one session based on the URLs accessed in another session and report which appear to work.

Expected results:

Users will be able to:

• specify exactly which alerts are included, by context, site or on an individual alert basis
• specify what information is included and how it is layed out
• specify a range of output formats, at least including HTML and PDF
• include details of what testing has been performed (automatically generated where possible)
• apply their own branding
• save report templates, and apply templates downloaded from the ZAP marketplace

The code should be:

• Clean and easy to follow
• Include a full set of unit tests
• Include good documentation

Knowledge Prerequisite:

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

Mentor: Guifre Ruiz - OWASP ZAP Dev Team

OWASP ZAP: Advanced reporting

Brief explanation:

The reports that ZAP generates are in a fixed format which is not particularly useful or attractive. This development would provide the user with a fine grained control over the contents, layout and branding of the reports.

Expected results:

A new user interface for genrating reports which is easy to use and provides the user with a wide range of options. The code should be:

• Clean and easy to follow
• Include a full set of unit tests
• Include good documentation

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