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

Difference between revisions of "OWASP Code Sprint 2017"

From OWASP
Jump to: navigation, search
(Created page with "== OWASP Summer Code Sprint 2015 == == Goal == The OWASP Summer Code Sprint 2015 is a program that aims to provide incentives to students to contribute to OWASP projects. B...")
 
(→‎Deadlines)
 
(46 intermediate revisions by 7 users not shown)
Line 1: Line 1:
−
== OWASP Summer Code Sprint 2015 ==
+
== '''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.
  
−
== Goal ==
+
== '''Program details''' ==
−
 
 
−
The OWASP Summer Code Sprint 2015 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.
 
''Projects that are eligible:'' All code/tools projects. Documentation projects are excluded.
  
−
''Duration:'' 2 months of full-time engagement.
+
''Duration:'' 8 weeks of full-time coding engagement .
  
−
== How it works ==
+
== '''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.
+
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.  
 
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.  
Line 19: Line 16:
 
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.  
 
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 ==
+
== '''How you can participate''' ==
  
 
=== As a student: ===
 
=== As a student: ===
  
−
1. Review the list of OWASP Projects currently participating in the OWASP Summer Code Sprint 2015.
+
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.
 
2. Get in touch with the OWASP Project mentor of your choice.
Line 29: Line 26:
 
3. Agree deliverables with OWASP mentor.  
 
3. Agree deliverables with OWASP mentor.  
  
−
4. Work away during Summer 2015.
+
4. Work away during May thru September
  
 
5. Rise to Open Source Development Glory :-)
 
5. Rise to Open Source Development Glory :-)
  
−
ALL STUDENTS PLEASE APPLY HERE >> [http://goo.gl/forms/jUFTcXVDEY FORM]
+
=== [https://docs.google.com/forms/d/e/1FAIpQLSdAyBg5x9gapfLTL4Q_so7faNpR2QZmtuL3q4la2g5NZnhvyA/viewform ALL STUDENTS PLEASE APPLY HERE] '''EXTENDED TO JUNE 18th!''' ===
  
 
=== As an OWASP Project Leader: ===
 
=== As an OWASP Project Leader: ===
Line 41: Line 38:
 
2. Promote the initiative to your academic contacts
 
2. Promote the initiative to your academic contacts
  
−
== Timeplan ==
+
== '''Timeplan''' ==
  
 
'''Phase 1: Proposals'''
 
'''Phase 1: Proposals'''
Line 74: Line 71:
 
of their mentors.
 
of their mentors.
  
−
== Evaluations ==
+
== '''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.
 
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.
 
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!!''' 
  
−
== Deadlines ==
+
Proposal Evaluations: from: '''June''' '''19 thru June 23  2017'''
−
Program announcement: June 19th, 2015
 
  
−
Deadline for Student Applications: July 3rd, 2015
+
Successful proposals announcement:: '''June 26, 2017'''
  
−
Proposal Evaluations: from July 6th until July 10th.
+
Bonding Period Announcement: June 26, 2017 - July 1, 2017
  
−
Successful proposals announcement: July 10th, 2015
+
Coding Period Starts: '''July 3, 2017'''
  
−
Coding Period Starts: July 13th, 2015
+
Mid-term evaluations: Submitted from :'''July 31, 2017  thru  August 4, 2017'''
  
−
Mid-term evaluations: Submitted from August 3rd  until August 7th.
+
Coding Period Re-starts: August 7, 2017
  
−
Coding period ends: August 28th, 2015.
+
Coding period ends: '''September 6, 2017'''
  
−
Final evaluations: Until September 4th, 2015.
+
Final evaluations:'''September 7, 2017 thru September 14, 2017'''
  
−
== Mailing List ==
+
[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:'''
−
Please subscribe to the following mailing list to receive updates or ask any particular questions:
 
  
−
[https://groups.google.com/d/forum/owasp-summer-code-sprint OWASP Summer Code Sprint Mailing List]
+
'''Recording:https://drive.google.com/open?id=0B3BoOR0oMwsseGx1VUFKWVlJc28 - Winner Sourav Badami !'''
 +
* '''$550.00 for Airfare or Transportation'''
 +
* '''3 Nights of Hotel Accommodations'''
 +
* '''Must attend the  2 day Project Summit 2018 Sessions'''
 +
* '''All done by reimbursement process along with receipts'''
  
−
== Ideas ==
+
== '''Mailing List''' ==
 +
'''Please subscribe to the following mailing list to receive updates or ask any particular questions:'''
  
−
=== OWASP Hackademic ===
+
[https://groups.google.com/a/owasp.org/forum/?hl=en#!forum/owasp-code-sprint-2017 '''OWASP Code Sprint 2017 Mailing list''']
  
−
=== Hackademic Docker Sandboxed for challenges ===
+
== '''Project Ideas''' ==
 +
== OWASP ZAP ==
  
−
''' Brief explanation: '''
+
[[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.
  
−
Background problem to solve:
+
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.
  
−
We are trying to enable users to freely upload vulnerable applications to the platform.  
+
=== Field Enumeration ===
−
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.
+
: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 installer of the application should take care of initializing both the CMS and the containers without introducing too much complexity.
+
:
 +
: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 [https://github.com/zaproxy/zaproxy/wiki/DevGuidelines 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 '''
 +
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:[email protected] @] and the rest of the ZAP Core Team
 +
:
  
−
Proposed solution:
+
=== 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 [https://github.com/zaproxy/zaproxy/wiki/DevGuidelines 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:'''
 +
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:[email protected] @] and the rest of the ZAP Core Team
  
−
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.
+
=== SSRF Detector Integration ===
−
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.
+
:
 +
: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 '''
 +
:* Extend ZAP to detect SSRF vulnerabilities and interact with other services such as outlined above.
 +
:* Code that conforms to our [https://github.com/zaproxy/zaproxy/wiki/DevGuidelines 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:'''
 +
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:[email protected] @] and the rest of the ZAP Core Team
  
−
''' Expected results '''
+
=== 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 '''
 +
:* 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
 +
:
 +
:''' 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:'''
 +
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:[email protected] @] and the rest of the ZAP Core Team
  
−
* Integrate dockerized challenges in the platform.
+
=== Support Java as a Scripting Language ===
−
* PEP-8 compliant code in all provided python code
+
:
−
* PSR compliant code in all PHP provided code
+
:It would be very useful to support Java in addition to the JSR223 scripting languages within the ZAP script console'.
−
* Sphinx/phpdoc friendly comments
+
:
−
* Excellent reliability
+
:It should be possible to provide much better auto complete support than will be possible with dynamically typed scripting languages.
−
* Good performance
+
:
−
* Unit tests / Functional tests
+
:''' Expected Results '''
−
* Good documentation
+
:* The ability to run Java code in the ZAP Script Console to the same leval as other supported scripting languages
 +
:* Templates for all of the current script types
 +
:* Optionally auto complete supported
 +
:
 +
:''' 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:'''
 +
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:[email protected] @] and the rest of the ZAP Core Team
  
−
''' Prerequisites '''
+
=== Bamboo Support ===
 +
:
 +
:ZAP already has an official plugin for Jenkins (https://wiki.jenkins-ci.org/display/JENKINS/zap+plugin).
 +
:
 +
: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 '''
 +
:* Facilitate the invocation and configuration of various ZAP functionalities from Bamboo CI. Including (but not limited to):
 +
::*Manage Sessions (Loading/Persisting)
 +
::*Define Context (Name, Include & Exclude URLs)
 +
::* Attack Contexts (Spider, Ajax Spider, Active Scan)
 +
::* Setup Autentication (Formed or Script Based)
 +
::* Generate Reports
 +
:* Templates for all of the current script types
 +
:* Optionally auto complete supported
 +
:
 +
:''' 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:'''
 +
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:[email protected] @] and the rest of the ZAP Core Team
  
−
Some knowledge of test driven development, PHP, Python, Docker
+
=== 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 '''
 +
:* Extend ZAP's active scanner to leverage Backslash type scanning.
 +
:* Code that conforms to our [https://github.com/zaproxy/zaproxy/wiki/DevGuidelines Development Rules and Guidelines]
 +
:
 +
:''' Knowledge Prerequisite: '''
 +
:ZAP is written in Java, so a good knowledge of this language is recommended.
 +
:
 +
:'''Mentors:'''
 +
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:[email protected] @] and the rest of the ZAP Core Team
  
−
''' OWASP Mentors '''
+
=== 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 [https://github.com/zaproxy/zaproxy/wiki/DevGuidelines 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:'''  
 +
:[https://www.owasp.org/index.php/User:Psiinon Simon Bennetts] [mailto:[email protected] @] and the rest of the ZAP Core Team
 +
:
  
−
Spyros Gasteratos ([email protected]) and Paul Chaignon ([email protected]).
+
== BLT  ==
  
 +
'''Brief Explanation:'''
  
−
=== Hackademic: JavaScript Based Development Challenges ===
+
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.
  
−
Brief explanation:
+
''' Getting started '''
−
Background Problem to solve:
+
* Get in touch with us :)
  
−
We are looking for challenges which are aimed towards secure coding.
+
'''Expected Results:'''
−
The user should be served with a piece of vulnerable JavaScript which fails the unit tests provided.
+
* A new feature that makes Bugheist even better
−
The user has to fix the vulnerability in a way that makes the unit tests pass.
 
  
−
Example Solution of one of the challenges:
 
−
Provide the user with the following code:
 
−
''
 
−
function sayHi(string userInput){
 
−
var hiField = document.getElementById("hiField");
 
−
hiField.innerHtml = userInput;
 
−
}
 
−
''
 
−
Use any JavaScript unit - testing framework to design a set of unit tests which call the function with all sorts of payloads and test if the user seems to have escaped userInput correctly,
 
−
we're not looking for completeness a solid proof of concept implementation for future reference is acceptable.
 
  
−
''' 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.
  
−
A complete implementation of challenges covering the top 10 according to our coding standards.
+
'''Mentors:'''
 +
[https://www.owasp.org/index.php/User:Sauriti Sean Auriti] [mailto:[email protected] @] and the rest of the BLT Core Team
  
−
''' OWASP Mentors '''
 
  
−
Spyros Gasteratos ([email protected]) and Paul Chaignon ([email protected]).
 
  
 +
== OWASP Security Knowledge framework ==
  
−
=== Hackademic - Migrate old code to the new coding standards ===
+
===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.
  
−
'''Brief Explanation'''
+
'''In a nutshell'''  
  
−
In the last project summit we decided to introduce code style and standards compliance checking for new commits and slowly migrate the old ones to the new setting.
+
- Training developers in writing secure code
−
We also decided to prefer contributions with unit tests.
 
  
−
So far we have a testing framework which allows us to setup and test things easily and thus makes writing new tests less painful, but the tests cover only a few files and we don't provide line coverage yet.
+
- Security support pre-development ( Security by design, early feedback of possible security issues )
−
We want coverage reports and as much line coverage as possible.
 
  
−
We're looking for someone to assist in this migration.
+
- Security support post-development ( Double check your code by means of the OWASP ASVS checklists )
  
−
''''What you will have to do'''
+
- Code examples for secure coding
  
−
* Introduce PSR-4 autoloading
+
===Your idea / Getting started===
−
* Migrate all the existing code into PSR-1, PSR-2 naming and code style
+
* Please send an email to [email protected] [[email protected]] or [email protected] [glenn.ten.cate@owasp.org] and we would love to tell you all about it! :-)
−
* Use tools like php_codeSniffer to automate the checks for standards compliance
 
−
* If necessary, automate the use of these tools with pre-commit hooks and create a "Check everything" script
 
−
* Add code coverage reports into the testing pipeline.
 
−
* Add the remaining tests.
 
−
* Write a travis.yml file to integrate the platform to Travis CI.
 
  
−
''' Knowledge Prerequisites '''
+
===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)
  
−
* PHP and bash experience
+
===Knowledge Prerequisites===
−
* Writing unit and functional tests
 
−
* Familiarity with Git is a plus
 
−
* Familiar or willing and able to quickly learn concepts like autoloading, the PSR standard, the sniff file syntax and Travis CI
 
  
−
''' Mentor '''
+
* 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.
  
−
Spyros Gasteratos ([email protected]) and Paul Chaignon ([email protected]).
+
'''Mentors:'''
  
 +
Riccardo ten Cate [mailto:[email protected]]
 +
Glenn ten Cate [mailto:[email protected]]
  
−
=== Hackademic: New Frontend ===
+
== OWASP ZSC ==
  
−
'''Brief Explanation'''
+
=== 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
  
−
Our current theme is written using Smarty Templates and basic HTML/CSS.
+
=== Getting started  ===
−
It covers all of the platform's functionality but it's  from 2012 and it needs both visual and usability improvements.
+
* Get in touch with us on Github:
 +
https://github.com/zscproject/OWASP-ZSC
  
−
Your job will be to design and implement a new shiny theme using the latest in frontend technology.
+
'''Project Leaders'''
 +
*https://www.owasp.org/index.php/User:Ali_Razmjoo
 +
*https://www.owasp.org/index.php/User:Johanna_Curiel
  
−
'''Expected Results'''
+
=== 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
  
−
* Come up with suggestions on which parts of the current frontend need usability improvements.
+
Contact us through Github, send us a question:
−
* Write the new smarty-based template using the CSS and JavaScript frameworks you thing necessary.
+
https://github.com/zscproject/OWASP-ZSC
−
* Code must be consistent with JavaScript and CSS coding standards and style.
 
  
−
''' Knowledge Prerequisites '''
+
* New obfuscation modules
 +
* New shellcodes for OSX and Windows
  
−
* Experience in JavaScript, CSS + experience or willing and able to learn  Frameworks such as bootstrap, foundation, semantic UI or Angular, jQuery, etc.
+
=== Knowledge Prerequisites ===
−
* Experience in web design and implementation
+
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.
  
−
''' OWASP Mentors '''
+
'''Mentors:''' Patrik Patel, Ali Razmjoo
 +
Please contact us through Github
 +
https://github.com/zscproject/OWASP-ZSC
  
−
Spyros Gasteratos ([email protected]) and Paul Chaignon ([email protected]).
 
  
  
 +
== OWASP Seraphimdroid mobile security project ==
  
−
=== OWASP OWTF  ===
 
  
 +
=== Behavioral malware and intrusion analysis  ===
  
−
=== OWASP OWTF - VMS - OWTF Vulnerability Management System ===
+
'''Brief Explanation:'''
  
−
'''Brief explanation:'''
+
[[OWASP_SeraphimDroid_Project|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.
  
−
Background problem to solve:
+
'''Expected Results:'''
  
−
We are trying to reduce the human work burden where there will be hundreds of issues listing apache out of date or php out of date.
+
*  Reviewing scientific literature and find feasible approach we can take
 +
*  Implement and possibly improve the approach in Seraphimdroid
 +
*  Test the model and provide controls to switch algorithm on or off and possibly fine tune it
 +
*  Documenting approach as a technical report
  
−
Proposed solution:
+
'''Knowledge Prerequisites:'''
 +
* Java
 +
* Android
 +
* CSV, XML
 +
* Basic knowledge and interest in machine learning
  
−
We can meta aggregate these duplicate issues into one issue of "outdated software / apache / php detected". with XYZ list of issues in them.
+
'''Mentors:'''
 +
* [[User:Nikola_Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader
  
 +
=== Framework for plugin development  ===
  
−
A separate set of scripts that allows for grouping and management of vulnerabilities (i.e. think huge assessments), to be usable *both* from inside + outside of OWTF in a separate sub-repo here: https://github.com/owtf
+
'''Brief Explanation:'''
  
−
VMS will have the following features:
+
[[OWASP_SeraphimDroid_Project|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.  
−
* Vulnerability correlation engine which will allow for quick identification of unique vulnerability and deduplication.
 
−
* Vulnerability table optimization : combining redundant vulnerabilities like example : PHP <5.1 , PHP < 5.2 , PHP < 5.3 all suggest upgrade php so if multiple issues are reported they should be combined.
 
−
* Integration with existing bug tracking system like example bugzilla, jira : Should not be too hard as all such system have one or the other method exposed (REST API or similar)
 
−
* Fix Validation : Since we integrate with bug tracking once dev fixed the bug and code deployed we can run specific checks via * OWTF or other tool (may be specific nessus or nexpose plugin or similar.)
 
−
* Management Dashboard : Could be exposed to Pentester, Higher Management where stats are shown with lesser details but more of high level overview.
 
  
−
[http://www.slideshare.net/null0x00/nessus-and-reporting-karma Similar previous work for Nessus]
+
'''Expected Results:'''
  
 +
*  Examining the way of integrating third party apps through some provided API to OWASP Seraphimdroid
 +
*  Providing GUI integration with third party components
 +
*  Develop at least one test plugin
 +
*  Document the development process and API
  
−
For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]
+
'''Knowledge Prerequisites:'''
 +
* Java
 +
* Android
 +
* CSV, XML
  
 +
'''Mentors:'''
 +
* [[User:Nikola_Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader
  
−
'''Expected results:'''
+
== OWASP DefectDojo ==
  
−
* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
+
'''Brief Explanation:'''
−
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
 
−
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
 
−
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
 
−
* Good performance
 
−
* Unit tests / Functional tests
 
−
* Good documentation
 
  
 +
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.
  
−
'''Knowledge Prerequisite:'''
+
'''Expected Results:'''
  
−
Python and bash experience would be beneficial, some previous exposure to security concepts and penetration testing is welcome but not strictly necessary as long as there is will to learn
+
*  Multiple opportunities for students to get involved with DefectDojo ranging in difficulty from easy to advanced
 +
*  Students will receive hands-on experience in a full-stack software development project
 +
*  Students will have the opportunity to work on a project with multiple moving parts and third-party interactions
  
 +
'''Knowledge Prerequisites:'''
 +
* Python
 +
* HTML, Bootstrap
  
−
'''OWASP OWTF Mentor:'''
+
''' Getting started: '''
 +
* We have a [http://defectdojo.readthedocs.io/en/latest/ Read the Docs Site]
  
−
Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: [email protected], [email protected]
 
  
−
=== OWASP OWTF - HTTP Request Translator Improvements ===
+
'''Mentors:'''
 +
* [[User:devgreg|Greg Anderson]] - OWASP DefectDojo Project Leader
  
−
'''Brief explanation:'''
+
== OWASP AppSensor ==
  
−
Problem to solve:
+
[[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.
  
−
There are many situations in web app pentests where just no tool will do the job and you need to script something, or mess around with the command line (classic example: sequence of steps where each step requires input from the previous step). In these situations, translating an HTTP request or a sequence of HTTP requests, takes valuable time which the pentester might just not really have.
+
=== 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:
 +
:* Almost everybody has web server logs. It's a common format that is well understood, and is a good starting place for many security teams
 +
:* Because the format is well understood, the data points (features) are well understood.
 +
:* This tool suite would have applicability far beyond just our project. The goal is to give away a tool that can process a set of log files, build a custom model for the traffic, and then be used to process future log files and find attacks (outliers / anomalies)
 +
:
 +
: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 '''
 +
:* User provides tool suite a set of web server logs (User has option to annotate data set with known attacks)
 +
:* System is pre-coded with knowledge of certain anomalous patterns (attacks)
 +
:* System builds ML model for processing future log files
 +
:* System provides mechanism for processing future logs using trained model.
 +
:
 +
:''' 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 '''
 +
:[https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:jtmelton@gmail.com @] and the rest of the AppSensor Team
 +
:
  
−
Proposed solution:
+
=== 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 '''
 +
:* Get in touch with us :)
 +
:
 +
:'''Expected Results:'''
 +
:* A new feature that makes AppSensor even better
 +
:
 +
:''' Knowledge Prerequisite: '''
 +
:AppSensor is written in Java, so a good knowledge of this language is recommended.
 +
:
 +
:''' Mentors '''
 +
:[https://www.owasp.org/index.php/User:John_Melton John Melton] [mailto:[email protected] @] and the rest of the AppSensor Team
 +
:
  
−
An HTTP request translator, a *standalone* *tool* that can:
+
== 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.
  
−
1) Be used from inside OR outside of OWTF.
+
=== OWASP OWTF - MiTM proxy interception and replay capabilities ===
  
−
2) Translate raw HTTP requests into curl commands or bash/python/php/ruby/PowerShell scripts
+
'''Brief Explanation:'''
−
 
 
−
3) Provide essential quick and dirty transforms: base64 (encode/decode), urlencode (encode/decode)
 
−
* Transforms with boundary strings? (TBD)
 
−
* Individually or in bulk? (TBD)
 
−
 
 
−
'''Essential Function: "--output" argument'''
 
−
 
 
−
CRITICAL: The command/script should be generated so that the request is sent as literally as possible.
 
−
 
 
−
Example: NO client specific headers are sent. IF the original request had "User-Agent: X", the generated command/script should have EXACTLY that (i.e. NOT a curl user agent, etc.). Obviously, the same applies to ALL other headers.
 
−
 
 
−
NOTE: Ideally the following should be implemented using an extensible plugin architecture (i.e. NEW plugins are EASY to add)
 
−
* http request in => curl command out
 
−
* http request in => bash script out
 
−
* http request in => python script out
 
−
* http request in => php script out
 
−
* http request in => ruby script out
 
−
* http request in => PowerShell script out
 
−
 
 
−
'''Basic additional arguments:'''
 
−
 
 
−
- "--proxy" argument: generates the command/script with the relevant proxy option
 
−
 
 
−
NOTE: With this the command/script may send requests through a MiTM proxy (i.e. OWTF, ZAP, Burp, etc.)
 
−
 
 
−
- "--string-search" argument: generates the command/script so that it:
 
−
 
 
−
1) performs the request
 
−
 
 
−
2) then searches for something in the response (i.e. literal match)
 
−
 
 
−
- "--regex-search" argument: generates the command/script so that it:
 
−
1) performs the request
 
−
 
 
−
2) then searches for something in the response (i.e. regex match)
 
−
 
 
−
'''OWTF integration'''
 
−
 
 
−
The idea here, is to invoke this tool from:
 
−
 
 
−
1) Single HTTP transactions:
 
−
 
 
−
For example, have a button to "export http request" + then show options equivalent to the flags
 
−
 
 
−
2) Multiple HTTP transactions:
 
−
 
 
−
Same as with Single transactions, but letting the user "select a number of transactions" first (maybe a checkbox?).
 
−
 
 
−
 
−
'''Desired input formats:'''
 
−
 
 
−
* Read raw HTTP request from stdin -Suggested default behaviour! :)-
 
−
 
 
−
Example: cat path/to/http_request.txt | http-request-translator.py --output
 
−
 
 
−
* Interactive mode: read raw HTTP request from keyboard + "hit enter when ready"
 
−
 
 
−
Suggestion: This could be a "-i" (for "interactive") flag and/or the fallback option when "stdin is empty"
 
−
 
 
−
Example:
 
−
 
 
−
1) User runs tool with desired flags (i.e. "--output ruby --proxy 127.0.0.1:1234 ...", etc.)
 
  
−
2) Tool prints: "Please paste a raw HTTP request and hit enter when ready"
+
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).
  
−
3) User pastes a raw HTTP requests + hits enter
+
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
  
−
4) Tool outputs whatever is relevant for the flags + http request given
+
* 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
  
−
* For bulk processing: Maybe a directory of raw http request files?
+
Bonus:  
  
−
'''Nice to have: Transforms'''
+
* 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)
−
In the context of translating raw HTTP requests into commands/scripts, what we want here is to provide some handy "macros" so that the relevant command/script is generated accordingly.
 
−
 
 
−
Example:
 
−
 
 
−
NOTE: Assume something like the following arguments: "--transform-boundary=@@@@@@@ --transform-language=php"
 
−
 
 
−
Step 1) The user provides a raw HTTP request like this:
 
−
 
 
−
  GET /path/to/urlencode@@@@@@@abc d@@@@@@@/test
 
−
  Host: target.com
 
−
  ...
 
−
 
 
−
Step 2) The tool generates a bash script like the following:
 
−
 
 
−
  #!/bin/bash
 
−
 
 
−
  PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));")
 
−
  curl ...... "http://target.com/path/to/$PARAM1/test"
 
−
 
 
−
 
 
−
OR a "curl command" like the following:
 
−
  PARAM1=$(echo 'abc d' | php -r "echo urlencode(fgets(STDIN));"); curl ...... "http://target.com/path/to/$PARAM1/test"
 
−
 
 
−
 
 
−
This feature can be valuable to shave a bit more time in script writing.
 
−
 
 
−
 
 
−
For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]
 
  
 +
* 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:'''
 
'''Expected results:'''
Line 406: Line 496:
 
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
 
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
 
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
 
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
−
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
+
* CRITICAL: Excellent reliability
 
* Good performance
 
* Good performance
 
* Unit tests / Functional tests
 
* Unit tests / Functional tests
 
* Good documentation
 
* Good documentation
−
 
  
 
'''Knowledge Prerequisite:'''
 
'''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.
  
−
Python and bash experience would be beneficial, 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: [mailto:[email protected] Abraham Aranguren][mailto:[email protected] Viyat Bhalodia][mailto:[email protected] Bharadwaj Machiraju] OWASP OWTF Project Leaders
−
 
 
−
'''OWASP OWTF Mentor:'''
 
−
 
 
−
Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: [email protected], [email protected]
 
  
−
=== OWASP OWTF - JavaScript Library Sniper Improvements ===
+
=== OWASP OWTF - Report enhancements ===
  
 
'''Brief explanation:'''
 
'''Brief explanation:'''
−
This is a project that tries to resolve a very common problem during penetration tests:
 
−
 
−
The customer is running a number of outdated JavaScript Libraries, but there is just not enough time to determine if something useful -i.e. something *really* bad! :)- can be done with that or not.
 
−
 
−
 
−
To solve this problem, we propose a *standalone* *tool* that can:
 
−
 
−
1) Be run BOTH from inside AND outside of OWTF
 
−
 
−
2) Build and *update* a fingerprint JavaScript library database of:
 
−
* Library File hashes => JavaScript Library version
 
−
* Library File lengths => JavaScript Library version
 
−
* (Nice to have:) As above, but for each individual github commit (possible drawback: too big?)
 
−
 
−
3) Build and *update* a vulnerability database of:
 
−
* JavaScript Library version => CVE - CVSS score - Vulnerability info
 
−
 
−
4) Given a [ JavaScript file OR hash OR length ], found in the database, provides:
 
−
* JavaScript Library version
 
−
* List of vulnerabilities sorted in descending CVSS score order
 
−
 
−
5) (very cool to have) Given a list of JavaScript files (maybe a directory), provides:
 
−
* ALL Library/vulnerability matches described on 4)
 
−
 
−
Once the standalone tool is built and verified to be working, OWTF should be able to:
 
  
−
Feature 1) GREP plugin improvement (Web Application Fingerprint):
+
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:
  
−
Step 1) Lookup file lengths and hashes in the "JavaScript library database"
+
* HTML (pure static html here)
−
 
+
* PDF
−
Step 2) If a match is found: provide the list of known vulnerabilities against "JavaScript library X" to the user
+
* XML (for processing)
−
 
+
* JSON (for processing)
−
Feature 2) SEMI-PASSIVE plugin improvement (Web Application Fingerprint):
 
−
 
 
−
1) Requests all referenced BUT missing JavaScript files -i.e. scanners won't load JavaScript files! :)-
 
−
 
 
−
2) re-runs the GREP plugin on the new files (i.e. to avoid missing vulns due to unrequested JavaScript files)
 
−
 
 
−
Potential projects worth having a look for potential overlap/inspiration:
 
−
* [https://owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Check?]
 
−
 
 
−
How many JavaScript libraries should be included?
 
−
* As many as possible, but especially the major ones: jQuery, knockout, etc.
 
−
* "Nirvana" Nice to have: ALL Individual versions of ALL JavaScript files from ALL opensource projects, (ideally) even if the project is not a JavaScript library -i.e. JavaScript files from Joomla, Wordpress, etc.-
 
−
 
 
−
Common JavaScript library fingerprinting techniques include:
 
−
* Parse the JavaScript file and grab the version from there
 
−
* Determine the JavaScript version based on a hash of the file
 
−
* Determine the JavaScript version based on the length of the file
 
−
 
 
−
Other Challenges:
 
−
* "the file" could be "the minimised file", "the expanded file" or even "a specific JavaScript file from Library X"
 
−
* When the JavaScript file does not match a specific version:
 
−
1) The commit that matches the closest should (ideally) be found
 
−
2) The NEXT library version after that commit (if present) should be found
 
−
3) From there, it is about reusing the knowledge to figure out public vulnerabilities, CVSS scores, etc. again
 
−
 
 
−
For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]
 
  
 +
For background on OWASP OWTF please see: https://www.owasp.org/index.php/OWASP_OWTF
  
 
'''Expected results:'''
 
'''Expected results:'''
Line 489: Line 525:
 
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
 
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
 
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
 
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
−
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
+
* CRITICAL: Excellent reliability
 
* Good performance
 
* Good performance
 
* Unit tests / Functional tests
 
* Unit tests / Functional tests
 
* Good documentation
 
* Good documentation
−
 
  
 
'''Knowledge Prerequisite:'''
 
'''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.
  
−
Python and bash experience would be beneficial, 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: [mailto:[email protected] Abraham Aranguren][mailto:[email protected] Viyat Bhalodia][mailto:[email protected] Bharadwaj Machiraju] OWASP OWTF Project Leaders
  
 +
=== OWASP OWTF - Distributed architecture ===
  
−
'''OWASP OWTF Mentor:'''
+
To be updated soon!
  
−
Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: [email protected], [email protected]
 
  
 
=== OWASP OWTF - Off-line HTTP traffic uploader ===
 
=== OWASP OWTF - Off-line HTTP traffic uploader ===
Line 542: Line 579:
  
  
−
For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]
+
For background on OWASP OWTF please see: https://www.owasp.org/index.php/OWASP_OWTF
  
  
Line 550: Line 587:
 
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
 
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
 
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
 
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
−
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
+
* CRITICAL: Excellent reliability
 
* Good performance
 
* Good performance
 
* Unit tests / Functional tests
 
* Unit tests / Functional tests
 
* Good documentation
 
* Good documentation
−
 
  
 
'''Knowledge Prerequisite:'''
 
'''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.
  
−
Python and bash experience would be beneficial, 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: [mailto:[email protected] Abraham Aranguren][mailto:[email protected] Viyat Bhalodia][mailto:[email protected] Bharadwaj Machiraju] OWASP OWTF Project Leaders
−
 
 
−
'''OWASP OWTF Mentor:'''
 
−
 
 
−
Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: [email protected], [email protected]
 
−
 
 
−
=== OWASP OWTF - Health Monitor ===
 
−
 
 
−
'''Brief explanation:'''
 
−
 
 
−
In some cases, especially on large assessments (think: > 30 URLs) a number of things often go wrong and OWTF needs to recover from everything, which is difficult.
 
−
 
 
−
For this reason, OWTF needs an independent module, which is completely detached from OWTF (a different process), to ensure the health of the assessment is in check at all times, this includes the following:
 
−
 
 
−
'''Feature 1) Alerting mechanisms'''
 
  
−
When any of the monitor alerts (see below) is triggered. The OWTF user will be notified immediately through ALL of the following means:
 
−
* Playing an mp3 song (both local and possibly remote locations)
 
−
* Scan status overview on the CLI
 
−
* Scan status overview on the GUI
 
  
−
NOTE: A configuration file from where the user can enable/disable/configure all these mechanisms is desired.
+
== OWASP Hackademic Challenges Project ==
  
−
'''Feature 2) Corrective mechanisms'''
+
[[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.
  
−
Corrective mechanisms are also expected in this project, these will be accomplished sending OWTF api messages such as:
+
=== New CMS ===
−
* Stop this tool
 
−
* Freeze this process (to continue later)
 
−
* Freeze the whole scan (to continue later)
 
−
 
 
−
Additional mechanisms:
 
−
* Show a ranking of files that take the most space
 
−
 
 
−
'''Feature 3) Target monitor'''
 
−
 
 
−
Brief overview:
 
−
 
 
−
All target URLs are checked for availability periodically (i.e. once x 5 minutes?), if a URL in scope goes down the pentester is alerted (see above).
 
−
 
 
−
Potential approach: Check if length of 1st page changes every 60 seconds.
 
−
 
 
−
NOTE: It might be needed to change this on the fly.
 
−
 
 
−
More background
 
−
 
 
−
Consider the following scenario:
 
−
 
 
−
Current Situation aka "problem to solve":
 
−
 
 
−
1) Website X goes down during a scan
 
−
 
 
−
2) the customer notices
 
−
 
 
−
3) the customer tells the boss
 
−
 
 
−
4) the boss tells the pentester
 
−
 
 
−
5) the pentester stops the tool which was *still* trying to scan THAT target (!!!!)
 
−
 
 
−
Desired situation aka "solution":
 
−
 
 
−
It would be much more professional AND efficient that:
 
−
 
 
−
1) The pentester notices
 
−
 
 
−
2) The pentester tells the boss
 
−
 
 
−
3) The boss tells the customer
 
−
 
 
−
4) OWTF stops the tool because it knows that website is DEAD anyway
 
−
 
 
−
A target monitor could easily do this with heartbeat requests + playing mp3s
 
−
 
 
−
The target monitor will use the api to tell OWTF "this target is dead: freeze(stop?) current tests, skip target in future tests"
 
−
 
 
−
'''Feature 4) Disk space monitor'''
 
−
 
 
−
Another problem that is relatively common in large assessments, is that all disk space is used and the scanning box becomes unresponsive or crashes. When this happens it is too late, the pentester may also see this coming but wonder “which are the biggest files in the filesystem that I can delete”, it is not ideal to have to look for these files in a moment when the scanning box is about to crash :).
 
−
 
 
−
Proposed solution:
 
−
 
 
−
Regularly monitor how much disk space is left, especially on the partition where OWTF is writing the review (but also tool directories such as /home/username/.w3af/tmp, etc.). Keep track of files created by OWTF and all called tools and sort them by size in descending order. Then when the disk space is going low (i.e. predefined threshold), an mp3 or similar is played and this list is displayed to the user, so that they know what to delete to survive :).
 
−
 
 
−
'''Feature 5) Network/Internet Connectivity monitor'''
 
−
 
 
−
Sometimes it may also happen that ISP, etc. connectivity go down in the middle of a scan, this is often a very unfortunate situation since most tools are scanning in parallel and they won’t be able to produce a report OR even resume (i.e. A LOT is lost). The goal here is that OWTF does all of the following automatically:
 
−
 
 
−
1) Detects the lack of connectivity
 
−
 
 
−
2) Freezes all the tools (read: processes) in progress
 
−
 
 
−
3) Resumes the scan when the connectivity is back.
 
−
 
 
−
'''Feature 6) Tool crash detection'''
 
−
 
 
−
Sometimes, certain tools (most notably, ahem, w3af), when they crash they do NOT exit. This leaves OWTF in a difficult position where 1+ process is waiting for nothing, forever (i.e. because “Tool X” will never finish)
 
−
 
 
−
'''Feature 7) Tool (Plugin?) CPU/RAM/Bandwidth abuse detection and correction'''
 
−
 
 
−
OWTF needs to notice when some tools crash and/or “go beserk” with RAM/CPU/Bandwidth consumption, this is different from the existing built-in checks in OWTF like “do not launch a new tool if there is less than XYZ RAM free” and more like “if tool X is using > XYZ of the available RAM/CPU/Bandwidth” and this is (potentially) negatively affecting other tools/tests, then throttle it.
 
−
 
 
−
For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]
 
−
 
 
−
 
 
−
'''Expected results:'''
 
−
 
 
−
* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
 
−
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
 
−
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
 
−
* CRITICAL: Excellent reliability -i.e. the Health Monitor cannot crash! :)-
 
−
* Good performance
 
−
* Unit tests / Functional tests
 
−
* Good documentation
 
−
 
 
−
 
 
−
'''Knowledge Prerequisite:'''
 
−
 
 
−
Python and bash experience would be beneficial, 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 Mentor:'''
 
−
 
 
−
Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: [email protected], [email protected]
 
−
 
 
−
=== OWASP OWTF - Installation Improvements and Package manager ===
 
−
 
 
−
'''Brief explanation:'''
 
−
 
 
−
This project is to implement what was suggested in the following github issue:
 
−
[https://github.com/owtf/owtf/issues/192 https://github.com/owtf/owtf/issues/192]
 
−
 
 
−
 
 
−
Recently i tried to make a fresh installation of OWTF. The installation process takes too much time. Is there any way to make the installation faster?
 
−
Having a private server with:
 
−
* pre-installed files for VMs
 
−
* pre-configured and patched tools
 
−
* Merged Lists
 
−
* Pre-configured certificates
 
−
Additionally a minimal installation which will install the core of OWTF with the option of update can increase the installation speed. The update procedure will start fetching the latest file versions from the server and copy them to the right path.
 
−
Additional ideas are welcome.
 
−
 
 
−
-- They could be hosted on Dropbox or a private VPS :)
 
−
 
 
−
2 Installation Modes
 
−
* For high speed connections (Downloading the files uncompressed)
 
−
* For low speed connections (Downloading the files compressed)
 
−
and the installation crashed because i runned out of space in the vm
 
−
IMPORTANT NOTE: OWTF should check the available disk space BEFORE installation starts + warn the user if problems are likely
 
−
 
 
−
 
 
−
For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]
 
−
 
 
−
 
 
−
'''Expected results:'''
 
−
 
 
−
* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
 
−
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
 
−
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
 
−
* Excellent reliability (i.e. proper exception handling, etc.)
 
−
* Good performance
 
−
* Unit tests / Functional tests
 
−
* Good documentation
 
−
 
 
−
 
 
−
'''Knowledge Prerequisite:'''
 
−
 
 
−
Python and bash experience would be beneficial, 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 Mentor:'''
 
−
 
 
−
Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: [email protected], [email protected]
 
−
 
 
−
=== OWASP OWTF - Testing Framework Improvements ===
 
−
 
 
−
'''Brief explanation:'''
 
−
 
 
−
As OWASP OWTF grows it makes sense to build custom unit tests to automatically re-test that functionality has not been broken. In this project we would like to improve the existing unit testing framework so that creating OWASP OWTF unit tests is as simple as possible and all missing tests for new functionality are created. The goal of this project is to update the existing Unit Test Framework to create all missing tests as well as improve the existing ones to verify OWASP OWTF functionality in an automated fashion.
 
−
 
 
−
 
 
−
'''Top features'''
 
−
 
 
−
In this improvement phase, the Testing Framework should:
 
−
* (Top Prio) Focus more on functional tests
 
−
For example: Improve coverage of OWASP Testing Guide, PTES, etc. (lots of room for improvement there!)
 
−
* (Top Prio) Put together a great wiki documentation section for contributors
 
−
The goal here is to help contributors write tests for the functionality that they implement. This should be as easy as possible.
 
−
* (Top Prio) Fix the current Travis issues :)
 
−
* (Nice to have) Bring the unit tests up to speed with the codebase
 
−
This will be challenging but very worth trying after top priorities.
 
−
The wiki should be heavily updated so that contributors create their own unit tests easily moving forward.
 
−
 
 
−
 
 
−
'''General background'''
 
−
 
 
−
The Unit Test Framework should be able to:
 
−
* Define test categories: For example, "all plugins", "web plugins", "aux plugins", "test framework core", etc. (please see [http://www.slideshare.net/abrahamaranguren/introducing-owasp-owtf-workshop-brucon-2012 this presentation] for more background)
 
−
* Allow to regression test isolated plugins (i.e. "only test _this_ plugin")
 
−
* Allow to regression test by test categories (i.e. "test only web plugins")
 
−
* Allow to regression test everything (i.e. plugins + framework core: "test all")
 
−
* Produce meaningful statistics and easy to navigate logs to identify which tests failed and ideally also hints on how to potentially fix the problem where possible
 
−
* Allow for easy creation of _new_ unit tests specific to OWASP OWTF
 
−
* Allow for easy modification and maintenance of _existing_ unit tests specific to OWASP OWTF
 
−
* Perform well so that we can run as many tests as possible in a given period of time
 
−
* Potentially leverage the python unittest library: [http://docs.python.org/2/library/unittest.html http://docs.python.org/2/library/unittest.html]
 
−
 
 
−
 
 
−
For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]
 
−
 
 
−
 
 
−
'''Expected results:'''
 
−
 
 
−
* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
 
−
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
 
−
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
 
−
* Performant and automated regression testing
 
−
* Unit tests for a wide coverage of OWASP OWTF, ideally leveraging the Unit Test Framework where possible
 
−
* Good documentation
 
−
 
 
−
 
 
−
'''Knowledge Prerequisite:'''
 
−
 
 
−
Python, experience with unit tests and automated regression testing would be beneficial, 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 Mentor:'''
 
−
 
 
−
Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: [email protected], [email protected]
 
−
 
 
−
 
 
−
=== OWASP OWTF - Tool utilities module ===
 
−
 
 
−
'''Brief explanation:'''
 
−
 
 
−
The spirit of this feature is something that may or may not be used from OWTF: These are utilities that may be chained together by OWTF OR a penetration tester using the command line. The idea is to automate mundane tasks that take time but may provide a lever to a penetration tester short on time.
 
−
 
 
−
'''Feature 1) Vulnerable software version database:'''
 
−
 
 
−
Implement a searchable vulnerable software version database so that a penetration tester enters a version and gets vulnerabilities sorted by criticality with MAX Impact vulnerabilities at the top (possibly: CVSS score in DESC order).
 
−
 
 
−
Example:
 
−
[http://www.cvedetails.com/vulnerability-list.php?vendor_id=74&product_id=128&version_id=149817&page=1&hasexp=0&opdos=0&opec=0&opov=0&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=0&month=0&cweid=0&order=3&trc=17&sha=0d26af6f3ba8ea20af18d089df40c252ea09b711 Vulnerabilities against specific software version]
 
−
 
 
−
'''Feature 2) Nmap output file merger:'''
 
−
 
 
−
Unify nmap files *without* losing data: XML, text and greppable formats
 
−
For example: Sometimes 2 scans pass through the same port, one returns the server version, the other does not, we obviously do not want to lose banner information :).
 
−
 
 
−
'''Feature 3) Nmap output file vulnerability mapper'''
 
−
 
 
−
From an nmap output file, get the unique software version banners, and provide a list of (maybe in tabs?):
 
−
 
 
−
1) CVEs in reverse order of CVSS score, with links.
 
−
 
 
−
2) Metasploit modules available for each CVE / issue
 
−
 
 
−
NOTE: Can supply an *old* shell script for reference
 
−
 
 
−
3) Servers/ports affected (i.e. all server / port combinations using that software version)
 
−
 
 
−
 
 
−
'''Feature 4) URL target list creator:'''
 
−
 
 
−
Turn all “speaks http” ports (from any nmap format) into a list of URL targets for OWTF
 
−
 
 
−
 
 
−
'''Feature 5) Hydra command creator:'''
 
−
 
 
−
nmap file in => Hydra command list out
 
−
 
 
−
grep http auth / login pages in output files to identify login interfaces => Hydra command list out
 
−
 
 
−
 
 
−
'''Feature 6) WP-scan command creator:'''
 
−
 
 
−
look at all URLs (i.e. nmap file), check if they might be running word press, generate a list of suggested wp-scan commands for all targets that might be running word press
 
−
 
 
−
 
 
−
For background on OWASP OWTF please see: [https://www.owasp.org/index.php/OWASP_OWTF https://www.owasp.org/index.php/OWASP_OWTF]
 
−
 
 
−
 
 
−
'''Expected results:'''
 
−
 
 
−
* '''IMPORTANT: [http://legacy.python.org/dev/peps/pep-0008/ PEP-8 compliant code] in all modified code and surrounding areas.'''
 
−
* '''IMPORTANT: [https://github.com/7a/owtf/wiki/Contributor%27s-README OWTF contributor README compliant code]'''
 
−
* '''IMPORTANT: [http://sphinx-doc.org/ Sphinx-friendly python comments] [http://owtf.github.io/ptp/_modules/ptp/tools/w3af/parser.html#W3AFXMLParser example Sphinx-friendly python comments here]'''
 
−
* Excellent reliability (i.e. proper exception handling, etc.)
 
−
* Good performance
 
−
* Unit tests / Functional tests
 
−
* Good documentation
 
−
 
 
−
'''Knowledge Prerequisite:'''
 
−
 
 
−
Python, experience with unit tests and automated regression testing would be beneficial, 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 Mentor:'''
 
−
 
 
−
Abraham Aranguren, Bharadwaj Machiraju - OWASP OWTF Project Leaders - Contact: [email protected], [email protected]
 
−
 
 
−
''' OWASP Mentors '''
 
−
 
 
−
 
 
−
=== OWASP ZAP  ===
 
−
ZAP is an OWASP Flagship project and is currently the most active open source web security scanner.
 
−
 
 
−
There are a number of ZAP related projects students can work on, including:
 
−
 
 
−
 
 
−
=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - Bug tracker support ===
 
−
 
 
−
'''Brief explanation:'''
 
−
 
 
−
This would allow ZAP users to raise issues in bug trackers directly within ZAP.
 
−
 
 
−
This should be implemented as an extension with a generic framework and then adaptors for specific trackers, like github and bugzilla.
 
−
 
 
−
The info included in the issues raised should be as configurable as possible so that users can include whatever they want, and set things like custom fields.
 
−
 
 
−
'''Expected results:'''
 
−
 
 
−
A new ZAP add-on which would provide:
 
−
* A generic framework for raising ZAP issues in bug trackers controllable via the UI, API and configuration
 
−
* A full implementation for github issues
 
−
* Optionally additional support for other trackers such as bugzilla
 
−
 
 
−
'''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.
 
−
 
 
−
'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''
 
−
 
 
−
 
 
−
=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - Field enumeration ===
 
−
 
 
−
'''Brief explanation:'''
 
−
 
 
−
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:'''
 
−
 
 
−
A new ZAP add-on which would allow the user to:
 
−
* Select a specific field within a form
 
−
* Define success and failure conditions
 
−
* Define default values for other fields
 
−
* Specify character sets and ranges
 
−
* Report all of the valid and/or invalid characters of for that field
 
−
 
 
−
'''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.
 
−
 
 
−
'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''
 
−
 
 
−
 
 
−
=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - Form handling ===
 
−
 
 
−
'''Brief explanation:'''
 
−
 
 
−
The ZAP traditional and Ajax spiders explore an application by putting basic default values in all forms. These may often not be valid values, for example using "ZAP" when an email address is required.
 
−
 
 
−
The enhancement would allow the user to define default values based on pattern matching against the field names and/or ids.
 
−
 
 
−
It would also be very useful if it could show the user all forms and their associated fields for an application, and then allow the user to update the default values.
 
−
 
 
−
'''Expected results:'''
 
−
 
 
−
* New screens that allow the user to specify default values based on pattern matching against the field names and/or ids
 
−
* API support for configuring the default values
 
−
* The traditional and Ajax spiders changed to use those default values
 
−
* Optionally new screens which show all of the forms and their associated fields for an application
 
−
 
 
−
'''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.
 
−
 
 
−
'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''
 
−
 
 
−
 
 
−
=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - Gauntlet integration ===
 
−
 
 
−
'''Brief explanation:'''
 
−
 
 
−
Gauntlt is a framework for controlling security tools for testing web apps.
 
−
 
 
−
It is increasingly being used in 'secdevops' and therefore providing a plugin which allows ZAP to be run would be very desirable.
 
−
 
 
−
'''Expected results:'''
 
−
 
 
−
A Gauntlt plugin that provides ZAP integration to support:
 
−
* Spidering an application
 
−
* Actively scanning an application
 
−
* Reporting the vulnerabilities found
 
−
* Optionally configuring context information, eg to support authentication
 
−
 
 
−
'''Knowledge Prerequisite:'''
 
−
 
 
−
Gauntlt is written in Ruby, 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.
 
−
 
 
−
'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''
 
−
 
 
−
 
 
−
=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - Script console code completion ===
 
−
 
 
−
'''Brief explanation:'''
 
−
 
 
−
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:'''
 
−
 
 
−
AutoComplete supported in the ZAP Script Console for:
 
−
* Javascript
 
−
* Jython
 
−
* JRuby
 
−
 
 
−
'''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.
 
−
 
 
−
'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''
 
−
 
 
−
 
 
−
=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - Support java as a scripting language ===
 
−
 
 
−
'''Brief explanation:'''
 
−
 
 
−
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:'''
 
−
 
 
−
* The ability to run Java code in the ZAP Script Console to the same leval as other supported scripting languages
 
−
* Templates for all of the current script types
 
−
* Optionally auto complete supported
 
−
 
 
−
'''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.
 
−
 
 
−
'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''
 
−
 
 
−
 
 
−
=== [https://www.owasp.org/index.php/ZAP OWASP ZAP] - 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 fully documented and reviewed text representation for Zest
 
−
* The Java Zest runtime changed to generate the text representation for all statements
 
−
* A parser written in java that converts the text representation into Zest JSON
 
−
* Optionally parsers written in other languages
 
−
 
 
−
'''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.
 
−
 
 
−
'''Mentor: [https://www.owasp.org/index.php/User:Simon_Bennetts Simon Bennetts] - OWASP ZAP Project Leader'''
 
−
 
 
−
 
 
−
=== [https://www.owasp.org/index.php/OWASP_AppSensor_Project OWASP AppSensor] Enterprise Integrations - Reporting ===
 
  
 
'''Brief Explanation:'''
 
'''Brief Explanation:'''
  
−
This is a feature request that's been driven by the community. AppSensor provides great utility by allowing applications to defend themselves. AppSensor can/will also provide a UI (another possible GSOC project) to view and manage the information produced by the applications. However, larger organizations often already have a system in place for managing system security alerts. It would provide a lot of value if we can integrate with those systems and data formats. This project will involve a bit of up-front research, then primarily systems integration work.  
+
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:'''
 
'''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
  
−
We want  to support a number of integrations. Some that have been requested by our community are: 
+
''' Note: '''
−
* SNMP
+
This is a huge project, it is ok if the student implements a part of it. However whatever implemented must be up to spec.
−
* SCOM
+
If you decide to take on this project contact us and we can agree on a list of routes.
−
* syslog
+
If you don't decide to take on this project contact us.
−
* AppDynamics
+
Generally contact us, we like it when students have insightful questions and the community is active
  
−
Source code and associated tests for these integrations will be created, along with the associated end user documentation for how to setup and configure them.
 
  
−
'''Knowledge Prerequisites:'''
+
''' Getting Started: '''
−
 
+
* Install and take a brief look around the old cms so you have an idea of the functionality needed
−
Comfortable in Java and unit testing.
+
* 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)
−
'''Mentor:''' John Melton - OWASP AppSensor Project Leader (Development)
 
−
 
 
−
 
 
−
=== [https://www.owasp.org/index.php/OWASP_AppSensor_Project OWASP AppSensor] Enterprise Integrations - Transport ===
 
−
 
 
−
'''Brief Explanation:'''
 
−
 
 
−
AppSensor currently supports a number of "execution modes", which are simply a reference to the transport protocol (REST, SOAP, thrift). There are a number of protocols that are popular in enterprises that we don't currently support, but could. This would simplify integration for many organizations who already use a set of approved communication protocols. This project would be primarily integration work and testing with a number of well-known systems integration / transport protocols and mechanisms.
 
−
 
 
−
'''Expected Results:'''
 
−
 
 
−
We want to support a number of integrations. Some that have been proposed are: 
 
−
* ActiveMQ
 
−
* Avro
 
−
* Protobuf
 
−
 
 
−
Source code and associated tests for these integrations will be created, along with the associated end user documentation for how to setup and configure them.
 
  
 
'''Knowledge Prerequisites:'''
 
'''Knowledge Prerequisites:'''
 +
Python, Django, what REST is, the technologies used, some security knowledge would be nice.
  
−
Comfortable in Java and unit testing. Some familiarity with distributed systems in general and message brokers in particular would be helpful.
+
'''Mentors:''' [mailto:[email protected] Spyros Gasteratos] - Hackademic Challenges Project Leaders
−
 
 
−
'''Mentor:''' John Melton - OWASP AppSensor Project Leader (Development)
 
  
−
 
+
=== Course Type Challenge ===
−
=== [https://www.owasp.org/index.php/OWASP_AppSensor_Project OWASP AppSensor] Dashboard UI ===
 
  
 
'''Brief Explanation:'''
 
'''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.
  
−
AppSensor provides a solid base of functionality to applications, but does not currently do a good job of presenting the resulting data. We are attacking that issue on 2 fronts. We plan to create a custom UI (this project) as well as various integrations to standard tools/formats for reporting to existing display systems. This project will involve creating the default/standard UI for the AppSensor project. As part of the project, you will learn about the domain model, iterating your mockup designs and share those with the project leader(s) and the community for feedback. We don't have an existing product, so you will have lots of responsibility for the design and implementation, as well as significant input to the decision around the technology stack.
+
Ideas on the project:
 +
* Purposefully vulnerable web page that guides the user via javascript tooltips and hints to exploiting it using ZAP. ( Bonus: using ZAP via the ZAP api). The challenge is solved when the the student submits the contents of a text file located on the disk (obtained by exploited an RCE)
  
−
'''Expected Results:'''
+
* Reversing a provided binary to extract information by providing step by step instructions to reversing using any popular reversing tool (well, you can't use IDA so gdb should have to do). Challenge is solved when the keys are extracted from the binary and submitted. Bonus points if each binary donwloaded has different keys.
  
−
A modern, usable UI will be built that will have at least the following features (though there are many more features to build) :
+
* Guide to exploiting the TOP10. (Using ZAP?)
−
* Basic Dashboard UI (the UI for the OPS wall)
 
−
* Search
 
−
* Policy Management (edit server configuration)
 
  
−
Source code and associated tests for the UI will be created, along with the associated end user documentation for how to setup and configure the system.  
+
* Defensive Type challenges -- Here's how to create a patch for this kind of vulnerability -- Challenge is solved when the unit tests are run and the vulnerability isn't there.
  
−
'''Knowledge Prerequisites:'''
+
''' Getting started '''
−
 
+
* Check popular javascript guide tools such as: (http://introjs.com/ and http://github.hubspot.com/shepherd/docs/welcome/ )
−
Comfortable with UI design and development, particularly building dashboards. Comfortable with Java (with some assistance). Basic familiarity with security concepts related to intrusion detection and prevention as this is the basic domain.
+
* If you're more interested in system or non-web challenges check serverspec and definitely check quest (https://github.com/puppetlabs/quest)
−
 
+
* If you think contributing is a good idea to make yourself familiar with the project you can either port one of the existing simpler 1-page challenges to a docker container and submit a pull request or write a guide on how to create such a challenge
−
'''Mentor:''' John Melton - OWASP AppSensor Project Leader (Development)
 
−
 
 
−
 
 
−
=== [https://www.owasp.org/index.php/OWASP_AppSensor_Project OWASP AppSensor] Trend Monitoring Analysis Engine ===
 
−
 
 
−
'''Brief Explanation:'''
 
−
 
 
−
AppSensor currently supports a basic policy-driven analysis engine to determine if a series of events represents an attack (if a user triggers 5 of this type of event in 10 minutes, it's an attack). While this supports many use cases, there are times when it would be helpful to know trending information. If a particular function of the application begins to see 10 times its normal amount of traffic, that might represent an attack. This project would add an additional analysis engine to support "trend monitoring". Development of this feature would require some initial research on alternative implementation strategies, followed by the development and testing of the feature in AppSensor.
 
  
 
'''Expected Results:'''
 
'''Expected Results:'''
  
−
The project should produce:
+
* One or more Course - style challenges provided either as a docker container or as a vagrant box.
−
* A trend monitoring analysis engine to be used either in place of or in addition to the existing policy-driven analysis engine
+
* Concrete documentation on how to build a challenge like this.
−
* Associated configuration mechanism to specify the trending rules/policy
 
−
* A small full sample demo application showing usage of the trend monitoring feature
 
−
 
 
−
Source code and associated tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.
 
−
 
 
−
'''Knowledge Prerequisites:'''
 
−
 
 
−
Comfortable in Java and unit testing.
 
−
 
 
−
'''Mentors:''' John Melton - OWASP AppSensor Project Leader (Development)
 
−
 
 
−
 
 
−
=== [https://www.owasp.org/index.php/OWASP_SeraphimDroid_Project  OWASP Seraphimdroid]  - Open Seraphimdroid for external plugin development ===
 
−
 
 
−
'''Brief Explanation:'''
 
−
 
 
−
SeraphimDroid is an privacy protection and educational application for android devices that helps users learn about risks and threats coming from other android applications. SeraphimDroid scans your devices and teaches you about risks and threats coming from application permissions. In the last version SeraphimDroid evolved to application firewall for android devices not allowing malicious SMS or MMS to be sent, USSD codes to be executed or calls to be called without user permission and knowledge. Now we want to open the application for plugin development and improve some protection mechanisms.
 
−
 
 
−
'''Expected Results:'''
 
−
 
 
−
The project should produce:
 
−
* Application should be modified to a platform that will allow other developers to create android application and services as a plugins to OWASP Seraphimdroid, where the collected data on data leaks, security breaches and other things application are doing could be viewed through OWASP Seraphimdroid application.
 
−
* Create a plugin application that showcases how the plugin will work
 
−
* Create a documentation on how to create new plugin (guide)
 
−
 
 
−
 
 
−
Source code and associated tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.
 
−
 
 
−
'''Knowledge Prerequisites:'''
 
−
 
 
−
Comfortable in Java, XML and android development.
 
−
 
 
−
'''Mentors:''' [[User:Nikola Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader
 
−
 
 
−
=== [https://www.owasp.org/index.php/OWASP_SeraphimDroid_Project  OWASP Seraphimdroid]  - Settings checker and improving permission ranking algorithm ===
 
−
 
 
−
'''Brief Explanation:'''
 
−
 
 
−
SeraphimDroid is an privacy protection and educational application for android devices that helps users learn about risks and threats coming from other android applications. SeraphimDroid scans your devices and teaches you about risks and threats coming from application permissions. In the last version SeraphimDroid evolved to application firewall for android devices not allowing malicious SMS or MMS to be sent, USSD codes to be executed or calls to be called without user permission and knowledge. Now we want improve some protection mechanisms, like check for settings and improve the ranking of application by how dangerous their permissions are. We also look for new ideas on how to improve privacy and security of mobile device users.
 
−
 
 
−
'''Expected Results:'''
 
−
 
 
−
The project should produce:
 
−
* We are also looking for a new ideas how to evaluate the dangers coming from the permissions applications are requesting. Currently there is a simple algorithm that is labelling red, yellow and green apps, but in many cases red apps just request multiple permissions. We are looking for a solution that will somehow give a weight to permissions and based on it evaluate it more realistically.
 
−
* Create a settings check - check whether settings are set according to best practices (development options turned off, debugging off, etc.)
 
−
* Fix some bugs like fixing application locker on Lollipop, update and improve recieving SMS alarming, etc.
 
−
* Document the improvements
 
−
* Bonus: Create a widget
 
−
 
 
−
 
 
−
Source code and associated tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.  
 
  
 
'''Knowledge Prerequisites:'''
 
'''Knowledge Prerequisites:'''
 +
The technologies used.
  
−
Comfortable in Java, XML and android development.
 
  
−
'''Mentors:''' [[User:Nikola Milosevic|Nikola Milosevic]] - OWASP Seraphimdroid Project Leader
+
'''Mentors:''' [mailto:[email protected] Spyros Gasteratos] - Hackademic Challenges Project Leaders

Latest revision as of 19:29, 13 November 2017

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

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

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 !

  • $550.00 for Airfare or Transportation
  • 3 Nights of Hotel Accommodations
  • Must attend the 2 day Project Summit 2018 Sessions
  • All done by reimbursement process along with receipts

Mailing List

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

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

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
  • 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
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
  • The ability to run Java code in the ZAP Script Console to the same leval as other supported scripting languages
  • Templates for all of the current script types
  • Optionally auto complete supported
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://wiki.jenkins-ci.org/display/JENKINS/zap+plugin).
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
  • Facilitate the invocation and configuration of various ZAP functionalities from Bamboo CI. Including (but not limited to):
  • Manage Sessions (Loading/Persisting)
  • Define Context (Name, Include & Exclude URLs)
  • Attack Contexts (Spider, Ajax Spider, Active Scan)
  • Setup Autentication (Formed or Script Based)
  • Generate Reports
  • Templates for all of the current script types
  • Optionally auto complete supported
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
  • Get in touch with us :)
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

  • 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

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]

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

  • Get in touch with us on Github:

https://github.com/zscproject/OWASP-ZSC

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

  • New obfuscation modules
  • New shellcodes for OSX and Windows

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:

  • Reviewing scientific literature and find feasible approach we can take
  • Implement and possibly improve the approach in Seraphimdroid
  • Test the model and provide controls to switch algorithm on or off and possibly fine tune it
  • Documenting approach as a technical report

Knowledge Prerequisites:

  • Java
  • Android
  • CSV, XML
  • Basic knowledge and interest in machine learning

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:

  • Examining the way of integrating third party apps through some provided API to OWASP Seraphimdroid
  • Providing GUI integration with third party components
  • Develop at least one test plugin
  • Document the development process and API

Knowledge Prerequisites:

  • Java
  • Android
  • CSV, XML

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:

  • Multiple opportunities for students to get involved with DefectDojo ranging in difficulty from easy to advanced
  • Students will receive hands-on experience in a full-stack software development project
  • Students will have the opportunity to work on a project with multiple moving parts and third-party interactions

Knowledge Prerequisites:

  • Python
  • HTML, Bootstrap

Getting started:


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:
  • Almost everybody has web server logs. It's a common format that is well understood, and is a good starting place for many security teams
  • Because the format is well understood, the data points (features) are well understood.
  • This tool suite would have applicability far beyond just our project. The goal is to give away a tool that can process a set of log files, build a custom model for the traffic, and then be used to process future log files and find attacks (outliers / anomalies)
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
  • User provides tool suite a set of web server logs (User has option to annotate data set with known attacks)
  • System is pre-coded with knowledge of certain anomalous patterns (attacks)
  • System builds ML model for processing future log files
  • System provides mechanism for processing future logs using trained model.
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
  • Get in touch with us :)
Expected Results:
  • A new feature that makes AppSensor even better
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

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

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

  • HTML (pure static html here)
  • PDF
  • XML (for processing)
  • JSON (for processing)

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 ArangurenViyat BhalodiaBharadwaj 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:

  • Tools that OWTF has trouble proxying right now: skipfish, hoppy
  • Tools that the user may have run manually OR even from a tool aggregator -very common! :)-
  • Tools that we just don't run from OWTF: ZAP, Burp, Fiddler

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:

  • HTTP request
  • HTTP response status code
  • HTTP response headers
  • HTTP response body

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 ArangurenViyat BhalodiaBharadwaj 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:

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

  • Purposefully vulnerable web page that guides the user via javascript tooltips and hints to exploiting it using ZAP. ( Bonus: using ZAP via the ZAP api). The challenge is solved when the the student submits the contents of a text file located on the disk (obtained by exploited an RCE)
  • Reversing a provided binary to extract information by providing step by step instructions to reversing using any popular reversing tool (well, you can't use IDA so gdb should have to do). Challenge is solved when the keys are extracted from the binary and submitted. Bonus points if each binary donwloaded has different keys.
  • Guide to exploiting the TOP10. (Using ZAP?)
  • Defensive Type challenges -- Here's how to create a patch for this kind of vulnerability -- Challenge is solved when the unit tests are run and the vulnerability isn't there.

Getting started

  • Check popular javascript guide tools such as: (http://introjs.com/ and http://github.hubspot.com/shepherd/docs/welcome/ )
  • If you're more interested in system or non-web challenges check serverspec and definitely check quest (https://github.com/puppetlabs/quest)
  • If you think contributing is a good idea to make yourself familiar with the project you can either port one of the existing simpler 1-page challenges to a docker container and submit a pull request or write a guide on how to create such a challenge

Expected Results:

  • One or more Course - style challenges provided either as a docker container or as a vagrant box.
  • Concrete documentation on how to build a challenge like this.

Knowledge Prerequisites: The technologies used.


Mentors: Spyros Gasteratos - Hackademic Challenges Project Leaders

Retrieved from "https://wiki.owasp.org/index.php?title=OWASP_Code_Sprint_2017&oldid=235377"