ZAP GUI - Active Scan versus Fuzzer

1,290 views
Skip to first unread message

Usman Waheed

unread,
Aug 2, 2013, 9:53:17 AM8/2/13
to zaprox...@googlegroups.com
Hi,

I tried to use ZAP (GUI mode) to find some XSS vulnerabilities i know exist in a web app (cgi perl) i setup with Apache on a workstation.
I used Chrome and surfed URLS in the web app through ZAP in order to build a site tree.

Then i specifically picked (selected) one cgi perl script that processes a web form and performed an Active Scan (Active Scan URL only) on it.
I set the attack setting to low, medium, high and insane to see if it discovers the reflected XSS. 
The scanner ran fine in all cases, reported its findings but did NOT report the XSS that i know exists.

On the contrary if i use the Fuzzer and select the web param to fuzz on and then used the built in fuzzer list(s) the REFLECTED XSS is reported.
So the fuzzer does its thing and reports the XSS.

I then looked at all the POST requests in the active scan for that one URL and saw that it performed a bunch of injections but none of them was able to pick the XSS.
What i did not see in all these Active Scan POST requests are any specific XSS injections for eg: <script>alert('xss')</script> which were there in the fuzzer despite the 
fact that my settings have the Injection Plugin Category Enabled and the following test names enabled as well:

Server Side Include
Cross Site Scripting (Persistent) - Prime
Cross Site Scripting (Persistent)
SQL Injection
CRLF Injection
Parameter Tampering
Cross Site Scripting (Persistent) - Spider

I wonder why when i run the Active Scanner it does use XSS specific inputs for the scan although the settings are ON for it.

Am i missing something here?

Thanks,
Usman






Simon Bennetts

unread,
Aug 2, 2013, 11:49:01 AM8/2/13
to zaprox...@googlegroups.com
The fuzzer doesnt actually report any issues, it just throws the attacks you specify at the field and tells you if the attacks also appeared in the result. You need to manually examine the results and decide if they are real vulnerabilities.

Do you have the "Cross Site Scripting (Reflected)" plugin enabled? Thats the only one which will detecting reflected XSSs.

Note that this rule doesnt just throw <script> attacks at a page, it tries to be more sensible - see https://code.google.com/p/zap-extensions/wiki/AddOn_ascanrules for an overview.

If you do have it enabled and it hasnt found a known vulnerability then you might have found a situation it doesnt cope with.
If so please let us know the details (eg the attack and relevant html) and we'll fix it.

Many thanks,

Simon

Usman Waheed

unread,
Aug 5, 2013, 6:40:20 AM8/5/13
to zaprox...@googlegroups.com
Hi Simon,

I have the Cross Site Scripting (Reflected) plugin enabled but ZAP's "Active Scan" is still not able to pick up the reflected XSS.

Noted below is the html web form and the perl cgi-script.

Thanks,
Usman

HTML
<html>
<head><title>Test</title></head>
<body>
<b>Testing</b>
<form METHOD=POST action=http://owasp-t01/cgi-bin/form1.pl accept-charset="UTF-8">
<textarea name="tarea" cols=60 rows=5></textarea>
<br>
<input type=submit name=submit value=SUBMIT>
</form>

</body>
</html>

PERL CGI
#!/usr/bin/perl

use CGI;

my $query_params = CGI->new;
my $postdata  = $query_params->param('tarea');

print "Content-type: text/html\n\n";

print "Here is what the user submitted: <br>$postdata<br>\n";




Usman Waheed

unread,
Aug 7, 2013, 8:23:26 AM8/7/13
to zaprox...@googlegroups.com
I configured my apache test server on my test machine (owasp-t01) to process SSL traffic and basically took the same web form but instead of it being a POST HTTP request changed it to POST HTTPS to the same perl CGI script. This time i did see the active scan send in a reflected XSS injection.

It seems the Active Scan looks at the nature of the requests (http versus https) and also other things before deciding to use various injections. Could it be that the XSS Reflected plugin only kicks in if the requests are HTTPS only? This is speculation from my end but asking if that might be the case, maybe?

Thanks,
Usman

Usman Waheed

unread,
Aug 7, 2013, 10:44:22 AM8/7/13
to zaprox...@googlegroups.com
Ok, finally got the XSS Reflected to work :) in ZAP
The problem has nothing to do with http or https etc, my initial assumption was incorrect and wrong.

Earlier in my perl cgi i was simply printing the output without any html tags. This was throwing ZAP off ( i think ) during the active scan in order to determine if the injection inputs are reflected back.
The correction i made is to have html tags printed out and then everything works as expected.

Noted below is the final perl script:

#!/usr/bin/perl

use CGI;

my $query_params = CGI->new;
my $tarea = $query_params->param('tarea');


print "Content-type: text/html\n\n";

print "<html>\n";
print "<head><title>Testing</title></head>\n";
print "<body>\n";
print "<h2>\n";
print "Tarea: $tarea\n";
print "</body>\n";
print "</html>\n";

Simon Bennetts

unread,
Aug 7, 2013, 10:56:28 AM8/7/13
to zaprox...@googlegroups.com
Oh yes - that rule looks for some sort of valid html :)
I _think_ thats a reasonable assumption, unless anyone else disagrees?

Thanks for letting us know!

Simon

Cash Williams

unread,
Dec 19, 2013, 5:46:34 PM12/19/13
to zaprox...@googlegroups.com
Digging up old thread as I try to cram everything about this project into my head.

I think requiring valid html should not be required.

If a developer has a response intended to be an ajax response or something like it, then no HTML would be in the request. This is important especially if that response was reflecting something. 

For instance, Drupal has a feature called clean urls, and has a callback publicly accessible (http://cashwilliams.com/admin/config/search/clean-urls/check) to check if the feature is enabled.

Mukesh Sharma

unread,
Feb 26, 2014, 7:56:18 AM2/26/14
to zaprox...@googlegroups.com
Has any one tried to capture cross site script(persistent). I have installed the plugin but its not capturing . Any help is appreciated

Simon Bennetts

unread,
Feb 26, 2014, 9:17:02 AM2/26/14
to zaprox...@googlegroups.com
Persistent XSS's are a bit harder to detect as you might need to perform actions in a sequence to persist the attack.
The ZAP scanner injects a unique 'safe' value in all of the fields it knows about, and then spiders to see the locations where they end up.
It then tries to inject attacks and checks the resulting locations.

This works well in the relatively simple cases I've tested.
Have you definitely explored the page from which the attack can take place?
Is your known vulnerability a relatively straightforward one, ie inject in one page and detect in another?
Can you share any more details about it?

Many thanks,

Simon

Simon Bennetts

unread,
Feb 26, 2014, 9:23:57 AM2/26/14
to zaprox...@googlegroups.com
Currently ZAP can only detect reflected (and stored) XSS vulnerabilities, ie not DOM XSS vulnerabilities.
This is because you need a browser (or equivalent) to render the AJAX response in order to find out that its vulnerable.
However we are working on that right now :).
At AppSec USA I demo'ed finding a DOM XSS in a PostMessage: https://www.youtube.com/watch?v=pYFtLA2yTR8 (near the end)
Right now you can only do this via manual fuzzing, and via the Plug-n-Hack add-on in source control (its not been officially released yet).
In the future we plan to support automated 'client side' scanning,, but we're not there yet.

Cheers,

Simon

Mukesh Sharma

unread,
Feb 27, 2014, 4:22:17 AM2/27/14
to zaprox...@googlegroups.com
Thanks Simon for replying back.
In my case I have explored the page , I select the option to edit some field on the page, I injected some script and saved the page, I revisit the page, scripts gets executed. All these requests are proxied through ZAP. Now when I run Active scan, ZAP is not capturing the cross site script persistent.

Thanks
Mukesh


--
You received this message because you are subscribed to a topic in the Google Groups "OWASP ZAP User Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/zaproxy-users/7LGp8lZRKZc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to zaproxy-user...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--
Thanks & Regards
Mukesh

Simon Bennetts

unread,
Feb 28, 2014, 6:43:57 AM2/28/14
to zaprox...@googlegroups.com
I've just started a new thread for this problem so please see my suggestions here: https://groups.google.com/d/msg/zaproxy-users/apr9GnZLQM0/GjvPUUmIfAgJ

Cheers,

Simon
Reply all
Reply to author
Forward
0 new messages