Zest complex conditionals

[Alessandro Secco]

Hi all,
I'm Alessandro Secco, a 23-year-old student in Computer Engineering.
I have already submitted a proposal for the GSoC ( https://www.owasp.org/index.php/GSoC2013_Ideas#OWASP_ZAP:_Dynamically_Configurable_actions ), and I'm improving it day by day.
I exchanged some emails with Simon Bennet, and I started to look inside the code of Zest.

I noticed that now zest does not support complex conditionals, so I was wondering if it could be a nice idea to implement something similar.

Simon already told me that one of the most important aim of zest is to be esy, but I think that complex conditionals could be very useful for zest scripts.

I'd like to know your opinion about this and about my idea.

An example of the current way to express a conditionals is the followin (extracted by Bodgeit_Register_XSS.zst example):

{

      "regex": "\\Q\u003cscript\u003ealert(1);\u003c/script\u003e\\E",

      "location": "BODY",

      "ifStatements": [

        {

          "message": "There is an XSS in the username field",

          "index": 6,

          "elementType": "ZestActionFail"

        }

      ],

      "elseStatements": [

        {

          "targetParameter": "",

          "index": 7,

          "elementType": "ZestActionScan"

        }

      ],

      "index": 5,

      "elementType": "ZestConditionRegex"

}

Observe that there is no way to express combination of conditional.

I think that it could be possible to represent even complex and composed Conditionals encapsulating different "SimpleConditionals" in a

single "ComposedConditional".

A SimpleConditional could be a ZestConditionRegex, a ZestConditionResponseTime, a ZestConditionStatusCode or even a ZestConditionURL.

A ComposedConditional is a collection of SimpleConditional, connected by AND, OR, NOT criterias and parenthasis.

The main goal is to allow user to use even complex conditionals writing a Zest script in a very simple way.

I know that the first aim of Zest is to be easy, otherwise people will prefer to write java, python, ... programs, but I also think that

the usage of ComposedConditionals can be very useful and not too complicated to use in the creation of a zest script.

Currently I'm not sure about how to modify Zest syntax in order to allow ComposedConditionals, but I think that a possible syntax 

could be something like the following (or something similar):

{

      [

{

"regex": "\\Q\u003cscript\u003ealert(1);\u003c/script\u003e\\E",

"location": "BODY",

"index":3,

"elementType": "ZestConditionRegex"

}

"booleanOperator":"AND",

{

{

"code": 200,

"index": 4,

"elementType": "ZestConditionStatusCode"

}

"booleanOperator":"OR",

{

"booleanOperator"="NOT",

{

"greaterThan": true,

      "timeInMs": 1000,

"index": 5,

"elementType":"ZestConditionResponseTime"

}

}

}

      ]

      "ifStatements": [

        {

          "message": "example",

          "index": 6,

          "elementType": "ZestActionFail"

        }

      ],

      "elseStatements": [

        {

          "targetParameter": "",

          "index": 7,

          "elementType": "ZestActionScan"

        }

      ],

      "index": 8,

      "elementType": "ZestComposedCondition"

}

I'm currently not sure about some things, for example if it is really needed to represent each SimpleConditional with a different element and an index or to encapsulate everything in the container "ZestComposedCondition"

What's your opinion about this?

About the creation of these ComposedConditional, I think that a BuilderPattern is perfect: easy to use and easy to develop.

every comment, idea, opinion, feedback and anything else is welcomed!

Cheers,
Alessandro.

[Simon Bennetts]

Hi Alessandro,

Could you mock up how the complex conditionals might appear in the ZAP scripts tab?
Thats what I did for myself at the start for other Zest elements and I think it helped me.
I'd also be interested in hearing/seeing how you think the UI would work around creating and modifying them.

I like the idea of complex conditionals and thought about adding them at the start.
But I decided it would be too complex and unnecessary at that stage.
But I'm very happy for them to be added, as long as they are easy and intuitive to use.

Cheers,

Simon

[Alessandro Secco]

Hi Simon,

Well, the workflow in my mind is the following:

1. The user adds a new Condition in the zest script tab (as in the current version);
2. a pop up appears and let the user create multiple Simple Conditional (regex, response time, status code and url, each more or less in same way as the current version);
3. the user names each simple conditional with a String;
4. the user will fill a text field with autocompletion collecting all the simple conditional using the names he gave to the condition in step 3.
   
   
   

The Text Field in the example will appear as in the following example:

The autocompletion of the text field will help the user with the names of the simple conditionals.
Viewing the text field, if the user put the cursor upon the name of a simple condition, then a label appears, showing the detailed declaration of the conditional.
To edit that simple conditional user has to double click on that name, or click a button in the same label.

The backend works as follows:

in phases 1,2 and 3 a Map<String, Condition> is created;

in phase 4 the application first helps user writing down the name of the simple conditionals, then will create the composed condition parsing the text field and using a BuilderPattern to create the binary boolean tree associated to the statement.

I hope that this description was clear. If you want more details just ask. :)
Any question, comment, suggestion or feedback?

Cheers,
Alessandro

[Alessandro Secco]

Hi all,
Today I had implemented a little prototype of the front-end of the application. I'll try to describe you better the workflow:

First, given the current Zest Scripts tab perspective, the user will open the wizard right clicking. This is the perspective:

At this point, user is able to create different types of Simple Conditionals, based on regex, status code, response time or URL.
In our example, user wants to create first a condition based on regex. In the previous screenshot, he will click on the "Add Simple Condition" button:

Above the pop up containing the details of the Regex condition the user wants to create. The button "Save" saves the condition.

Here you can see that in the second comb box is displayed the name of the simple conditional and the type. User can create different types of simple conditionals and then collect them together using the text pane in the bottom of the window.

For example the user can create a response time condition:

and a condition based on Status code:

And then he will be able to put them together:

The final perspective with the whole complex condition is the following:

Then, pressing the "Add Complex Condition" button, user will put the whole condition in the zest script.
The backend of the application will parse the string, and will then generate the correct code for the script.

I have created a repository on Bitbucket where you can see the code: https://bitbucket.org/vankar/zest-complex-conditional

If you want only to play with the front end, you can download the executable jar here: https://dl.dropboxusercontent.com/u/5100168/OWASP/prototype.jar

[ to use the jar:

1. download in a folder;
2. cd to that folder;
3. java -jar prototype.jar

Then the front end starts (not zap, only the wizard for the creation of the complex condition).

].

Note that 

1. the code needs to be refractored and cleaned (and there is no comment);
   
2. the code can be improved making other decisions (it is just a demo);
3. The Front end had  been implemented using the Zest Core for the creation of the conditions, but does not create any zest script;
4. The current front end works is not connected to zap at the moment (as I hadn't found the repository for the zest add on for zap).
   
   

Any comment, suggestion, question is welcomed.

Cheers,
Alessandro

[Simon Bennetts]

Great - I'll have a look at this early next week.
FYI the ZAP Zest add-on is in the zap-extensions project, in the 'alpha' branch: https://code.google.com/p/zap-extensions/source/browse/#svn%2Fbranches%2Falpha%2Fsrc%2Forg%2Fzaproxy%2Fzap%2Fextension%2Fzest

Many thanks,

Simon

On Friday, 26 April 2013 13:18:15 UTC+1, Alessandro Secco wrote:

[Simon Bennetts]

Been thinking about this from the Zest language perspective.

Right now the boolean expressions are part of both Assertions and Conditionals.
That means they are fairly limited, duplicate code and are not easy to combine.

How about we introduce a new Zest element, something like ZestTest / ZestBoolean / ZestCondition
I'll go with ZestBoolean for now, but thats just so I can refer to something - happy to change the name.

So in java a ZestBoolean will be abstract and have a method like:

public boolean evaluate(ZestResponse response);

ZestAssertion and ZestConditional will use this and no longer be abstract.
So instead of having ZestConditionRegex we will have ZestConditional which uses ZestBooleanRegex (?)
We can then add new elements like ZestBooleanAnd, ZestBooleanOr which each take a list of ZestBoolean elements.
This way we can build up complex conditionals. I dont _think_ we need brackets as the And and Or elements implicitly define them, but I could be wrong.

So a test could look like:

ZestConditional

• ZestBooleanAnd
• ZestBooleanOr
• ZestBooleanRegex (regex exp1)
• ZestBooleanRegex (regex exp2)
• ZestBooleanStatusCode (200)
• List <ZestStatement> ifStatements etc...

Does that make sense? And is it a reasonable approach??

Of course this doesnt address the UI :)

We could have a wizard like you've suggested Alessandro, or have the nodes appear in the Scripts tree.

Or we could actually have both, and I think that might make sense - sometimes a wizard would be best, other times the separate nodes might be more useful.

This would probably be a 'breaking' change, but these are still early days for Zest, so if its the right way to go then breaking things shouldnt be a big problem.

Thoughts anyone?

Cheers,

Simon

On Friday, 26 April 2013 13:18:15 UTC+1, Alessandro Secco wrote: