Automated Scanning With ZAP & Zest Combination

690 views
Skip to first unread message

vedantam sekhar

unread,
Feb 10, 2014, 12:03:52 AM2/10/14
to zaprox...@googlegroups.com
Hi Group,

Please share if any one has written the Zest rules for scanning the XSS. In my application, default active scanning rule do not seems to be idenfying the issue which i am able to manually (<iframe> src=http://www.site.com </iframe>). Does these scripts uses the current session tokens? I tried creating an active scanning rule myself but i ran into issues.In other words, i want re-use these scripts everytime i get a new build(provided no changes to the forms..etc).Is there any additional configuration to be done?

Any help on explanations of parameters in Zest default template is also great.

Thanks for the help,

Sekhar




Simon Bennetts

unread,
Feb 10, 2014, 4:53:13 AM2/10/14
to zaprox...@googlegroups.com
Hi Sekhar,

Can you explain in a little more detail about the vulnerability, for example the vulnerable code into which you are able to inject the attack?
If the current XSS rule is not finding an XSS then we'll want to fix that :)

The Zest scripts _should_ use the current session tokens, but they are relatively new so I'll test that manually to confirm that.

If you save any script (including Zest ones) with the "Load on start" box ticked then those scripts will be loaded whenever you start ZAP. If they are Active Scan rules and enabled then they will automatically be run whenever you perform and active scan.

The parameters contain the data for the 'original' request that is available to test.
So
request.header    is the request header
request.body       is the request body
request.method   is the request method (eg GET, POST etc)
request.url          is the request URL
You can use the "Action - Print" to output the values of any parameter - just right click in the Message field to get a list of available parameters.
'target' is slightly different. This is the parameter you should change to be your attack.
Your script could be called to attack parameters in the url, header or body. The target parameter will be embedded in the relevant request.* parameter, eg request.url=http://www.example.com/test={{target}}
You can either change the target to be your attack in the script definition (by default it is set to "__replace__") or you can set it in the script prior to the request.
Does that make sense?
If not please let me know and I'll try to explain better ;)

Cheers,

Simon

vedantam sekhar

unread,
Feb 10, 2014, 5:57:07 AM2/10/14
to zaprox...@googlegroups.com
Hi Simmon,

I tried both the <iframe> src=http://www.site.com </iframe> & <script> alert (document.cookie) </script> as well for the vulnerable parameter. However, When i scan with ZAP by right clicking that URL and run the active scan no vulnerabilities are reported by tool. But i can find through manual testing. Is there a way, i can include my custom strings to the active scan rule directly? I am able to do the same through a file for Fuzzing, but the there i need to manually select the string and run the fuzzing. So i am checking the options.

For example the request is;

POST http://<IP>/createRole.dwr HTTP/1.1
Host: 10.1.1.1:Port
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Content-Type: text/plain; charset=UTF-8
Referer: Referrer URL
Content-Length: 9391
Cookie: JSESSIONID=HQAABFDGgkAUjK9X5McEIiNo

Body:
-------
callCount=1
windowName=
c0-scriptName=RoleUIService
c0-methodName=createRole
c0-id=0
c0-e1=string:%3Ciframe%3E%20src%3Dhttp%3A%2F%2Fwww.site.com%20%3C%2Fiframe%3E
c0-e2=string:lk%0A%09%09%09%09%09%09%09
c0-e3=string:0
page=%2Fsdp%2Fui%2Fhome%2Froles%3Faction%3Dcreate
httpSessionId=HQAABFDGgkAUjK9X5McEIiNo
scriptSessionId=F301817DE699FA7C1BABEB9F27EAAF76

HttpSessionID/ScriptSessionID are anti csrf tokens in the request body.

You said "
The parameters contain the data for the 'original' request that is available to test" - Does this mean, i need to copy the values of into these respective fields in the script? Default template presently has {{request.url}}. Should i remove this and replace with the URL in the original request?

"This is the parameter you should change to be your attack." - In my request c0-e1 is vulnerable. So, do i need to mention that? or actual XSS script?

When i tried with Resending request / Fuzzing / Manual request editor - the XSS works. But when going through Zest - I get 403 forbidden error and when i open the URL in Browser in ZAP, it says - Unable to find the script session ID which DWR is expecting i believe.

Thanks for the help...

Sekhar

Simon Bennetts

unread,
Feb 10, 2014, 7:12:39 AM2/10/14
to zaprox...@googlegroups.com
Hi Sekhar,

First things first - does ZAP recognize your parameters?
To find this out look at the request in the Sites tree - if the name is something like POST: createRole.dwr(callCount,windowName,c0-scriptName.c0-methodName, ..) then its ok.
So each of the parameter names should be listed in brackets after the page name.
I'm asking this because in 2.2.2 ZAP can only handle URL and body parameters of the form aaa=bb&cc=dd ie with the key-value pairs separated by '&' and in your example it looks like the key-value pairs might be separated by newlines.
The next version of ZAP allows you to define custom separators - you can try it out via the weekly releases.

Your script will be invoked once for every parameter in every page, which is why we use tokens.
You should typically only change the "attack" parameter, all the other ones will be set up correctly (assuming ZAP understands your parameters).

The fact that you are getting a 403 is not a good sign, as that might mean that the session token is being lost.
But the first potential problem is with the parameters, so lets start with those.

Cheers,

Simon

vedantam sekhar

unread,
Feb 10, 2014, 8:53:16 AM2/10/14
to zaprox...@googlegroups.com

Hi Simmon,

Yes, i noticed that the ZAP does not recognise the parameters. what i see is only this;

POST: RoleUIservice.Create.dwr(CallCount). I have installed the ZAP weekly release and it is as well same. I observed while running the active scan only the URL is scanned and i dont see any parameters in the body is scanned. That might be the reason i am unable to find the XSS.

What i am trying to achieve is;

a. Use Selenium IDE to record the application module wise. For ex: Add-Role
b. Play the Selenium IDE  through ZAP proxy
c. Get the Zest scripts ready - I am thinking of making active scripts so that all the modules can use them.

When new build comes, i will be playing the Selenium IDE records-> trigger the Active scan & get the reports.

Thanks and Regards,

Sekhar

Simon Bennetts

unread,
Feb 10, 2014, 11:14:17 AM2/10/14
to zaprox...@googlegroups.com
OK, I have some bad news .. and some good news :)
The bad news is that if ZAP doesnt recognize the parameters correctly then it cant scan them properly - it wont know what to inject where.
And ZAP 2.2.2 will not be able to handle this.

The good news is that ZAP 2.3 will be able to handle this.
And you can try this out right now by either using the latest weekly release or building ZAP from source control.
Having said that, we are working on this right now, so it is bleeding edge and might need to tweaking.
Would you be interested in trying this out?

Cheers,

Simon

vedantam sekhar

unread,
Feb 10, 2014, 9:54:32 PM2/10/14
to zaprox...@googlegroups.com

Definitely i would like to try this out Simon.Good to hear that 2.3 can handle :) I have already installed weekly release.what tweaking do i need to?I see in the session properties section - POST Keypair values as &. Is there something to do here?


Thanks and Regards,

Sekhar


On Monday, February 10, 2014 10:33:52 AM UTC+5:30, vedantam sekhar wrote:

Simon Bennetts

unread,
Feb 11, 2014, 5:37:36 AM2/11/14
to zaprox...@googlegroups.com
OK, so there are 2 ways we can do this, but lets start with the one that hopefully we be the easier option.

Yes, you are right that its the Session Properties, so what you need to do is
  1. Right click the top node of your app in the Sites tree
  2. Select "Include in Context -> 1"
  3. Select the Structure tab for Context 1
  4. Change the "POST key value pair separators" to the 'right' characters

What characters are you using to separate your POST key value pairs? Newline or ??

I've only tested this with alpha-numerics so I might need to tweak the code eg to handle hex notation ;)

The other option we have is to use scripting, but that is even more bleeding edge, so lets try and get this working first.

Cheers,

Simon

vedantam sekhar

unread,
Feb 12, 2014, 2:13:56 AM2/12/14
to zaprox...@googlegroups.com
Hi Simon,

POST key value Pair separators used are Space. I have tried both \t & \n but still no luck.


Thanks and Regards,

Sekhar

On Monday, February 10, 2014 10:33:52 AM UTC+5:30, vedantam sekhar wrote:

Simon Bennetts

unread,
Feb 12, 2014, 4:13:29 AM2/12/14
to zaprox...@googlegroups.com
Just a space?
I assume you tried that as a separator as well?

Do the full set of params get shown in the Sites tree?
You may need to visit the relevant pages again, so try that and see if a new node is created in the tree with all of the params.

If that doesnt work could you attach a file with an example POST body and I'll try it out.

Many thanks,

Simon

vedantam sekhar

unread,
Feb 12, 2014, 4:25:25 AM2/12/14
to zaprox...@googlegroups.com

I've tried with CR+LF seems to be working Simon. Now i can see the requests along with their parameters brackets.

  • POST:UserUIService.createUser.dwr(,5A02077A8,8,A4D4BDEA45186,D7 ,YMZ2vPmKESr scriptSessionId,action%3Dcreate httpSessionId,call,home%2,test_1234 c0-e8,test_1234 c0-e9,onfirm:reference:c0-e8, ldapUserProperti,ount,pdp%2,ui%2,users%3)


  • while the original request is

callCount=1
windowName=
c0-scriptName=UserUIService
c0-methodName=createUser
c0-id=0
c0-e1=string:test
c0-e2=string:tt
c0-e3=string:t
c0-e4=string:t
c0-e5=string:t
c0-e6=string:t
c0-e7=string:test_1234
c0-e8=string:test_1234
c0-e9=array:[]
c0-param0=Object_Object:{userName:reference:c0-e1, firstName:reference:c0-e2, lastName:reference:c0-e3, emailAddress:reference:c0-e4, jobTitle:reference:c0-e5, company:reference:c0-e6, password:reference:c0-e7, pwdConfirm:reference:c0-e8, ldapUserProperties:reference:c0-e9}
c0-param1=array:[]
batchId=6
page=%2Fsdp%2Fui%2Fhome%2Fusers%3Faction%3Dcreate
httpSessionId=Ddk6PIAKW91-CYMZ2vPmKESr
scriptSessionId=B8CC8CA4D4BDEA45186C5A02077A8CD7

Thanks and Regards,

Sekhar


On Monday, February 10, 2014 10:33:52 AM UTC+5:30, vedantam sekhar wrote:

vedantam sekhar

unread,
Feb 12, 2014, 4:30:14 AM2/12/14
to zaprox...@googlegroups.com

Hi Simon,

I attached the

POST http://<IP>:<Port>/dir/dwr/call/plaincall/UserUIService.createUser.dwr HTTP/1.1

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Content-Type: text/plain; charset=UTF-8
Referer: http://<Server>:<Port>/dir/ui/home/users?action=create
Content-Length: 684
Cookie: JSESSIONID=Ddk6PIAKW91-CYMZ2vPmKESr
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Host: <IP>:<Port>





callCount=1
windowName=
c0-scriptName=UserUIService
c0-methodName=createUser
c0-id=0
c0-e1=string:test
c0-e2=string:tt
c0-e3=string:t
c0-e4=string:t
c0-e5=string:t
c0-e6=string:t
c0-e7=string:Test_1234
c0-e8=string:Test_1234

c0-e9=array:[]
c0-param0=Object_Object:{userName:reference:c0-e1, firstName:reference:c0-e2, lastName:reference:c0-e3, emailAddress:reference:c0-e4, jobTitle:reference:c0-e5, company:reference:c0-e6, password:reference:c0-e7, pwdConfirm:reference:c0-e8, ldapUserProperties:reference:c0-e9}
c0-param1=array:[]
batchId=6
page=%2Fsdp%2Fui%2Fhome%2Fusers%3Faction%3Dcreate
httpSessionId=Ddk6PIAKW91-CYMZ2vPmKESr
scriptSessionId=B8CC8CA4D4BDEA45186C5A02077A8CD7


On Monday, February 10, 2014 10:33:52 AM UTC+5:30, vedantam sekhar wrote:

vedantam sekhar

unread,
Feb 16, 2014, 10:08:37 PM2/16/14
to zaprox...@googlegroups.com
Hi Simmon,


Since we are facing issues with ZAP handling the DWR based applications, is there a chance the same will be incorporated in 2.3?

Thanks and Regards,

Sekhar



On Monday, February 10, 2014 10:33:52 AM UTC+5:30, vedantam sekhar wrote:

Simon Bennetts

unread,
Feb 18, 2014, 12:15:59 PM2/18/14
to zaprox...@googlegroups.com
Hi Sekhar,

I've had a play around with the DWR demo app and have created the attached 'input vector' script.
You will need to use a recent weekly release and import it as an "Custom Input Vector" script.
By default it just works on POST requests with URLs ending in '.dwr' but thats easy to change.
You also need to enable the script before it will be used, and you can uncomment some of the println statements if you want to see whats going on.

Please let me know if this works for you.

Cheers,

Simon
dwr test.js

vedantam sekhar

unread,
Feb 21, 2014, 11:34:13 AM2/21/14
to zaprox...@googlegroups.com
Thanks a ton Simon. The Script worked.
 
Now, ZAP looks like identifying the parameters and testing them as I can see the requests while "Active" scan is running. I "loaded" the script as ECMA script & type as "Input vector". Now, when I run the Active Scan for a URL I see all the parameter are tested. One observation is Missing an XSS vulnerability(threshold as INSANE). While I have an XSS vulnerability at one parameter(confirmed through Fuzzing) same is not reported through the active scan though ZAP sends the '"<script>alert(1);</script> as input(as I can see in the Request & my Application). I also see minimal XSS strings are sent. I am using the latest weekly release.
 
Thanks and regards,
 
Sekhar
 
 
 

On Monday, February 10, 2014 10:33:52 AM UTC+5:30, vedantam sekhar wrote:

Simon Bennetts

unread,
Feb 24, 2014, 5:06:03 AM2/24/14
to zaprox...@googlegroups.com
Hi Sekhar,

Thats good news - I'll tidy it up and check it in so it will be included in the release :)

The XSS code checks where user input is reflected in the response and tries to craft attacks that it can be fairly sure are not false positives.
Does the '"<script>alert(1);</script>" get reflected in the response?
If so can you paste in the surrounding HTML fragment?

Cheers,

Simon
Reply all
Reply to author
Forward
0 new messages