OWASP Code Sprint 2017

Goal

The OWASP Summer Code Sprint 2017 is a program that aims to provide incentives to students to contribute to OWASP projects. By participating in the OWASP Summer Code Sprint 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: 2 months of full-time engagement.

How it works

Any code/tool project can participate in the OWASP Summer 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 Summer 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 Summer 2017.

5. Rise to Open Source Development Glory :-)

ALL STUDENTS PLEASE APPLY HERE >> FORM

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:

Deadline for Student Applications:

Proposal Evaluations: from

Successful proposals announcement:

Coding Period Starts:

Mid-term evaluations: Submitted from August 3rd until August 7th.

Coding period ends:

Final evaluations:

Mailing List

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

OWASP Summer Code Sprint Mailing List

Ideas

Hackademic Docker Sandboxed for challenges

Brief explanation:

Background problem to solve:

We are trying to enable users to freely upload vulnerable applications to the platform. After some research we concluded that writing a python application that uses docker to deploy challenges would be the best way to go about it. Also, we need to provide a frontend to manage the deployed containers and integrate our existing analytics gathering system into the dockerized challenges. The installer of the application should take care of initializing both the CMS and the containers without introducing too much complexity.

Proposed solution:

There is an easy to use python library for docker and there should be a frontend managing the containers we can use off the self with minimal modifications. The feature has already had a PoC using Linux containers, you can find it in the open merge requests of the project's GitHub page.

Expected results

• Integrate dockerized challenges in the platform.
• PEP-8 compliant code in all provided python code
• PSR compliant code in all PHP provided code
• Sphinx/phpdoc friendly comments
• Excellent reliability
• Good performance
• Unit tests / Functional tests
• Good documentation

Prerequisites

Some knowledge of test driven development, PHP, Python, Docker

OWASP Mentors

Spyros Gasteratos ([email protected]) and Paul Chaignon ([email protected]). criticality with MAX Impact vulnerabilities at the top (possibly: CVSS score in DESC order).