Tuesday 28 May 2013

Accepted project: Dynamically Configurable actions add on

Short description: A plugin for OWASP Zed Attack Proxy will be developed to let users create and run Mozilla ZEST scripts with an as easy as possible interface.

Additional info: https://www.owasp.org/index.php/GSoC2013_Ideas#OWASP_ZAP:_Dynamically_Configurable_actions

Introduction

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.

Zest is a specialized scripting language developed by the Mozilla security team and is intended to be used in web orientated security tools. A Zest add-on for ZAP already exist, but it is in a very early stage, and let the user only create very simple scripts.

This proposal will guarantee the user to create longer and more complex Zest scripts, introducing new structures as Complex Conditionals, Asserts and an easy and intuitive GUI, providing a wide range of functionality. 

Project Goals:

After discussing the idea with the mentor, I had set the following goals:
  • Create a full documentation (both wiki and javadoc) for the current implementation of Zest and his add-on for ZAP: 
  • the current implementation of zest contains no javadoc, and I think that, even if the code is quite simple to read, a full documentation for future implementations and extensions is reccomended; 
  • Improve Zest (Complex Conditionals, Assertions, ...) 
  • Find some good integration points and create a standard and extensible interface that can be easily reused to add new integration points (maybe introducing hooks like ActionHooks for extensions); 
  • Create some zest examples reguarding the integration points found; 
  • Create an intuitive GUI for a simple creation of the zest scripts, keeping in mind that: 
    • the creation must be as simple as possible; 
    • the GUI must guarantee a wide range of funcionality to the zest script; 
  • Create all the documentation needed for an user with no experience in vulnerabilities and attacks to let him create a zest script. 
All the work must observe these requirements:
  • The code must be: 
  • Clean and easy to follow; 
  • Include a full set of unit tests; 
  • Include good and full documentation. 

Work and implementation
In this section I will describe more in detail the work. Please look the timeline in order to see how I suppose to split the work and not look at the order of the points in this section.

Documentation of the existing code
First step is the creation of the whole documentation for zest. Then the wiki will be completed with the missing pages in the zest-core section.

Design (detailed specs) & creation of usecases
Second step consists in a designing phase, in order to write down a simple and extensible interface for the creation of zest scripts.

This designing phase must be combined with some examples of usage, that will be considered as possible integration points for the addOn. By the way, the idea is to guarantee the usage of the add on for the examples above, but must be more flexible, in order to let users create their own usecases (in the future other extensions and integrations has to be developed easily).

Some usecases are the following:
Suppose to have a wizard with 3 steps (each of wich with a different anti CSRF token), and user wants to test a parameter in the last step, and he has to pass through the first two steps;
Suppose that a WEB application detects an attack and logged the user out; the user will be able to detect this with a zest script and reauthenticate in a very easy way;
Suppose a user wants to edit manually the requests (or run a script) when a given condition happens: he will simply set the conditional in the zest script and put a break point;
Suppose a user wants to test a set of string which can cause injection: he will simply set up the zest script changing the requests in order to test the strings and set a break point when an injection occurs.


other scenarios will be added during this phase.


Implementation
This part includes the following stages:
  1. Improve the existing zest code: 
    1. construption of Complex Conditions, collecting simple conditions (regex, status code, response time ones). More details about the implementation of this feature can be found here: https://groups.google.com/forum/?fromgroups=#!topic/mozilla-zest/5Uhs67ogLkg
    2. managing break points (suspension of the script until an event occurs); 
    3. managing scripts (suspension of the zest script, run of another script specified by user, resume of the zest script); 
  2. Creating/improving the ZAP add on. 
The gui
The current version of the zest add-on guarantees a very unstructured way to add the requests/responses to the zest script, but the creation of IF/THEN/ELSE statements and the configuration of the actions is quite difficult. By the way, the usage of a wizard to set up the action could be too structured for the user.

In the following line I'll show you some extracts of the final GUI.


First this is a snaphot of the current way perspective:





In the current perspective the user is able to add IF/THEN/ELSE clauses and to modify the parameters of the requests.


This is the current perspective for manipulating requests:





It is a bit difficult to use: now we have only two parameters, but suppose to have a much longer body. It is quite difficult to manage it.




This second image represents a simpler way to edit requests and responses: the user should only edit the “editable” strings in the TextField.


With a right click the user is allowed to add new fields, remove fields, the add-on will then create the complete body of the request.


This perspective gives also the user the opportunity to mark some parts of the editable fields. These marked parts can then be changed with some other values (for example a list of String given by the user through a text file) or can be stored into token in order to be used again later in the script.


In the following image, is showed the current way to add a conditional.





To put some action inside the IF clause, the user has to right click on the if, and decide to add a new action, or condition.


The current perspective does not allow users to create more complex conditions: the usage of AND, OR, NOT clauses are not allowed here.


The final GUI will let the user write conditionals using a textField as the following:





lets call "condRegex1", "condResponseTime" and "conditionStatusCode" simple conditional. All the simple conditionals can both be defined in the text field or be defined through name. Suppose for example we want to define condRegex on the body of the request as follow:

"\Q<script>alert(1);</script>\E"


The application will then associate univocally condRegex1 and "\Q<script>alert(1);</script>\E".


The user will see a label containing the full declaration of the simple condition putting the cursor on it, and he will be able to edit the condition with a double click on the name of the simple condition.


The application will then parse the text field creating the full Conditional with a BuilderPattern.


In this case, the creation of the simple criterias remain more or less the same of the current version.

You can see a better description with a graphical perspective: https://groups.google.com/forum/?fromgroups=#!topic/mozilla-zest/5Uhs67ogLkg

and here you can download a little demo of the front end of this part:

https://dl.dropboxusercontent.com/u/5100168/OWASP/prototype.jar

The Repository is at this link:

https://bitbucket.org/vankar/zest-complex-conditional

The case of the break points can be managed with a pop up which rise with the correct condition. The popup is structured into tabs, and lets the user make all the actions he needs to. The zest script resumes once user press apply or ok to the pop up. 

Timeline
The project has substantially these deliverables:

  • design; 
  • develop; 
  • documentation; 
  • test. 

The main idea is to loop between these 4 steps:
  1. first the design a new usecase of zap defining an example of usage; 
  2. develop hooks and integration; 
  3. creation of the documentation about the code already developed; 
  4. test. 
This timeline is very flexible, and allows to put other phases, for example a review one, ie after people have had a chance to play with the code.
About me


Short bio / overview of your background:


2011-current:

M.S., University of Padua. Currently pursuing the M.S. in Computer Engineering.


2008-2012:

B.S., University of Padua, 93/110. Bachelor in Information Engineering


M.S. exams:

Data Bases 26/30


Computer Networks 30/30 cum laude


Parallel Computing 30/30 cum laude


Data Structures And Algorithms 2 30/30


Strategic Enterprise Management 30/30


Current GPA:
29.2/30
 
Coding Skills

What platform do you use to code? Hardware specifications and operating system

I always work under Linux. I often change distribution, but now I've installed Linux Sabayon (gentoo based & preferred one) and Ubuntu.


Hardware: Laptop Dell XPS 17: Specifications:
CPU: intel i7-740
RAM: 4GB DDR3 1.333 GHz
HDD: 500GB


Did you ever code in C or C++/Perl/python/..., yes/no? what is your experience?I have good exeperience with Java and C++ (Java is the better known). I can also have experience with BASH, C, little of Python and some others.

Here a little description of the projects I collaborated for:

Bachelor Thesis
Title
eLaw: automatic management of notarial deeds

Supervisor
Professor Enoch Peserico and Engineer Federica Bogo

Keywords
eLaw, automatic, management, notarial deeds

Description
This work consists on the description of the productive and working model of a new software, whose aim is the automation of notarial deeds management. This document explains the usage of important informations retrieved in a notarial deed and describes how these informations are used in order to fill automatically some forms under the ministerial directives. The software here described is an OpenOffice extension which is supposed to be a valid alternative of the actual notarial softwares semplifying and automating some of the notary work. The pros of this work are the easy-to-use interface and the automatization. Reading this work you'll also see how this application can be easily used in other contexts.

Experiences

2011-current, University of Padua

"Web Quality Project"I'm involved in the Web Quality Research Team. Our goal is to perform a complete crawl of the italian web in order to test and compare different ranking algorithms. My role is to manage the crawl (hardware and software perspective) and to write an efficient extension of the Heritrix web crawler. Here i am making a large use of Java and Bash, I'm also using Spring framework to write Heritrix extension, tomcat and jsp.


2012,ERASMUS-LLP (IP) Course “Secure WEB Applications: Best Practices for Protection & Development” Glamorgan University, Pontypridd
Intensive Program on the topic of Web Security and the best practices for Protecting & Development.

2012, University of Padua
DNA Assembly
I worked in a DNA Assembly project for my Parallel Computation exam. My role was to create and to study the efficiency of the parallelization related to the extraction and the filtering of reads. Here i used C++, POSIX threads.


2012, University of Padua
Covering Firm Web Application
I collaborated on the creation of a web app lication for my Data Bases exam. The application had to manage orders, catalogue and warehouse for a covering organization. Here i used Java, OpenOffice UNO library, Castor, JDOM, XML and DTD.


2011, University of Padua
GPS for maemo
I collaborated on the creation of an application for a Nokia maemo based n900 for the Embedded System exam. The goal of this app is to get data from GPS sensors and to plot this data in a 2D map. Here i used C++, Qt and Maemo framework.

If you apply for a project on our ideas list, have you experience in the areas listed under "Desired knowledge"?
As you can read above, or in my web site, I have the experiences listed as Desired Knowledge.

Contact
Full Name: Alessandro Secco

University / current enrollment: University of Padua (Italy). M.S. in Computer Engineer.

Web site: http://www.dei.unipd.it/~seccoale/

mail: seccoale@gmail.com
References

https://www.owasp.org/index.php/GSoC_SAT
https://www.owasp.org/index.php/GSoC2013_Ideas#OWASP_ZAP:_Dynamically_Configurable_actions
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/guifre/3006
https://groups.google.com/forum/?fromgroups=#!topic/zaproxy-develop/TloQLHSJmdE
https://developer.mozilla.org/en-US/docs/Zest
https://code.google.com/p/zap-extensions/wiki/AddOn_Zest
https://github.com/mozilla/zest/wiki
https://groups.google.com/forum/?fromgroups=#!topic/mozilla-zest/5Uhs67ogLkg




Any advice or comments would be gratefully welcome.