This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

GSOC2018 Ideas

From OWASP
Revision as of 09:16, 8 January 2018 by Delta24 (talk | contribs) (Added and edited the ideas for OWTF.)

Jump to: navigation, search

OWASP Project Requests

Tips to get you started in no particular order:

* Read Google Summer of Code Program(GSOC)
* Read the GSoC SAT 
* Read the GSOC Student Guidelines
* Contact us through the mailing list or irc channel.
* Check our github organization

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.

Zest Text Representation and Parser

Brief Explanation:

Zest is a graphical scripting language from the Mozilla Security team, and is used as the ZAP macro language.

A standardized text representation and parser would be very useful and help its adoption.

Expected Results:

  • A documented definition of a text representation for Zest
  • A parser that converts the text representation into a working Zest script
  • An option in the Zest java implementation to output Zest scripts text format

Getting started:

  • Have a look at the ZAP CONTRIBUTING.md file, especially the 'Coding section.
  • We like to see students who have already contributed to ZAP, so try fixing one of the bugs flagged as IdealFirstBug.

Knowledge Prerequisites:

  • The Zest reference implementation 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.

Expected Results:

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

Getting started:

  • Have a look at the ZAP CONTRIBUTING.md file, especially the 'Coding section.
  • We like to see students who have already contributed to ZAP, so try fixing one of the bugs flagged as IdealFirstBug.

Knowledge Prerequisites:

  • 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

SAMPLE: OWASP Hackademic Challenges

OWASP Hackademic Challenges Project helps you test your knowledge on web application security. You can use it to actually attack web applications in a realistic but also controllable and safe environment. After a wonderfull 2016 GSoC with 100 new challenges and a couple of new plugins we're mainly looking to get new features in and maybe a couple of challenges. Bellow is a list of proposed features.

REST API for the sandbox

Brief Explanation:

During the last summer code sprint Hackademic got challenge sandboxing in the form of vagrant and docker wrappers as well as an engine to start and stop the container or vm instances. What is needed now is a rest api which supports endpoint authentication and authorization which enables the sandbox engine to be completely independed from the rest of the project.

Ideas on the project: Since the sandbox is written in python, you will be using Django to implement the api. The endpoint authorization can be done via certificates or plain signature or username/password type authentication. We would like to see what's your idea on the matter. However the communication between the two has to be over a secure channel.

Expected Results:

  • A REST style api which allows an authenticated remote entity control the parts of the sandbox engine it has access to.
  • PEP8 compliant code
  • Acceptable unit test coverage

Getting started: Since this has been a popular project here's a suggestion on how to get started.

  • Check the excellent work done by mebjas and a0xnirudh in their respective brances in the project's repository
  • Take a brief look at the code and try to get a feeling of the functionality included. (Essentially it's CRUD operations on vms or containers)
  • Read on what Docker and Vagrant are and take a look at their respective py-libraries
  • If you think that contributing helps perhaps it would be a good idea to start with lettuce tests on the current CRUD operations of the existing functionality(which won't change and can eventually be ported to the final project)

Knowledge Prerequisites: Python, test driven development, some idea what REST is, some security knowledge would be preferable.

Mentors: Konstantinos PapapanagiotouSpyros Gasteratos - Hackademic Challenges Project Leaders

New CMS

Brief Explanation:

The CMS part of the project is really old and has accumulated a significant amount of technical debt. In addition many design decisions are either outdated or could be improved. Therefore it may be a good idea to leverage the power of modern web frameworks to create a new CMS. The new cms can be written in python using Django.

Expected Results:

  • New cms with same functionality as the old one (3 types of users -- student, teacher, admin--, 3 types of resources -- article challenge, class--, ACL type permissions, CRUD operations on every resource/user, all functionality can be extended by Plugins.
  • REST endpoints in addition to classic ones
  • tests covering all routes implemented, also complete ACL unit tests, it would be embarassing if a cms by OWASP has rights vulnerabilities.
  • PEP 8 code

Note: This is a huge project, it is ok if the student implements a part of it. However whatever implemented must be up to spec. If you decide to take on this project contact us and we can agree on a list of routes. If you don't decide to take on this project contact us. Generally contact us, we like it when students have insightful questions and the community is active


Getting Started:

  • Install and take a brief look around the old cms so you have an idea of the functionality needed
  • It's ok to scream in frustration
  • If you want to contribute to get a feeling of the platform a good idea would be lettuce tests for the current functionality (which won't change and you can port in the new cms eventually)

Knowledge Prerequisites: Python, Django, what REST is, the technologies used, some security knowledge would be nice.

Mentors: Konstantinos PapapanagiotouSpyros Gasteratos - Hackademic Challenges Project Leaders

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

Expected Results

Knowledge Prerequisites

  • For helping in the development of new features and functions you need Python flask and for the frond-end we use Angular 4.0
  • 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]

OWASP Nettacker

Brief Explanation

OWASP Nettacker project is created to automate information gathering, vulnerability scanning and eventually generating a report for networks, including services, bugs, vulnerabilities, misconfigurations, and other information. This software will utilize TCP SYN, ACK, ICMP and many other protocols in order to detect and bypass Firewall/IDS/IPS devices. By leveraging a unique method in OWASP Nettacker for discovering protected services and devices such as SCADA. It would make a competitive edge compared to other scanner making it one of the bests.

if you need more details please visit the GitHub page or contact a leader(Ali Razmjoo Qalaei, Reza Espargham).

Getting started

  • You may read the available documents in the wiki page. Developers and users documents are separated.

A Better Penetration Testing Automated Framework

Expected Results

  • Create more modules to the framework (web, network, IoT, etc.)
  • Create more categories to the framework (already has scan and brute)
  • Create API for the framework
  • Optimize the core (speed, hardware usage, user-friendly...)
  • Research and new methods and IDS/IPS detections.
  • Create a benchmark with other competitors frameworks
  • Improve documentation, languages and create a video library
  • Create GUI

Knowledge Prerequisites

  • The whole framework was written in Python language. You must be familiar with Python 2.x, 3.x.
  • Good knowledge of computer security (and penetration testing)
  • Knowledge of OS (Linux, Windows, Mac...) and Services
  • Familiar with IDS/IPS/Firewalls and ...
  • To develop the API you should be familiar with HTTP, Database...

Mentors

Mentors are: Ali Razmjoo Qalaei, Abbas Naderi Afooshteh

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 2018

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 user story])
  • 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

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:

Frontend Tech/Design Update

Brief Explanation:

Development of OWASP Juice Shop started in 2014 and was based on - back then - quite recent Javascript frontend framework AngularJS 1.x along with Bootstrap 3. Several major releases later, there now are Angular 5 and Bootstrap 4 available as well as other mature web frontend frameworks. Migrating the OWASP Juice Shop to the latest version of Angular and Bootstrap 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. Furthermore, the OWASP Juice Shop could greatly benefit from involvement of someone with UI/UX Design expertise. Individual product images would be lovely, too.

Expected Results:

  • High-level target client-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.
  • Iterative and incremental redesign of the UI/UX as well as the product image catalog

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

Knowledge Prerequisites:

  • Javascript, experience with latest Javascript frameworks for frontend, testing and building
  • Additional web and/or graphic design experience would be highly welcome

Mentors:

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

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 and NodeJS/Express, some security knowledge would be preferable.

Mentors:

OWASP OWTF

Offensive Web Testing Framework (OWTF) is a project focused on penetration testing efficiency and alignment of security tests to security standards like the OWASP Testing Guide (v3 and v4), the OWASP Top 10, PTES and NIST. Most of the ideas below focus on rewrite of some major components of OWTF to make it more modular. OWTF is moving to a fresh codebase with a fully Docker testing and deployment environment. If you want to get a jumpstart, check out https://github.com/owtf/owtf/tree/new-arch.

OWASP OWTF - MiTM proxy interception and replay capabilities

Brief Explanation:

The OWTF man-in-the-middle proxy is written completely in Python (based on the excellent Tornado framework) and was benchmarked to be the fastest MiTM python proxy. However it lacks the useful and much need interception and replay capabilities of mitmproxy (https://github.com/mitmproxy/mitmproxy).

The current implementation of the MiTM proxy serves its purpose very well. Its fast but its not extensible. There are a number of good use cases for being extensible

  • ability to intercept the transactions
  • modify or replay transaction on the fly
  • add additional capabilities to the proxy (such as session marking/changing) without polluting the main proxy code

Bonus:

  • Design and implement a proxy plugin (middleware) architecture so that the plugins can be defined separately and the user can choose what plugins to include dynamically (from the web interface).
  • Replace the current Requester (based on urllib, urllib2) with a more robust Requester based on the new urllib3 with support for a real headless browser factory. The typical flow when requested for an authenticated browser instance (using PhantomJS)
  • The "Requester" module checks if there is any login parameters provided (i.e form-based or script - look at https://github.com/owtf/login-sessions-plugin)
  • Create a browser instance and do the necessary login procedure
  • Handle the browser for the URI
  • When called to close the browser, do a clean logout and kill the browser instance.

Expected results:

Knowledge Prerequisite: Python proficiency, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn.

OWASP OWTF Mentors: Contact: Abraham ArangurenViyat BhalodiaBharadwaj Machiraju OWASP OWTF Project Leaders

OWASP OWTF - Web interface enhancements

Brief explanation:

The current web interface is a mixture of Tornado Jinja templates and ReactJS. A complete UI change to a stable ReactJS-based interface should be the deliverable for this project. Most of the hard part for the change has already been done and added in a separate branch at https://github.com/owtf/owtf/tree/ui-break.

For background on OWASP OWTF please see: https://www.owasp.org/index.php/OWASP_OWTF

Expected results:

  • IMPORTANT:Clean, maintainable (ES6 compatible and using recommended design patterns) React (JavaScript) code.
  • IMPORTANT: Thoroughly documented code along with API examples and example future components.
  • CRITICAL: Excellent reliability and performance.
  • Unit tests / Functional tests and easy to setup testing environment (preferably automated).

Knowledge Prerequisite: Python (reading API source code and endpoints), React.JS (high proficiency) and general JavaScript proficiency.

OWASP OWTF Mentors: Contact: Abraham ArangurenViyat BhalodiaBharadwaj Machiraju OWASP OWTF Project Leaders

OWASP OWTF - New plugin architecture

Brief explanation:

The current plugin system is not very useful and it is painful to browse many plugins. Most of the plugins do have much code and most of is repeated - much refactoring needed there.

This issue is documented in detail at https://github.com/owtf/owtf/issues/905.

For background on OWASP OWTF please see: https://www.owasp.org/index.php/OWASP_OWTF

Expected results: