Scanner improvements

[h0ng10]

Hi all

I'm currently playing with the OWASP ZAP scanner and have a view improvements that I would like to implement. However before I start

working on it, I think it is better to discuss them first (to be sure I didn't make any error in reasoning)

1. "Active" plugins that can be implemented as passive:

When I locked at the code of the existing plugins, noticed that the following plugins can be implemented as passive versions:

- Session ID in URL rewrite

- Secure page in browser cache

Those plugins don't make any active requests.

2. URL Redirector Abuse

The URL Redirector Abuse should include the following testscases:

- //www.owasp.org

- [name of target host].owasp.org

3. Scanner XML Output

Currently the a typical XML alertitem node from the scanner looks like this:

 <pluginid>10010</pluginid>

  <alert>Cookie set without HttpOnly flag</alert>

  <riskcode>1</riskcode>

  <reliability>2</reliability>

  <riskdesc>Low (Warning)</riskdesc>

  <desc>A cookie has been set without the HttpOnly flag, which means that the cookie can be accessed by JavaScript. If a malicious script can be run on this page then the cookie will be accessible and can be transmitted to another site. If this is a session cookie then session hijacking may be possible.

</desc>

  <uri>http://wwwxxxxxxx</uri>

  <param>PHPSESSID</param>

  <attack>66ntqn6bimv32ogja4g8o2nhb5; path=/</attack>

  <otherinfo/>

  <solution>Ensure that the HttpOnly flag is set for all cookies.

</solution>

  <reference>www.owasp.org/index.php/HttpOnly

</reference>

</alertitem>

There is a lot of redundancy in this document, as each finding contains the same description, references etc. 

This would make sense if the description is different for each alertitem which is not the case.

I would suggest following type of structure:

<plugin>

 <id></id>

 <description></description>

 <references></references>

 ....

 <alertitems>

    <item>

      <uri>http://xxxxxxx</uri>

      <parameter>evilparameter</parameter>

     ......

    </item>

</alertitems>

</plugin> 

I think the report should also contain additional information about the request (for example the request method, what part of the response triggered the alert) 

or even the Request/Responses itself.

3. Scanner configuration

Currently the configuration of the scanner is quite restricted, additionally it is not possible to configure the plugins at all, just en/disable them. If the scanner

is carefully configured, the scan time could be decreased.

Global Scanner configuration

- Target OS of the web application 

 If the tester knows the OS of the web server certain scan's can be avoided, for example path traversal attacks for ../etc/passwd if the host is a windows system

- Target framework (PHP/ASP/ASP.NET)

- Target database (MySQL, SQL, PostgreSQL)

- Parameters that should not be scanned by active scanner plugins (for example ASP.NET viewstate, or CSRF tokens)

In general I would like to move the entire scanner configuration (including the plugins) into a XML file and not only store them in the zap session. This would make it easier

to generate different scan policies and exchange them with others.

I think I can develop most of the stuff on my own, I wrote some paros plugins in the past. However I'm not good when it comes to GUI/Swing stuff, if anyone

can help me here, please let me know.

[psiinon]

Hi,

Quick reply as I have limited internet access right now.

1. Yes, these are old Paros tests and should be passive. I've been meaning to do this but not found time - feel free to change them :)
2. The reports could do with many enhancements. We did propose a Google Summer of Code project but no guarantee that will happen. Again, feel free to make some changes here!
3. This is part implemented - thats what the 'technology' tab on the Contexts' is for :) Also plan to allow you to configure the 'strength' and 'threshold' on a per plugin basis and create different profiles as per your suggestion. I'll give an update when I'm back.

Cheers,

Simon