Revision as of 13:43, 31 January 2017

OWASP Project Requests

Tips to get you started in no particular order:

* Read the GSoC SAT
* Check out the suggested projects below
* Contact the mentors and teams of the projects that you are interested in

OWASP Juice Shop

OWASP Juice Shop Project is an intentionally insecure webapp for security trainings written entirely in Javascript which encompasses the entire OWASP Top Ten and other severe security flaws. Juice Shop is written in Node.js, Express and AngularJS. The application contains more than 30 challenges of varying difficulty where the user is supposed to exploit the underlying vulnerabilities. Apart from the hacker and awareness training use case, pentesting proxies or security scanners can use Juice Shop as a "guinea pig"-application to check how well their tools cope with Javascript-heavy application frontends and REST APIs.

Challenge Pack 2017

Brief Explanation:

Ideas for potential new hacking challenges are collected in GitHub issues labeled "challenge". This project could implement a whole bunch of challenges one by one and release them over the course of several small releases. This would allow the student to work in a professional Continuous Delivery kind of way while bringing benefit to the Juice Shop over the duration of the project.

Coming up with additional ideas for challenges would be part of the project scope, as the list of pre-existing ideas might not be sufficient for a GSoC project.

Expected Results:

• 10 or more new challenges for OWASP Juice Shop (including required functional enhancements to place the challenges in, e.g. the Order Dashboard and Pomace Recycling user stories)
• Each challenge comes with full functional unit and integration tests
• Each challenge is verified to be exploitable by corresponding end-to-end tests
• Hint and solution sections for each new challenge are added to the "Pwning OWASP Juice Shop" ebook
• Code follows existing styleguides and passes all existing quality gates regarding code smells, test coverage etc.

Getting started:

• Get familiar with the architecture and code base of the application's rich Javascript frontend and RESTful backend
• Get a feeling for the high code & test quality bar by inspecting the existing test suites and static code analysis results
• Get familiar with the CI/CD process based on Travis-CI and several associated 3rd party services
• Check out the corresponding GitHub milestone for this project: https://github.com/bkimminich/juice-shop/milestone/3

Knowledge Prerequisites:

• Javascript, Unit/Integration testing, experience with (or willingness to learn) AngularJS (1.x) and NodeJS/Express, some security knowledge would be preferable.

Mentors:

• Bjoern Kimminich - OWASP Juice Shop Project Leader

Tech Stack Update

Brief Explanation:

Development of OWASP Juice Shop started in 2014 and was based on - back then - quite recent Javascript frameworks and modules:

• AngularJS 1.x with Bootstrap in the client
• Express on top of NodeJS on the server with
  • SQLite as a database
  • Sequelize as an OR-Mapper
    • sequelize-restful as an automatic API-generator on top of the DB entities
• Jasmine 1.x to specify behavioral tests
  • Karma as a test runner for the client-side unit tests
  • Frisby.js for API tests on a dynamically launched server
  • Protractor for end-to-end testing of the challenge exploits
• NPM for running/testing the application
• Grunt for some of the custom build scripts

Several of the above frameworks or modules have moved on to new (runtime incompatible) major releases, namely Angular 2, Sequelize, Frisby and Jasmine. Other modules are out of maintenance entirely, e.g. sequelize-restful.

Migrating the OWASP Juice Shop to the latest versions of the mentioned frameworks & modules is an important step to keep the application relevant as the most modern intentionally broken web application. Moving to entirely different frameworks might be taken into considerationas well.

Expected Results:

• High-level target architecture overview including a migration plan with intermediary milestones
• Execution of migration without breaking functionality or losing tests along the way
• Code follows existing (or new) styleguides and passes all existing (or new) quality gates regarding code smells, test coverage etc.

Getting started:

• Get familiar with the architecture and code base of the application's rich Javascript frontend and RESTful backend
• Get a feeling for the high code & test quality bar by inspecting the existing test suites and static code analysis results
• Get familiar with the CI/CD process based on Travis-CI and several associated 3rd party services
• Check out the corresponding GitHub milestone for this project: https://github.com/bkimminich/juice-shop/milestone/2

Knowledge Prerequisites:

• Javascript, experience with latest Javascript frameworks for frontend, backend, testing and building (e.g. AngularJS 2.x, Jasmine 2.x, ...)

Mentors:

• Bjoern Kimminich - OWASP Juice Shop Project Leader

Your idea

Brief Explanation:

You have an awesome idea to improve OWASP Juice Shop that is not on this list? Great, please submit it!

Getting started

• Get in touch with Bjoern Kimminich

Expected Results:

• A new feature that makes OWASP Juice Shop even better
• Code follows existing styleguides and passes all existing quality gates regarding code smells, test coverage etc.

Knowledge Prerequisites:

• Javascript, Unit/Integration testing, experience with (or willingness to learn) AngularJS (1.x) and NodeJS/Express, some security knowledge would be preferable.

Mentors:

• Bjoern Kimminich - OWASP Juice Shop Project Leader

OWASP Mobile Hacking Playground

The OWASP Mobile Hacking Playground (https://github.com/OWASP/OMTG-Hacking-Playground) is part of the OWASP Mobile universe, which consists at the moment of the following projects:

• Mobile Application Security Verification (MASVS). The MASVS is a list of security requirements for mobile applications that can be used by architects, developers, testers, security professionals, and consumers to define what a secure mobile application is. (https://github.com/OWASP/owasp-masvs)
• Mobile Security Testing Guide (MSTG). The OWASP MSTG is a comprehensive manual for testing the security of mobile apps. It describes technical processes for verifying the controls listed in the OWASP Mobile Application Verification Standard (MASVS). The MSTG is meant to provide a baseline set of test cases for dynamic and static security tests, and to help ensure completeness and consistency of the tests. (https://github.com/OWASP/owasp-mstg)

In order to give also practical guidance to developers, security researches and penetration testers of mobile Apps, a hacking playground was created with the goal to create different mobile App’s that contain different vulnerabilities that map to the MSTG test cases. Every test case described in the MSTG will therefore be implemented in an Android and iOS App. This has two advantages:

• A developer can identify vulnerable code in the provided App’s and can see the implications and risks if such patterns are used and can look for the best practices in the MSTG to mitigate the vulnerabilities.
• Penetration testers / security researchers can identify bad practices, dangerous methods and classes they should look for when assessing a Mobile App and can gain more knowledge through the information provided in the OMTG.

It is also encouraged to use the App(s) for education purpose during trainings and workshops.

Creation of Android Code Samples

Brief Explanation:

An Android App that maps to the MSTG test cases is already created. This App contains mostly test cases that are related to data storage on an Android device. In order to close the gap to the MSTG more test cases need to be added that show "bad practices" that lead to vulnerabilites, but also the latest security best practices to demonstrate how vulnerabilites can be mitigated.

For examples of implemented test cases, see the Wiki of the Mobile Hacking Playground: https://github.com/OWASP/OMTG-Hacking-Playground/wiki/Android-App

Expected Results:

The following categories and their test cases are not fully added to the Android App:

• Cryptography (https://github.com/OWASP/owasp-masvs/blob/master/Document/0x08-V3-Cryptography_Verification_Requirements.md)
• Authentication and Session Management (https://github.com/OWASP/owasp-masvs/blob/master/Document/0x09-V4-Authentication_and_Session_Management%20Requirements.md)
• Network Communication (https://github.com/OWASP/owasp-masvs/blob/master/Document/0x10-V5-Network_communication_requirements.md)
• Environmental Interaction (https://github.com/OWASP/owasp-masvs/blob/master/Document/0x11-V6-Interaction_with_the_environment.md)
• Code Quality (https://github.com/OWASP/owasp-masvs/blob/master/Document/0x12-V7-Code_quality_and_build_setting_requirements.md)

For some of the testcases this also includes creating an endpoint on server side in order to fully understand the test case and possible security concerns.

As not all missing test cases can be implemented during the GSOC a subset of them will be defined with the student together.

Getting started: Here are a few suggestion on how to get started.

• Check the Mobile Hacking Playground Android App, browse through the code and Wiki to get an understanding of what a test case look likes.
• Browse through the MASVS and check the different areas and their defined requirements.
• Read about Security vulnerabilites and best practices for Android in areas you are interested in (e.g. Cryptography).

Knowledge Prerequisites: General interest in Mobile and Security. Basic knowledge of Android and Java.

Mentors: Sven Schleier - OWASP Mobile Security Testing Guide and Mobile Hacking Playground Project Leader

OWASP ZAP

OWASP Zed Attack Proxy Project (ZAP) The OWASP Zed Attack Proxy (ZAP) is one of the world’s most popular free security tools and is actively maintained by hundreds of international volunteers. Previous GSoC students have implemented key parts of the ZAP core functionality and have been offered (and accepted) jobs based on their work on ZAP.

We have just included a few of the ideas we have here, for a more complete list see the issues on the ZAP bug tracker with the project label.

Field Enumeration

This would allow a user to iterate though a set of (user defined) characters in order to identify the ones that are filtered out and/or escaped.

The user should be able to define the character sets to test and will probably need to configure the success and failure conditions, as well as valid values for other fields in the form.

Expected Results

• User able to specify a specific field to enumerate via the ZAP UI
• A list of all valid characters to be returned from the sets of characters the user specifies
• Ability to configure a wide range of success and failure conditions to cope with as many possible situations as possible
• Code that conforms to our Development Rules and Guidelines

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.

Mentors

Simon Bennetts @ and the rest of the ZAP Core Team

Scripting Code Completion

ZAP provides a very powerful scripting interface. Unfortunately to use it effectively is only really possible with a good knowledge of the ZAP internals. Adding code completion (eg using a project like https://github.com/bobbylight/AutoComplete) would significantly help users.

Expected Results

• Code completion for all of the parameters for all available functions in the standard scripts
• Implementations for JavaScript, JRuby and Jython
• Helper classes with code completion for commonly required functionality
• Code that conforms to our Development Rules and Guidelines

Knowledge Prerequisite:

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

Mentors:

Simon Bennetts @ and the rest of the ZAP Core Team

Your idea

Brief Explanation:

ZAP is a great framework for building new and innovative security testing solutions. If you have an idea that is not on this list then don't worry, you can still submit it, we have accepted original projects in previous years and have even paid a student to work on their idea when we did not get enough GSoC slots to accept all of the projects we wanted.

Getting started

• Get in touch with us :)

Expected Results:

• A new feature that makes ZAP even better
• Code that conforms to our Development Rules and Guidelines

Knowledge Prerequisites: 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.

Mentors: Simon Bennetts @ and the rest of the ZAP Core Team

BLT / Bugheist

Brief Explanation:

Bugheist lets anyone report issues they find on the internet. Found something out of place on Amazon.com ? Let them know. Companies are held accountable and shows their response time and history. Get points for reporting bugs and help keep the internet bug free.

Getting started

• Get in touch with us :)

Expected Results:

• A new feature that makes Bugheist even better

Knowledge Prerequisites: BLT is written in Python / Django, so a good knowledge of this language and framework is recommended, as is knowledge of HTML. Some knowledge of application security would be useful, but not essential.

Mentors: Sean Auriti @ and the rest of the BLT Core Team

OWASP Security Knowledge framework

Brief Explanation

The OWASP Security Knowledge Framework is intended to be a tool that is used as a guide for building and verifying secure software. It can also be used to train developers about application security. Education is the first step in the Secure Software Development Lifecycle. This software can be run on Windows/Linux/OSX using python-flask.

In a nutshell

- Training developers in writing secure code

- Security support pre-development ( Security by design, early feedback of possible security issues )

- Security support post-development ( Double check your code by means of the OWASP ASVS checklists )

- Code examples for secure coding

Your idea / Getting started

• Please send an email to [email protected] [[email protected]] or [email protected] [[email protected]] and we would love to tell you all about it! :-)

Expected Results

• Adding features to SKF project
• Adding more function examples to pre-development phase
• Adding/updating code examples ( PHP, Java, .NET, Go, Python, NodeJS and more )
• Adding/updating Knowledgebase items
• Adding CWE references to knowledgebase items
• Adding low/medium level verification testing guides for developers to teach how to manually verify the existence of injection/logic flaws. (pen-testing)

Knowledge Prerequisites

• For helping in the development of new features and functions Python flask would come in handy since the framework is written in python flask.
• For writing knowledgebase items only technical knowledge of application security is required
• For writing / updating code examples you need to know a programming language along with secure development.
• For writing the verification guide you need some penetration testing experience.

Mentors:

Riccardo ten Cate [1] Glenn ten Cate [2]