Projects/ESAPI Hackathon

ESAPI Hackathon / Bug Bash Contest

Contributing to the ESAPI Hackathon / Bug Bash

In this hackathon / bug bash we will focus on:

1. Implementing modular security controls that can be plugged in to the brand new ESAPI 3.0 framework allowing developers to quickly and easily integrate the security controls they need into their projects.
2. Fixing existing known existing bugs in the ESAPI 2.x framework.
3. Provide real-world reference implementations for the ESAPI 2.x Authenticator and AccessController.
4. Improving user documentation for the ESAPI 2.x framework.

Additional instructions on contributing to each of these sections follows.

All those contributing to the ESAPI Hackathon / Bug Bash agree to assign copyright ownership over to The OWASP Foundation and agree to allow The OWASP Foundation publish their source code contributions under the New BSD License and their documentation contributions under the Creative Commons 3.0 BY-SA license.

Judges and their immediate family members are encouraged to participate but are not eligible for prizes.

ESAPI 3.0 Contributions

The ESAPI 3.0 interfaces are just starting to be developed. These interfaces are hosted on GitHub at:

https://github.com/ESAPI/

If you wish to contribute to ESAPI 3.0, you are expected to choose one of the existing ESAPI 3.0 interfaces at https://github.com/ESAPI/esapi-java and provide a working implementation for it. You may, if / when appropriate, reuse code from ESAPI 2.x framework for your implementations. You must sign up for a GitHub account if you wish to participate in this aspect of the ESAPI hackathon.

Instructions for contributing to ESAPI 3.0 for this hackathon are:

1. Sign up for a GitHub account via the 'Sign Up' button on GitHub.
2. Login to your GitHub account via the 'Sign In' button.
3. Clone the ESAPI/esapi-java interfaces via the 'Fork' button from https://github.com/ESAPI/esapi-java
4. Implement one or more of the interfaces
5. Check in your code to your forked repository
6. Shoot the judges an email with a link to your repository and brief description of what you did.

Additional details, such as how to configure your pom.xml for Maven, may be found at https://github.com/ESAPI/esapi-hackathon.

ESAPI 2.x Contributions

If you plan to participate in the hackathon / bug smashing contest for ESAPI 2.x (rather than ESAPI 3.0), you will find the ESAPI 2.x code hosted at:

http://code.google.com/p/owasp-esapi-java/

Because we do not wish to give any advantages to those who are already ESAPI committers, we will ask you to submit all your code as patches to the main ESAPI trunk via Google Issues. (Note: Eclipse plugins such as Subclipse and others generally have a way to create patches under ‘Team’ but you can also use the ‘patch’ program to do so manually.) More details are below.

If you do not wish everyone to see your contributions prior to the end of the hackathon / bug smash contest, you can post a link to something like Google Drive or similar place and configure it so that only these Google accounts (those belonging to the judges) have access to it:

Kevin Wall - [email protected]

Chris Schmidt - [email protected]

Jeff Williams - [email protected]

Jim Manico - [email protected]

and then email Kevin Wall and Chris Schmidt with the URL of where you have posted your contribution.

ESAPI 2.x Bug Fixes

The ESAPI 2.x bugs are described as Google Issues at

http://code.google.com/p/owasp-esapi-java/issues/list

Address as many of the open Google Issus that can. However if you wish to participate for a prize, it is strongly suggested that you focus on issues that have a priority of Critical or High (17 of them when I counted them) as these are more likely to be considered as better meeting the criteria of “community need”.

To submit your code for ESAPI bug fixes, simply go in to the relevant Google Issue, create a new comment associated with the issue, and then attach your patches. If you do not wish everyone to see your code (patches), you can post a link to something like Google Drive or similar as described above.

Important Special Note: If you intend to address any crypto related Google Issues for ESAPI 2.x, please first contact Kevin Wall ([email protected]) as we may wish you to base your work off the "kww-crypto-2.1.1" branch rather than basing it off the main "trunk".

ESAPI 2.x Reference Implementations for Authenticator or AccessController

The current ESAPI 2.0 reference implementations are at best “toy” implementations; they certainly are not enterprise-ready as neither implementation scales well. There is a Spring authenticator model in the 'contrib' section, but if one is not using Spring for one's web application, one is either left writing one's own implementation of Authenticator and/or AccessController or simply not using ESAPI for authentication or authorization purposes. One example might be to replace the toy ESAPI 2.x reference FileBasedAuthenticator with an LDAPAuthenticator that would work with most enterprises. (Note: Should you implement an LDAPAuthenticator, the judges would prefer a JNDI implementation over something like a Mozilla LDAP SDK implementation because one thing that we do not wish to introduce are additional dependencies.)

These new reference implementations eventually will probably be placed under ‘contrib’, alongside the Spring authenticator and encrypted-properties code, but because you likely will not have ‘commit’ access, for the time being it is recommended that you follow the suggestions of posting your code as a .zip or tarball file on Google Drive or similar place and make this code available to the four judge’s Google accounts.

Because there unlikely is a Google Issue with this, you may either create a Google Issue and post your code as an attachment, or if you are concerned about others seeing what you have contributed before the contest is over, you may

ESAPI 2.x Documentation

Some suggested items that need work that you may wish to consider are

• Installation / Configuration / Getting Started Guide
• User Guide
  • Especially how to use ESAPI 2.x Validators and Encoders
• Create a FAQ list - can glean questions from places like the two ESAPI mailing lists and StackOverflow
• Fix the remaining Javadoc issues (see Google Issues list and/or just create the ESAPI Javadoc and look at all the errors.

Of course, other items are also possible, but these are ones that have been identified as lacking by the ESAPI user community.

Documentation should be submitted in some open source format such as ODT (Open Document Text), LaTex, etc. PDF or PostScript is also acceptable as a proof copy and you may be requested by some judges to provide such proofs should they not have access to process the native source.

To submit documentation, you may either create a new Google Issue and attach the documentation file(s) to the new Google Issue, or if you are concerned that someone else may use your idea.

Criteria for Judging

The contest will run from December 20, 2013 until January 20, 2014, after which judging results shall commence. The judging will take no more than one week. It will be following by an announcement of the winners. The winners will be announced on Saturday, February 1, 2014. The prizes that will be awarded will be as follows:

First place: Apple iPad Mini and an ESAPI T-shirt

Second place: $30.00 (USD) Amazon Gift Card and an ESAPI T-shirt

Third place: $20.00 (USD) Amazon Gift Card and an ESAPI T-shirt

Fourth place: An ESAPI T-shirt

Judging will be done by four individuals (Chris Schmidt, Kevin Wall, Jeff Williams, and Jim Manico) who are all very familiar with ESAPI, both from the development and project owner / management perspectives. The judges and their immediate family members are not eligible for prizes.

Judging will be based on the judge's perception of the contributions based on:

• Perceived amount of effort expended
• Community need
• Code or documentation quality
• Testability
• Documentation

All submittals must be in by 11:59PM US/Eastern time on January 20, 2014 and are considered final by that date and time. Submittals and/or files in either the GitHub or Google Code repositories will not be considered. Winners will be announced February 1, 2014. All decisions by the judges will be final unless overturned by the OWASP Board.

Let the hackathon begin!

Kevin W. Wall