GSOC2016 Ideas

=OWASP Project Requests=

Tips to get you started in no particular order: * Read the GSoC SAT * Check the Hackademic wiki page linked above * Contact us through the mailing list or irc channel. * Check our github repository and especially the open tickets

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

REST API for the sandbox
Brief Explanation:

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

Ideas on the project: Since the sandbox is written in python, you can use microframeworks such as flask to implement the api. The endpoint authorization can be done via certificates or plain signature or username/password type authentication. However the communication between the two has to be over a secure channel.

Expected Results:
 * A REST style api which allows an authenticated remote entity control the sandbox engine.
 * PEP8 compliant code
 * Acceptable unit test coverage

Knowledge Prerequisites:

Python, test driven developmen, some idea what REST is, some security knowledge would be preferable.

Mentors: Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

New CMS
Brief Explanation:

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

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
 * PSR/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

Knowledge Prerequisites: Python or PHP, the framework suggested, what REST is, the technologies used, some security knowledge would be nice.

Mentors: Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

First Course Type Challenge
Brief Explanation: We have a wonderful 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.

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: Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

Advanced Sandboxed Challenges
Brief Explanation:

In the spirit of the challenges above, we're looking for true ctf type challenges. This is an open ended task. We're expecting awesome fresh ideas.

Ideas on the project:
 * An application vulnerable to one or more TOP 10 elements.
 * A logic flaws based ctf
 * Your idea here

Expected Results: Docker containers or Vagrant boxes that contain complete new challenges.

Knowledge Prerequisites: Knowledge of the technologies used

Mentors: Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

Your idea
Brief Explanation:

Amazing students, in our experience the best, most creative and unique ideas show up when we let students suggest their own feature in relation to the project. The above should give you a general idea where we're going but don't let them constrain you. Do you wanna do something that would fit into Hackademic? Send us an email!

Ideas on the project: No idea, that's your turn to shine!

Expected Results: If it's code, code according to our coding standards. If it's challenges, something new and interesting. If it's something else, then written like the person who's going to maintain your code is a raging psychopath with an axe who knows where you live.

In short we'd like some quality. ;-)

Knowledge Prerequisites:

Mentors: Konstantinos Papapanagiotou, Spyros Gasteratos - Hackademic Challenges Project Leaders

OWASP OWTF - VMS - OWTF Vulnerability Management System
Brief explanation:

Background problem to solve:

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.

Proposed solution:

We can meta aggregate these duplicate issues into one issue of "outdated software / apache / php detected". with XYZ list of issues in them.

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

VMS will have the following features:
 * 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.

Similar previous work for Nessus

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

Expected results:


 * IMPORTANT: PEP-8 compliant code in all modified code and surrounding areas.
 * IMPORTANT: OWTF contributor README compliant code
 * IMPORTANT: Sphinx-friendly python comments 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: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

OWASP OWTF - HTTP Request Translator Improvements
Brief explanation:

Problem to solve:

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.

Proposed solution:

An HTTP request translator, a *standalone* *tool* that can:

1) Be used from inside OR outside of OWTF.

2) Translate raw HTTP requests into curl commands or bash/python/php/ruby/PowerShell scripts

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"

3) User pastes a raw HTTP requests + hits enter

4) Tool outputs whatever is relevant for the flags + http request given


 * For bulk processing: Maybe a directory of raw http request files?

Nice to have: Transforms

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

Expected results:


 * IMPORTANT: PEP-8 compliant code in all modified code and surrounding areas.
 * IMPORTANT: OWTF contributor README compliant code
 * IMPORTANT: Sphinx-friendly python comments 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: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

OWASP OWTF - JavaScript Library Sniper Improvements
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: Once the standalone tool is built and verified to be working, OWTF should be able to:
 * ALL Library/vulnerability matches described on 4)

Feature 1) GREP plugin improvement (Web Application Fingerprint):

Step 1) Lookup file lengths and hashes in the "JavaScript library database"

Step 2) If a match is found: provide the list of known vulnerabilities against "JavaScript library X" to the user

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:
 * 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: 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
 * "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:

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

Expected results:


 * IMPORTANT: PEP-8 compliant code in all modified code and surrounding areas.
 * IMPORTANT: OWTF contributor README compliant code
 * IMPORTANT: Sphinx-friendly python comments 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: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

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:


 * IMPORTANT: PEP-8 compliant code in all modified code and surrounding areas.
 * IMPORTANT: OWTF contributor README compliant code
 * IMPORTANT: Sphinx-friendly python comments 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: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

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.

Feature 2) Corrective mechanisms

Corrective mechanisms are also expected in this project, these will be accomplished sending OWTF api messages such as:
 * 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

Expected results:


 * IMPORTANT: PEP-8 compliant code in all modified code and surrounding areas.
 * IMPORTANT: OWTF contributor README compliant code
 * IMPORTANT: Sphinx-friendly python comments 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: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

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

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: 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.
 * pre-installed files for VMs
 * pre-configured and patched tools
 * Merged Lists
 * Pre-configured certificates

-- They could be hosted on Dropbox or a private VPS :)

2 Installation Modes 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 high speed connections (Downloading the files uncompressed)
 * For low speed connections (Downloading the files compressed)

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

Expected results:


 * IMPORTANT: PEP-8 compliant code in all modified code and surrounding areas.
 * IMPORTANT: OWTF contributor README compliant code
 * IMPORTANT: Sphinx-friendly python comments 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: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

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: For example: Improve coverage of OWASP Testing Guide, PTES, etc. (lots of room for improvement there!) The goal here is to help contributors write tests for the functionality that they implement. This should be as easy as possible. 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.
 * (Top Prio) Focus more on functional tests
 * (Top Prio) Put together a great wiki documentation section for contributors
 * (Top Prio) Fix the current Travis issues :)
 * (Nice to have) Bring the unit tests up to speed with the codebase

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

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

Expected results:


 * IMPORTANT: PEP-8 compliant code in all modified code and surrounding areas.
 * IMPORTANT: OWTF contributor README compliant code
 * IMPORTANT: Sphinx-friendly python comments 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: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

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

Expected results:


 * IMPORTANT: PEP-8 compliant code in all modified code and surrounding areas.
 * IMPORTANT: OWTF contributor README compliant code
 * IMPORTANT: Sphinx-friendly python comments 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: Abraham.Aranguren@owasp.org, bharadwaj.machiraju@gmail.com

 OWASP Mentors 

OWASP ZAP
We are in the process of deciding the set of ZAP projects for Google Summer of Code 2015.

You can follow (and join in) the discussions on the ZAP Developer Group: https://groups.google.com/d/msg/zaproxy-develop/Uy0JPkzsI_s/Bj7OTSkISCIJ

Example Idea
Currently ZAP provides only a limited set of report data. While this can be extended dynamically this feature is not currently used, and there is no way for users to choose what data they get back. It also provides a set of API calls, some of which return data that could be incorporated into reports, and some of which allow the fixed report to be accessed.

Expected Results

 * Report data will be a distinct type of data returned via API calls
 * An add-on that provides report data - so this becomes 'plug-able'
 * Report data and meta data should be fully internationalized
 * Users can specify which sites / contexts report data should apply to

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

OWASP AppSensor
OWASP AppSensor Project provides real-time application layer intrusion detection.

* Check the AppSensor wiki page linked above * Contact us through the mailing list. * Check our github repository and the open tickets * Also see our appsensor website

Dashboard UI Expansion
Brief Explanation:

AppSensor provides a solid base of functionality to applications, and we currently have a minimal application for data display. This project will involve expanding 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. The existing stack is based on spring boot and reactjs. There are lots of features to be added, and you'll work with the project leader(s) and the community to build the most-needed and requested capabilities.

Expected Results:

The existing dashboard application will be expanded and will involve features like:
 * Search (could involve significant back-end work to configure indexing, etc.)
 * Policy Management (edit server configuration in real-time)
 * Data visualization / dashboarding

Source code, tests, and associated documentation for both the back-end and UI will be delivered for this effort.

Knowledge Prerequisites:

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

Mentors: John Melton - OWASP AppSensor Project Leader (Development)

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:

The project should produce:
 * A trend monitoring analysis engine to be used either in place of or in addition to the existing policy-driven analysis engine
 * 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)

Expand language support for clients
Brief Explanation:

AppSensor supports various modes for communication with the server. The language and framework of the client application are required only to support the given mode. This flexibility is desirable, but having pre-built clients in various languages is useful for our user-base. This project would involve working with various popular languages and frameworks to build support for communicating with the appsensor server backend.

Expected Results:

The project should produce:
 * Clients in multiple popular languages for interaction with appsensor server
 * At a minimum, coverage for the HTTP/REST mode should be supported. Other modes (thrift, soap, kafka, etc.) will be produced as time allows.
 * Several small demo applications showing usage of the given APIs

Source code and tests for the feature will be created, along with the associated end user documentation for how to setup and configure it.

Knowledge Prerequisites:

Comfortable working in multiple popular languages and unit testing.

Mentors: John Melton - OWASP AppSensor Project Leader (Development)

Implement Detection Points in Reverse Proxy
Brief Explanation:

AppSensor works by tracking events that are created by "detection points", essentially locations in the processing pipeline where suspicious or malicious intent is observed. This often requires business-specific detection within the application. However, the project has defined a number of detection points (https://www.owasp.org/index.php/AppSensor_DetectionPoints) and responses (https://www.owasp.org/index.php/AppSensor_ResponseActions), some of which can be generically applied across a broader set of applications, including those that are common to an entire organization or even cross-organization. For that reason, a sub-project has been created (https://github.com/jtmelton/appsensor-reverse-proxy) that provides support for detection points and responses that are generic enough to be broadly applicable. This project would expand support for these detection points and responses.

Expected Results:

The project should produce:
 * New detection points and responses
 * Documentation for how to deploy the project and any end-user considerations
 * Load testing each function as this project front-ends applications, and traffic throughput characteristics are important to our user-base.
 * A small sample demo application showing the utility of the proxy. A recording of the usage for community viewing would be beneficial.

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 golang and unit testing.

Mentors: John Melton - OWASP AppSensor Project Leader (Development)

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:
 * Nikola Milosevic - OWASP Seraphimdroid Project Leader

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:
 * Nikola Milosevic - OWASP Seraphimdroid Project Leader

Educational component
Brief Explanation:

OWASP Seraphimdroid is well rounded security and privacy app. The initial idea of the project was to provide educational platform for common users, where by using the application, users can learn about risks for their privacy and security. Some components already has some sort of explanation, which is educational. However, it lacks of uneatable knowledge source and some of the components that monitor user's behavior do not provide sufficient information. Idea of this project is to develop monitoring of user activity and an component that can warn user about risks if he does something risky. Also, mobile security knowledge base that can be updated remotely will be a huge new asset to the application.

Expected Results:


 * Develop uneatable knowledge base and GUI for it
 * Develop web server where the knowledge base can be updated
 * Improve current educational reporting
 * Develop methodology for monitoring users and notifying them about risky activities

Knowledge Prerequisites:
 * Java
 * Android
 * CSV, XML

Mentors:
 * Nikola Milosevic - OWASP Seraphimdroid Project Leader

OWASP ZSC Tool
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.

Expected Results:

Please take a look of our TODO list in Github to get some ideas: https://github.com/Ali-Razmjoo/OWASP-ZSC/issues

Another ideas:
 * Help us develop shellcode module for windows
 * Develop shellcode module for OSX

Read about the project here: https://ali-razmjoo.gitbooks.io/owasp-zsc/content/

Recommended reading: http://www.vividmachines.com/shellcode/shellcode.html

Knowledge Prerequisites:
 * Python
 * Basic knowledge about Shellcode and assembly language

Mentors:
 * Christo and Timo Goosen and Brian Beaudry- OWASP ZSC Contributors

Contact us through our mailing list for questions: https://groups.google.com/d/forum/owasp-zsc