Difference between revisions of "GSoC2013 Ideas"

From OWASP
Jump to: navigation, search
(OWASP Security Research and Development Framework)
Line 250: Line 250:
  
 
'''Mentor: Amr Thabet - OWASP Security Research and Development Framework Project Leader'''
 
'''Mentor: Amr Thabet - OWASP Security Research and Development Framework Project Leader'''
 +
 +
=== OWASP ModSecurity CRS - Create "Sniffer-Mode" ===
 +
 +
'''Brief explanation:'''
 +
 +
The ModSecurity code includes a "standalone" version that wraps a light weight Apache/APR around the ModSecurity code.  This is used as the basis for the ports to the IIS/Nginx web server platforms.  The goal for this project task is to extend this standalone version so that it can accept a data feed of network traffic (e.g. libpcap) data as input and apply the ModSecurity CRS rules.  One possible solution would be create a ModSecurity "plugin" for the Snort IDS.
 +
 +
'''Expected results:'''
 +
 +
This new sniffer mode would allow organizations to run ModSecurity/OWASP ModSecurity CRS in an out of line mode as they do IDS systems.
 +
 +
'''Knowledge Prerequisite:'''
 +
 +
C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.
 +
 +
'''Mentor: Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader'''
 +
 +
=== OWASP ModSecurity CRS - Port to Java ===
 +
 +
'''Brief explanation:'''
 +
 +
The goal is to have a ModSecurity version that can be used within Java servers (e.g. Tomcat).  There may be methods to use JNI to call the standalone code from a filter in Tomcat.
 +
 +
'''Expected results:'''
 +
 +
This new version allow organizations to run ModSecurity/OWASP ModSecurity CRS in Java web servers.
 +
 +
'''Knowledge Prerequisite:'''
 +
 +
C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.
 +
 +
'''Mentor: Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader'''
 +
 +
=== OWASP ModSecurity CRS - Implement libinjection Code ===
 +
 +
'''Brief explanation:''' https://www.modsecurity.org/tracker/browse/MODSEC-327
 +
 +
libinjection (https://github.com/client9/libinjection) is a C library that detects SQLi attacks in user input. It is designed to be embedded in existing or new applications:
 +
 +
*Fast > 100k inspections per second
 +
*No memory allocation
 +
*No threads
 +
*Stable memory usage (approximately 500 bytes on stack)
 +
*500 lines of C code (plus a few kiobytes of data)
 +
 +
It is based on lexical analysis of SQL and SQLi attempts and does not use regular expressions.
 +
 +
'''Expected results:'''
 +
 +
The new C code in ModSecurity will allow us to add new SQL Injection detection methods to the OWASP ModSecurity CRS.
 +
 +
'''Knowledge Prerequisite:'''
 +
 +
C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.
 +
 +
'''Mentor: Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader'''
 +
 +
=== OWASP ModSecurity CRS - Implement DoS Prevention Code ===
 +
 +
'''Brief explanation:''' https://www.modsecurity.org/tracker/browse/MODSEC-265
 +
 +
Implement a request velocity learning engine to identify dynamic DoS thresholds for both the site and for the particular URL.
 +
 +
'''Expected results:'''
 +
 +
The new C code in ModSecurity will allow us to add new DoS Protection methods to the OWASP ModSecurity CRS.
 +
 +
'''Knowledge Prerequisite:'''
 +
 +
C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.
 +
 +
'''Mentor: Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader'''
 +
 +
=== OWASP ModSecurity CRS - Create a Positive Learning/Profile Engine ===
 +
 +
'''Brief explanation:''' https://www.modsecurity.org/tracker/browse/MODSEC-193
 +
 +
ModSecurity needs a profiling engine that implements the various AppSensor Detection Points - http://blog.spiderlabs.com/2011/08/implementing-appsensor-detection-points-in-modsecurity.html.
 +
 +
'''Expected results:'''
 +
 +
The new engine will implement more detection points to detect abnormal request attributes.
 +
 +
'''Knowledge Prerequisite:'''
 +
 +
C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.
 +
 +
'''Mentor: Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader'''
 +
 +
=== OWASP ModSecurity CRS - Create an Engine to Detect Application Flow Anomalies ===
 +
 +
'''Brief explanation:'''
 +
 +
Need an engine that can track normal application flow paths (click-flows) for business logic transactions - such as transferring money from accounts.  After profiling normal application path flows, we want to then be able to alert to anomalies.  This type of logic can help to prevent Banking Trojan attacks.
 +
 +
'''Expected results:'''
 +
 +
The engine will be able to alert on anomalous application flows.
 +
 +
'''Knowledge Prerequisite:'''
 +
 +
C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.
 +
 +
'''Mentor: Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader'''

Revision as of 15:46, 22 March 2013

Contents

OWASP Project Requests

OWASP PHP Security Project

Description: OWASP PHP Security project plans to gather around secure PHP libraries, and provide a full featured framework of libraries for secure web applications in PHP, both as separate de-coupled libraries and as a whole secure web application framework. Many aspects of this project are already handled, and are being added to OWASP.

Expected Results: Result of this project is much more security among PHP applications. Most PHP applications are vulnerable and there's no central approach to secure them (due to open source nature). Many people look at OWASP for such information.

Knowledge prerequisite: Anyone with adequate PHP programming language experience (possibly web application development in PHP). There are hard and easy parts of this project. For tougher parts, familiarity with security concepts, advanced SQL, and advanced PHP and web server configuration is required.

Mentor: Abbas Naderi

OWASP RBAC Project

Description: For the last 6 years, improper access control has been the issue behind two of the Top Ten lists.

RBAC stands for Role Based Access Control and is the de-facto access control and authorization standard. It simplifies access control and its maintenance for small and enterprise systems alike. NIST RBAC standard has four levels, the second level hierarchical RBAC is intended for this project.

Unfortunately because of many performance and development problems, no suitable RBAC implementation was available until recently, so developers and admins mostly used ACLs and other forms of simple access control methods, which leads to broken and unmaintainable access control over the time.

OWASP provides the RBAC project, as a stand-alone library with very fast access control checks and standard mature code-base. Currently PHPRBAC which is the PHP version of the RBAC project is released.

Expected Results: Standard NIST level 2 hierarchical RBAC libraries for different programming languages, specially web-based ones such as C/C++/Java/ASP/ASPX/Python/Perl/etc.

Knowledge prerequisite: Good SQL knowledge, library development schemes, familiarity with one of the programming languages.

Mentor: Abbas Naderi

Skill Level: Advanced

For more info, visit phprbac.net

OWASP XSSer Project

XSSer has a correct engine implementation to search/exploit XSS vulnerabilities, but it is necessary to work on some different fields to obtain better results. Some of them are: to fight against "false positive" results, to implemenet a better human-readable output results and to develop some new features (like; CSSer, Code checks user inputs, etc...). Also, it will be nice to update the tool with more valid XSS vectors (DOM, DCP, reflected, etc...) and some "anti-anti-XSS" systems for more common browsers.

There is a roadmap on a pdf file with all tasks required to advance to next release of 'XSSer' (v1.7b - Total Swarm!)

Download: http://xsser.sourceforge.net/xsser/xsser-roadmap.pdf

Brief explanation:

Below is shown a structure of phases and milestones code areas.

Milestones:

   • Phase 1: Core:
       + Bugfixing:
            - False positives
            - Fix “swarm” results
            - Fix 'maximize' screen (bug reported)
            - Add auto-update revision
            - Fix multithreading (review)
            - Research 'glibc' corruption
       + Add crawlering for POST+GET (auto test 'whole' page forms)
       + Update XSS payloads (vectors.py / DOM.py / DCP.py / etc...)
       + Advance Statistics results (show more detailed outputs)
       + Advance Exporting methods (create 'whitehat' reports (xml/json))
       + Advance “WebSockets” technology on XSSer 'fortune' option
       + Update Interface (GTK+)
   • Phase 2: New features:
       + Add 'code pre-check' option: Users can set which code will return target's website, to try to evade false positive results.
       + Add 'CSSer' option: Payloads for CSS injections.
       + Research/Search anti-IDS/NIDS/IPS... codes to evade XSS filters.
       + BurpXSSer: Create a Burp plugin (with Jython libs)
       + ZAPXSSer: Create a ZAP plugin (with Jython libs)

Expected results:

  • To deploy a new stable version of XSSer with GTk+/Web/Shell main features working propertly,

The code should be:

  • Clean and easy to follow
  • Include a full set of unit tests
  • Include good documentation

Knowledge Prerequisite:

XSSer is written in Python, so a good knowledge of this language is recommended, as is knowledge of HTML and Javascript. Also, is necessary to have some knowledge of application security and more in concret about XSS techniques.

Skill Level: Medium

Mentor: epsylon (psy) - OWASP XSSer Project Leader

OWASP ZAP: Dynamically Configurable actions

ZAP provides various mechanisms which allow HTTP requests and responses to be changed dynamically. So (for example) a string in an HTTP request can automatically be changed to another string.

It also supports a scripting interface, which is very powerful but at the moment difficult to use.

This project would introduce something inbetween thess 2 options - a powerful way of defining (potentially) complex rules using a wizard based interface.

The challenge will be to make it as usable as possible while still providing a wide range of functionality.

Brief explanation:

This component would provide a set of highly configurable 'actions' which the user would see up via a wizard.

So they would initially define when the action applies, based on things like regex matching on request elements. And they should be able to define multiple criteria with ANDs and ORs.

Then they would define the actions, which could include:

  • Changing the request (adding, removing or replacing strings)
  • Raising alerts
  • Breaking (to replace existing break points)
  • Running custom scripts (which could do pretty much anything)

They would then be able to switch the actions on and off from the full list of defined actions using checkboxes

Expected results:

  • A new ZAP add-on providing the above functionality

The code should be:

  • Clean and easy to follow
  • Include a full set of unit tests
  • Include good documentation

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: Simon Bennetts - OWASP ZAP Project Leader


OWASP ZAP: Enhanced HTTP Session Handling

Brief explanation:

ZAP can currently manage multiple sessions. This development would allow ZAP to better handle HTTP Sessions to provide different views of a given target depending on the different user's permissions that the targeted site supports.

This implementation such provide a set of methods to answer questions such as: 1)What nodes(pages) are available to a group of users and not to other groups of users 2)What nodes are available to different users but these contain significant differences in the HTTP headers and/or in the body content.

This will allow ZAP to be used to detect access control issues which would otherwise require manual testing. Expected results:

  • ZAP will have an understanding of both users and roles and be able to associate them with HTTP sessions.
  • The user will be able to associate credentials with different roles allowing ZAP to automatically authenticate as any user / role.
  • ZAP will be able to spider an application using a given user/role.
  • ZAP will be able to report the differences between different HTTP sessions.
  • ZAP will be able to show different views of the site in the site's tree tab with the pages visible for each session.
  • ZAP will be able to attack one session based on the URLs accessed in another session and report which appear to work.

Expected results:

Users will be able to:

  • specify exactly which alerts are included, by context, site or on an individual alert basis
  • specify what information is included and how it is layed out
  • specify a range of output formats, at least including HTML and PDF
  • include details of what testing has been performed (automatically generated where possible)
  • apply their own branding
  • save report templates, and apply templates downloaded from the ZAP marketplace

The code should be:

  • Clean and easy to follow
  • Include a full set of unit tests
  • Include good documentation

Knowledge Prerequisite:

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML and the HTTP protocol specification. Some knowledge of application security would be useful, but not essential.

Mentor: Guifre Ruiz - OWASP ZAP Dev Team


OWASP ZAP: Advanced reporting

Brief explanation:

The reports that ZAP generates are in a fixed format which is not particularly useful or attractive. This development would provide the user with a fine grained control over the contents, layout and branding of the reports.

Expected results:

A new user interface for genrating reports which is easy to use and provides the user with a wide range of options. The code should be:

  • Clean and easy to follow
  • Include a full set of unit tests
  • Include good documentation

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: Simon Bennetts - OWASP ZAP Project Leader


OWASP ZAP - SAML 2.0 Support

Brief explanation:

SAML 2.0 is an XML-based federated single sign-on (FSSO) protocol that uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, that is an identity provider, and a SAML consumer, that is a service provider. SAML 2.0 enables web-based authentication and authorization scenarios including cross-domain single sign-on (SSO). SAML specifications support many ways, called profiles and bindings, to generate and transport assertions between trusted entities The Web Browser SSO profile is of particular interest here since it enables web applications from 2 separate domains to leverage SSO easily by exchanging assertions via a web browser session.

ZAP provides various mechanisms which allow HTTP requests and responses to be changed dynamically. This project will enhance those capabilities to be able to detect and fuzz various elements and attributes of a SAML Assertion.

The scope of this project is limited to the following SAML bindings, profiles and protocols:

Profiles :

  • Web Browser SSO

Bindings:

  • HTTP POST
  • HTTP Redirect

Protocols:

  • Authentication Request Protocol

Expected results:

This component would enable ZAP to:

  • Detect SAML Assertions in HTTP requests and responses
  • Decode SAML Assertions
  • Fuzz various entities and attributes within a SAML assertion
  • Re-encode the assertion and send it forward

The code should be:

  • Clean and easy to follow
  • Include a full set of unit tests
  • Include good documentation

Users would have a choice either to fuzz the attributes within an assertion or just add/remove arbitrary attribute (to check for XML and SAML Schema Conformance).

Knowledge Prerequisite:

ZAP is written in Java, so a good knowledge of this language is recommended, as is knowledge of HTML and SAML 2.0 Protocol. Some knowledge of application security would be useful, but not essential. Understanding of SSO and Federated SSO is preferred.

Mentor: Prasad N. Shenoy

OWASP Security Research and Development Framework

Brief explanation:

This is a free open source Development Framework created to support writing security tools and malware analysis tools. And to convert the security researches and ideas from the theoretical approach to the practical implementation.

This development framework created mainly to support the malware field to create malware analysis tools and anti-virus tools easily without reinventing the wheel and inspire the innovative minds to write their researches on this field and implement them using SRDF.

Targeted Applications:

  • Packet Analysis Tools (Personal Firewalls, HIDS/HIPS, WAF, Network Analysis, Network Capture)
  • Malware Analysis Tools (Static, Dynamic, Behavioral)
  • Antivirus and Virus Removal Tools (Signature-based, Behavioral-based)

Expected results:

  • Implement XRAY Tool, Recursive Disassembler Tool (based on our disassembler)
  • Improve Pokas Emulator and its disassembler engine
  • Improve The Kernel-Mode Part and more beta-testing
  • Integrate SRDF in python using SWIG

Knowledge Prerequisite:

We need variety of skills in different languages and platforms. We need a good knowledge in C++ in windows. We need a python developer for integrating SRDF in python. We need C++ developers have a good knowledge in Assembly (for working in disassembling part) and we need C++ developers have a knowledge in Kernel-Mode(for Kernel-Mode improvement and beta-testing)

Mentor: Amr Thabet - OWASP Security Research and Development Framework Project Leader

OWASP ModSecurity CRS - Create "Sniffer-Mode"

Brief explanation:

The ModSecurity code includes a "standalone" version that wraps a light weight Apache/APR around the ModSecurity code. This is used as the basis for the ports to the IIS/Nginx web server platforms. The goal for this project task is to extend this standalone version so that it can accept a data feed of network traffic (e.g. libpcap) data as input and apply the ModSecurity CRS rules. One possible solution would be create a ModSecurity "plugin" for the Snort IDS.

Expected results:

This new sniffer mode would allow organizations to run ModSecurity/OWASP ModSecurity CRS in an out of line mode as they do IDS systems.

Knowledge Prerequisite:

C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.

Mentor: Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader

OWASP ModSecurity CRS - Port to Java

Brief explanation:

The goal is to have a ModSecurity version that can be used within Java servers (e.g. Tomcat). There may be methods to use JNI to call the standalone code from a filter in Tomcat.

Expected results:

This new version allow organizations to run ModSecurity/OWASP ModSecurity CRS in Java web servers.

Knowledge Prerequisite:

C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.

Mentor: Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader

OWASP ModSecurity CRS - Implement libinjection Code

Brief explanation: https://www.modsecurity.org/tracker/browse/MODSEC-327

libinjection (https://github.com/client9/libinjection) is a C library that detects SQLi attacks in user input. It is designed to be embedded in existing or new applications:

  • Fast > 100k inspections per second
  • No memory allocation
  • No threads
  • Stable memory usage (approximately 500 bytes on stack)
  • 500 lines of C code (plus a few kiobytes of data)

It is based on lexical analysis of SQL and SQLi attempts and does not use regular expressions.

Expected results:

The new C code in ModSecurity will allow us to add new SQL Injection detection methods to the OWASP ModSecurity CRS.

Knowledge Prerequisite:

C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.

Mentor: Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader

OWASP ModSecurity CRS - Implement DoS Prevention Code

Brief explanation: https://www.modsecurity.org/tracker/browse/MODSEC-265

Implement a request velocity learning engine to identify dynamic DoS thresholds for both the site and for the particular URL.

Expected results:

The new C code in ModSecurity will allow us to add new DoS Protection methods to the OWASP ModSecurity CRS.

Knowledge Prerequisite:

C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.

Mentor: Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader

OWASP ModSecurity CRS - Create a Positive Learning/Profile Engine

Brief explanation: https://www.modsecurity.org/tracker/browse/MODSEC-193

ModSecurity needs a profiling engine that implements the various AppSensor Detection Points - http://blog.spiderlabs.com/2011/08/implementing-appsensor-detection-points-in-modsecurity.html.

Expected results:

The new engine will implement more detection points to detect abnormal request attributes.

Knowledge Prerequisite:

C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.

Mentor: Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader

OWASP ModSecurity CRS - Create an Engine to Detect Application Flow Anomalies

Brief explanation:

Need an engine that can track normal application flow paths (click-flows) for business logic transactions - such as transferring money from accounts. After profiling normal application path flows, we want to then be able to alert to anomalies. This type of logic can help to prevent Banking Trojan attacks.

Expected results:

The engine will be able to alert on anomalous application flows.

Knowledge Prerequisite:

C programming and ModSecurity Development Guidelines - http://www.modsecurity.org/developers/.

Mentor: Ryan Barnett - OWASP ModSecurity Core Rule Set Project Leader