Code Sprint 2017 Ideas & Info

Goal

The OWASP Code Sprint 2017 is a program that aims to provide incentives to students to contribute to OWASP projects. By participating in the OWASP Code Sprint 2017 a student can get real life experience while contributing to an open source project. A student that successfully completes the program will receive in total $1500.

Program details

Projects that are eligible: All code/tools projects. Documentation projects are excluded.

Duration: 8 weeks of full-time coding engagement .

How it works

Any code/tool project can participate in the OWASP Code Sprint. Each project will be guided by an OWASP mentor. Students are evaluated in the middle and at the end of the coding period, based on success criteria identified at the beginning of the project. Successful students will receive $750 after each evaluation, a total of $1500 per student.

Projects are focused on developing security tools. It is required that the code any student produces for those projects will be released as Open Source.

Note on language: English is required for code comments and documentation, but not for interactions between students and advisers. Advisers who speak the same language as their students are encouraged to interact in that language.

How you can participate

As a student:

  1. Review the list of OWASP Projects currently participating in the OWASP Code Sprint 2017.
  2. Get in touch with the OWASP Project mentor of your choice.
  3. Agree deliverables with OWASP mentor.
  4. Work away during May thru September
  5. Rise to Open Source Development Glory :-)

[https://docs.google.com/forms/d/e/1FAIpQLSdAyBg5x9gapfLTL4Q_so7faNpR2QZmtuL3q4la2g5NZnhvyA/viewform ALL STUDENTS PLEASE APPLY HERE] ‘'’EXTENDED TO JUNE 18th!

As an OWASP Project Leader:

  1. Edit this page adding your project and some proposed tasks as per the examples
  2. Promote the initiative to your academic contacts

Timeplan

Phase 1: Proposals

Project leaders who want to include their project to the program should submit some initial proposal ideas on this page. These ideas serve as guidance to the students; they are things that project leaders would like to get done, like new features, improvements, etc.

Subsequently students are invited to submit detailed proposals that can (but do not necessarily have to) be based on these ideas. Students are strongly encouraged to engage with project leaders and each project’s community (e.g. through the project’s mailing list) in order to discuss the details of their proposal. Proposals should provide details about the implementation, time plan, milestones, etc.

Phase 2: Scoring of proposals

After the submission of proposals, project leaders and contributors/mentors are required to review the submitted proposals and score them (on a 1 to 5 scale). Each proposal should receive at least 3 assessments/scores from different mentors. Each mentor, contributor or leader can score only proposals for their OWN project. All assessments should provide justification. Reviewers are strongly encouraged to provide constructive comments for students so that they can improve in the future.

Project leaders are responsible to attract a sufficient number of volunteer mentors to score proposals and subsequently supervise those that will get selected.

Phase 3: Slot allocation

When proposal scoring has been completed, each project leader requests a specific number of slots. This number should be based on: The number of truly outstanding proposals according to submitted scores. The importance of the proposal to the project’s roadmap. The number of available mentors for the project. At least 2 mentors are needed for each proposal that gets accepted. If the total number of requested slots is less than or equal to the available number of slots, then all projects get the requested slots. If not, the following rules apply: All projects that have requested a slot get at least 1 slot, provided they have a high quality proposal and sufficient number of mentors. Two mentors are required per slot allocated to the project. The program’s administrators get in touch with project leaders, especially those that have requested a large number of slots to receive additional feedback on the requested slots and explore any available possibilities for reducing the requested number of slots. A project leader might choose to donate one or more requested slots back to the pool so that other projects can get more slots. The program administrators can choose to initiate a public discussion between projects in need of more slots and projects that have requested a lot of slots in order to determine the best possible outcome for everyone. If all else fails, slots are equally allocated to projects, i.e. all projects get 1 slot; projects that have requested 2 or more slots get an extra slot if available; projects that have requested 3 or more slots get an extra slot if available, etc. When there are no more slots available for all projects that have requested them a draw is used to allocate the remaining slots.

In any case, the program’s administrators should perform a final review of the selected proposals to ensure that they are of high quality. If concerns arise they should request additional information from project leaders.

Phase 4: Coding

This is the main phase of the program. Students implement their proposal according to the submitted timeplan and under the supervision of their mentors.

Evaluations

In the middle of the coding period, mentors should submit an evaluation of their students to ensure that they are on track and provide some feedback both to OWASP and the students.

If no/little progress has been made up to this point, the mentors could decide to fail the student in which case the student does not receive money. If successful, OWASP will pay half the amount ($750). The final evaluations are submitted at the end of the coding period and the second installment ($750) is paid to the student if all agreed deliverables are met. If the student has failed to demonstrate progress during the second period, then the second installment will not be paid and the student will get only half of the amount.

Deadlines

Program announcement: May 15 2017

Deadline for Student Applications: EXTENDED TO JUNE 18th!!

Proposal Evaluations: from: June 19 thru June 23 2017

Successful proposals announcement:: June 26, 2017

Bonding Period Announcement: June 26, 2017 - July 1, 2017

Coding Period Starts: July 3, 2017

Mid-term evaluations: Submitted from July 31, 2017 thru August 4, 2017

Coding Period Re-starts: August 7, 2017

Coding period ends: September 6, 2017

Final evaluations September 7, 2017 thru September 14, 2017

[https://docs.google.com/a/owasp.org/presentation/d/1PRrTzqsVEDgYl8Tcg34XJhksO0MrbXG0e-8VqCpAxOE/edit?usp=sharing Live Raffle on September 29th at 3:00 pm EST for an APPSEC USA or EU Complimentary Pass with a Funding initiative of the following

Recording:https://drive.google.com/open?id=0B3BoOR0oMwsseGx1VUFKWVlJc28 - Winner Sourav Badami !

Mailing List

Please subscribe to the following mailing list to receive updates or ask any particular questions

https://groups.google.com/a/owasp.org/forum/?hl=en#!forum/owasp-code-sprint-2017 OWASP Code Sprint 2017 Mailing list

Project Ideas

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 https://github.com/zaproxy/zaproxy/issues?q=is%3Aopen+is%3Aissue+label%3Aproject 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

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

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

SSRF Detector Integration

Currently ZAP does not detect SSRF vulnerabilities, due to the lack of this sort of service. https://ssrfdetector.com/ is an online service for detecting Server Side Request Forgery vulnerabilities (SSRF). It is developed and maintained by Jake Reynolds and is open source https://github.com/jacobreynolds/ssrfdetector

Expected Results

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

Zest Text Representation and Parser

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

Knowledge Prerequisite:

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

Support Java as a Scripting Language

It would be very useful to support Java in addition to the JSR223 scripting languages within the ZAP script console’.

It should be possible to provide much better auto complete support than will be possible with dynamically typed scripting languages.

Expected Results

Knowledge Prerequisite:

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

Bamboo Support

ZAP already has an official plugin for Jenkins https://plugins.jenkins.io/zap/.

It would be great if we also had similar integration for Bamboo https://www.atlassian.com/software/bamboo, https://en.wikipedia.org/wiki/Bamboo_(software)

Expected Results

Knowledge Prerequisite:

The Zest reference implementation is written in Java, so a good knowledge of this language is recommended. Some knowledge of CI/CD/Bamboo would be useful.

Mentors:

Simon Bennetts and the rest of the ZAP Core Team

Backslash Powered Scanner

This is a brand new technique developed by one of the Burp guys: http://blog.portswigger.net/2016/11/backslash-powered-scanning-hunting.html Their implementation is open source: https://github.com/PortSwigger/backslash-powered-scanner so hopefully shouldn’t be too hard to port to ZAP :)

Expected Results

Knowledge Prerequisite:

ZAP is written in Java, so a good knowledge of this language is recommended.

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

Expected Results

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

Brief Explanation:

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

Expected Results

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 Auritiand 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

###Your idea / Getting started

###Expected Results

###Knowledge Prerequisites

Mentors:

Riccardo ten Cate [mailto:[email protected]] Glenn ten Cate [mailto:[email protected]]

OWASP ZSC

Brief Explanation

OWASP ZSC is an open source software in Python language which lets you generate customized shellcodes and convert scripts to an obfuscated script. This software can be run on Windows/Linux/OSX under python https://www.owasp.org/index.php/OWASP_ZSC_Tool_Project

Getting started

Project Leaders

Expected Results

We have a list of potential modules we want to build To get familiar with the project, please check our installation and developer guidelines: https://www.gitbook.com/book/ali-razmjoo/owasp-zsc/details

Contact us through Github, send us a question: https://github.com/zscproject/OWASP-ZSC

Knowledge Prerequisites

OWASP ZSC is written in Python, so a good knowledge of this language and framework is recommended. For the shellcoding section knowledge of Assembly language required, and for the other sections, PHP, JavaScript, Ruby and other scripting languages would be useful.

Mentors:Patrik Patel, Ali Razmjoo

Please contact us through Github https://github.com/zscproject/OWASP-ZSC

OWASP Seraphimdroid mobile security project

Behavioral malware and intrusion analysis

Brief Explanation:

OWASP Seraphimdroid is an Android mobile app which already has a capability to statically analyze malware using machine learning (weka toolkit) relying on permissions. However, this is usually not enough and we intend to improve this with behavioral analysis. There are a number of paper in scientific literature describing how to detect malware and intrusions by dynamically analyzing its behavior (system calls, battery consumption, etc.). The idea of this project is to find the best approach that can be implemented on the device and implement it.

Expected Results

Knowledge Prerequisites:

Mentors:

Framework for plugin development

Brief Explanation:

OWASP Seraphimdroid is well rounded security and privacy app, however, it lacks some components community can provide. We would like to provide community the way to develop plugins that can add features to OWASP Seraphimdroid app. However, the way of integrating external components into Android app may be challenge. The way of presenting GUI and integration between processes need to be examined and developed.

Expected Results

Knowledge Prerequisites:

Mentors:

OWASP DefectDojo

Brief Explanation:

DefectDojo is a security automation and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, schedule scans, triage vulnerabilities and push findings into defect trackers.

Expected Results

Knowledge Prerequisites:

Getting started: * We have a http://defectdojo.readthedocs.io/en/latest/ Read the Docs Site

Mentors:

OWASP AppSensor

OWASP AppSensor Project The OWASP AppSensor project is a project to help you build self-defending applications through real-time event detection and response. Previous GSoC students have implemented key AppSensor contributions, and we’ve had very successful engagements. We look forward to hearing your ideas and hopefully working with you to execute them.

Machine Learning Driven Web Server Log Analysis

Brief Explanation:

The goal of this project would be to build a web server log analysis tool suite based on ML (machine learning). This tool suite will accept as input web server logs (apache, nginx) and will provide as output a determination of requests that are considered “attacks” There are a number of key points for this project:

Note that this project would extend work done in last year’s GSOC (https://timothy22000.github.io/event/gsoc-work-report.html) to get an initial machine learning capability developed.

Expected Results

Knowledge Prerequisite:

AppSensor is written in Java, so a good knowledge of this language is recommended. The toolset used previously for the ML effort was scala/spark, but this is not a hard requirement. The preference would be to use either the JVM (java/scala), or possibly python, as both of these stacks are well understood and have significant ML capabilities.

Mentors

John Melton and the rest of the AppSensor Team

Your Idea

Brief Explanation:

AppSensor is a great tool and many organizations are starting to use it. If you have an idea that is not on this list, please submit it - we would love to give you the chance to work on an idea you came up with!

Getting started

Expected Results

Knowledge Prerequisite:

AppSensor is written in Java, so a good knowledge of this language is recommended.

Mentors

John Melton and the rest of the AppSensor Team

OWASP OWTF

https://github.com/owtf/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.

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

Bonus:

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 Aranguren, Viyat Bhalodia, Bharadwaj Machiraju OWASP OWTF Project Leaders

OWASP OWTF - Report enhancements

Brief Explanation:

The current OWTF report is very interactive but it cannot be exported in its current form. A reporter service can be written (which was in the very early releases of OWTF) which exports a nice report with template, findings, and additional pentester’s notes into multiple formats. A small set of export formats should be supported such as:

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

Expected Results

Knowledge Prerequisite:

Python, React.JS and general JavaScript 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 Aranguren, Viyat Bhalodia, Bharadwaj Machiraju OWASP OWTF Project Leaders

OWASP OWTF - Distributed architecture

To be updated soon!

OWASP OWTF - Off-line HTTP traffic uploader

Brief Explanation:

Although it is awesome that OWTF runs a lot of tools on behalf of the user, there are situations where uploading the HTTP traffic of another tool off-line can be very interesting for OWTF, for example:

This project is about implementing an off-line utility able to parse HTTP traffic:

1) Figure out how to read output files from various tools like: skipfish, hoppy, w3af, arachni, etc. Nice to have: ZAP database, Burp database

2) Translate that into the following clearly defined fields:

3) IMPORTANT: Implement a plugin-based uploader system

4) IMPORTANT: Implement ONE plugin, that uploads that into the OWTF database

5) IMPORTANT: OWTF should ideally be able to invoke the uploader right after running a tool Example: OWTF runs skipfish, skipfish finishes, OWTF runs the HTTP traffic uploader, all skipfish data is pushed to the OWTF DB.

6) CRITICAL: The off-line HTTP traffic uploader should be smart enough to read + push 1-by-1 instead of stupidly trying to load everything into memory first, you have been warned! :)

Why? Because in a huge assessment, the output of "tool X" can be "10 GB", which is *stupid* to load into memory, this is OWTF, we *really* try to foresee the crash before it happens! ;)

CRITICAL: It is important to implement a plugin-based uploader system, so that other projects can benefit from this work (i.e. to be able to import third-party tool data to ZAP, Burp, and other tools in a similar fashion), and hence hopefully join us in maintaining this project moving forward.

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

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 Aranguren, Viyat Bhalodia, Bharadwaj Machiraju OWASP OWTF Project Leaders

OWASP Hackademic Challenges Project

OWASP Hackademic Challenges Project The 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.

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

ote: 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

Knowledge Prerequisites:

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

Mentors:[mailto:[email protected] Spyros Gasteratos] - Hackademic Challenges Project Leaders

Course Type Challenge

Brief Explanation:

We have a sandbox engine which allows for complex guided challenges to be implemented. We’d like to build a challenge that guides the user through a series of steps to an end goal and teaches more information on the subject matter on the way. This is a very open-ended project on purpose to allow creative student to come up with nice ideas. Bellow you will find some examples that we thought might be interesting.

Ideas on the project:

Getting started

Expected Results

Knowledge Prerequisites:

The technologies used.

Mentors: Spyros Gasteratos - Hackademic Challenges Project Leaders