And the cli should report the missing ones

The code fails to maintain the indexes correctly

It should be easy to create a JUnit test from a Zest script, eg using a simple wrapper?

Scripts run from the command line should output in JSON, or at the very least have an option to do this.

A simple text match would be useful for those cases where you simply want to see if a specific piece of HTML is in a response or not. This can also be done with a regex of course but then you have to carefully escape all the funny characters which is error prone.

Only alpha numeric variable names seems to be accepted as a variable names in Zest. However, some applications such DWR do require to have variable names other than alphanumeric (ex:c0-e1).
Can this be addressed?

Support client side scripting via Selenium/WebDriver

As per https://groups.google.com/d/msg/mozilla-zest/B0bq4U2zOJo/YoI4o1_2L0YJ

The code currently assumes that all requests will have assertions, which is not necessarily the case

Maybe have something like a 'Test' element which is used by TestConditional and TestAssertion.

Add a new generic element type to represent loops.
Should also add elements to break and continue.
Initial implementations should also be made for looping through a list of specified values and looking through a set of values read from a specified file, as well as one for looping through integer values (start, end, step).
In all cases a specified token should be set to the value in the loop.

There should be no theoretical limit to the depth of loops possible (although there will be practical / sensible limits)

To be used by MitM proxies (like ZAP;) to allow Zest scripts to intercept / break on requests and responses

As per title - in some cases they are, in others not.

I think this condition should do two things:

• check if the header exists, and fail if it does not
• match the regular expression against the header value

It should find the header case insensitive. So a condition that works on X-Frame-Options should find x-frame-options.

One issue here is that multiple headers with the same name are allowed. For example it is not uncommon to have multiple Set-Cookie headers in the same response. Not sure how to deal with that. Maybe apply the regex to all the headers?

The current Transformations should be changed into 'Assignations".
So (for example) the ZestTransformFieldReplace would be replaced with an Assign which would set a specified token to the value of the field - which could be extracted via a ZestFieldDefinition, a regex etc etc
The field value could then be replaced by the token in future requests.
I think this is more flexible and hopefully logical.

Add a loop which loops through regex matches on a specifioed variable

The Then and Else statements are not copies, which breaks a whole load of things, including cut-n-paste in the ZAP add-on.

Define, implement and document a 'standard' set of tokens which are supported by the runtime.
Things like:

• request - the whole of the last request
• request.url - the last request url
• request.header - etc
• request.body
• response - the whole of the last response
• response.header
• response.body
• target.url - the target url for active (and generic?) scripts
• target.request - the whole of the target request
• target.param - the target parameter for active scripts
• target.value - the 'current' target value (expected to be replaced)

All relevant Zest elements should change to use these tokens instead of the current mechanisms

All elements should define a standard text representation, so that we dont end up with different implementations using different notations.
In theory someone could write a parser for these :)

This was a pragmatic 'hack' which was useful at the time, but means that scripts have an 'index' field that doesnt really make sense.

./zest.sh -script ../examples/BodgeIt_Register_XSS.zst

Error loading script /Users/dscarson/Documents/zest-master/dist/../examples/BodgeIt_Register_XSS.zst: com.google.gson.JsonParseException: java.lang.ClassNotFoundException: org.mozilla.zest.core.v1.ZestConditionRegex

As per the 'Int' one already added, but should allow rnadom 'sentances' to be built up.
eg
minWords
maxWords
minLettersPerWord
maxLettersPerWord

maybe even support different character sets?

ZestConditional should be made 'final' and use ZestExpression - this would be extended as per the current conditionals plus things like ZestExpressionOr and ZestExpressionAnd.
This will allow complex expressions to be built up.

Executing ZestAssignRegexDelimiters statement, like the one below, fails with null pointer exception.

{
   "prefix": "/DOCTYPE/",
   "postfix": "/en/",
   "location": "BODY",
   "variableName": "rr",
   "index": 5,
   "enabled": true,
   "elementType": "ZestAssignRegexDelimiters"
}

Result:

java.lang.NullPointerExceptionjava.lang.NullPointerException

Some of the expressions will only work on responses, when they should really work on requests, such as the URL matching.
This means that 'proxy' scripts using these expressions typically wont work as the script runs against the requests and responses separately.

Pauses for the specified number of ms

The low level tests pass but ZestExpressionURL fails when used in a script due to the way the patterns are initialised or, rather, not initialised.

have operations implementations send a ZestResponse a callback on ZestRequest for assertion checking.

When non-passive statements like ZestRequest are added to a passive type script and run, zest executes the non-passive statements too.

t seems that there is an issues if we modify any value/or use variable inside multipart-data body (inside visual dialog box)
The carriage return \r is remove. If we keep original request without any parameter value modification, it works.

example,

==> Initial request in dialog box.

-----------------------------23807238975742
Content-Disposition: form-data; name="state"

id1
-----------------------------23807238975742--

==> Inside script console
-----------------------------23807238975742\r\nContent-Disposition: form-data; name="state"\r\n\r\nid1\r\n-----------------------------23807238975742--\r\n

==> modify the request and use variable

-----------------------------23807238975742
Content-Disposition: form-data; name="state"

{{value1}}
-----------------------------23807238975742--

==> Inside script console
-----------------------------23807238975742\r\nContent-Disposition: form-data; name="state"\r\n\r\n{{value1}}\n-----------------------------23807238975742--\r\n

As on the above after variable replacement carriage return \r is disappear due to that multipart request fail or not work. If add manual \r after parameter modification it works.

\r must add after any kind of modification on parameter value.

Zest scripts can become very large if they also contain the response data. One of my tests is a 250KB JSON blob because it contains all the response bodies. I think in many cases storing the response data is not needed at all.

This would also make scripts much more lightweight and easier to embed in for example Minion.

There is no such thing as a regex standard: http://www.regular-expressions.info/refflavors.html
So we need to define a subset of regex expressions that can be safely used in Zest scripts.

eg see http://code.google.com/p/zaproxy/issues/detail?id=651

The Content-Type header is being dropped for POST requests, even when explicitly set in the Zest Request.
Theis means that POST requests for things like multi-part forms fail.

As per https://groups.google.com/d/msg/mozilla-zest/XhjJYyEqAvM/0jIqiq6dCHQJ

Support a new element which would invoke the named Zest script.
This will allow users to create smaller scripts which perform specific tasks.

We need a way to test if the protocol used for a previous request was using HTTPS.
This would allow us to write conditions for tests against HSTS, mixed-content and the secure flag on cookies.

Hi,

Currently redirection follow is only possible for GET request. The redirection is not possible for POST.
It would be really useful to have redirection on POST method.

Can you add this feature in Zest?

Kr,
Ph

See https://groups.google.com/d/msg/zaproxy-users/8EdgqM8zSrQ/e8PJdiEKgpkJ for more info.

Sometimes the case of a value does not matter. As an example, I am trying to match on an x-frame-options header but on www.mozilla.org it is set as x-frame-options.

In active scan rule, the user can not define the attack strings with either spaces or special characters. However, most of the attack strings do contain the special characters. So they may be required to be allowed.
The error would be: : escaped absolute path not valid

Enhance Zest so that it support the standard Java ScriptEngine mechanism

Zest is currently experimental and subject to significant change.
Should really be version '0' to indicate this, and introduce a 'minorVersion' to designate iterations within this

This should support regexes for including and excluding URLs
Note that this would act on Requests rather than Responses, so subtly different from other conditionals

Add option to allow redirects to be followed

This means you cant compare the values of 2 variables

I had a Zest script failing on me because it did not include the Accept: header. As a response the server returned a text/plain response instead of the original HTML document that I saw in ZAP.

Maybe there should be a default set of headers that Zest should always take and replay to make the request look as much as possible as one coming from a browser? How about at least User-Agent:, Accept:, Accept-Language:, Accept-Encoding: ?