HelpAddonsPscanrulesAlphaPscanalpha

Passive Scan Rules - Alpha

The following alpha quality passive scan rules are included in this add-on:

ASP.NET ViewState Disclosure

An ASP.NET ViewState was disclosed by the application/web server

ASP.NET ViewState Integrity

The application does not use a Message Authentication Code (MAC) to protect the integrity of the ASP.NET ViewState, which can be tampered with by a malicious client

Base64 Disclosure

Base64 encoded data was disclosed by the application/web server

Missing Content Security Policy Header

This checks response headers for the presence of a Content Security Policy header.

Cookie poisoning

This check looks at user-supplied input in query string parameters and POST data to identify where cookie parameters might be controlled. This is called a cookie poisoning attack, and becomes exploitable when an attacker can manipulate the cookie in various ways. In some cases this will not be exploitable, however, allowing URL parameters to set cookie values is generally considered a bug.

Cross Domain Misconfiguration

Passively scan responses for Cross Domain MisConfigurations, which relax the Same Origin Policy in the web browser, for instance.
The current implementation looks at excessively permissive CORS headers.

Directory Browsing

Passively scan responses for signatures that are indicative that Directory Browsing is possible.

Example File Passive Scanner

This implements an example passive scan rule that loads strings from a file that the user can edit.
For
more details see: http://zaproxy.blogspot.co.uk/2014/04/hacking-zap-3-passive-scan-rules.html

Example Simple Passive Scanner

This implements a very simple example passive scan rule.
For more details see: http://zaproxy.blogspot.co.uk/2014/04/hacking-zap-3-passive-scan-rules.html

Hash Disclosure

Passively scan for password hashes disclosed by the web server.
Various formats are including, including
some formats such as MD4, MD5, and SHA*, which are sometimes used for purposes other than to contain
password hashes.

HeartBleed

Passively scans for HTTP header responses that may indicate that the server is vulnerable to the critical
HeartBleed OpenSSL vulnerability.

HTTP to HTTPS insecure transition in form post

This check looks for insecure HTTP pages that host HTTPS forms. The issue is that an insecure HTTP page
can easily be hijacked through MITM and the secure HTTPS form can be replaced or spoofed.

HTTPS to HTTP insecure transition in form post

This check identifies secure HTTPS pages that host insecure HTTP forms. The issue is that a secure page
is transitioning to an insecure page when data is uploaded through a form. The user may think they're
submitting data to a secure page when in fact they are not.

Insecure Component

Passively scans the server response headers and body generator content for product versions, which are
then cross-referenced against a list of product versions known to be vulnerable to various CVEs.
A list
of ranked CVEs and CVSS severity scores is output for each product noted to be vulnerable.
Currently,
the following server side products are supported:
Apache Tomcat application server (limited functionality
due to limited information leakage by Tomcat)
Apache web server
mod_auth_radius Apache module
mod_fcgid
Apache module
mod_imap Apache module
mod_jk Apache module
mod_perl Apache module
mod_python Apache module
mod_ssl
Apache module
OpenSSL Apache module
Perl Apache module
Python Apache module
IBM HTTP Server
JBoss application
server
Jetty web server / application server
LiteSpeed web server
Lighttpd web server
Microsoft IIS web server
Netscape
Enterprise web server
Nginx web server
OpenCMS
Oracle Application Server
Oracle Web Cache
PHP
Phusion_Passenger
Squid
proxy server
Sun One web server
Sun Java System Web Server
TornadoServer web server
WordPress

Image Location Scanner

Passively scans for GPS location exposure in images during normal security assessments of websites. Image
Location Scanner assists in situations where end users may post profile images and possibly give away
their home location, e.g. a dating site or children's chatroom. A whitepaper on this can be found at
http://veggiespam.com/ils/

Note: In order for this plug-in to operate, ZAP must be configured to receive and process images. To
do this, go to the ZAP Options panel (Tools → Options), choose Display, and enable the checkbox
for "Process images in HTTP requests/responses". In addition, ZAP images cannot be filtered out via the
settings "Global Exclude URL" or the Session Properties for "Exclude from Proxy".

Open redirect

Open redirects are one of the OWASP 2010 Top Ten vulnerabilities. This check looks at user-supplied input
in query string parameters and POST data to identify where open redirects might be possible. Open redirects
occur when an application allows user-supplied input (e.g. http://nottrusted.com) to control an offsite
redirect. This is generally a pretty accurate way to find where 301 or 302 redirects could be exploited
by spammers or phishing attacks

Server Header Version Information Leak

This checks response headers for the presence of a server header that contains version details.

Source Code Disclosure

Application Source Code was disclosed by the web server

Missing Strict Transport Security Header

This checks HTTPS response headers for the presence of a HTTP Strict Transport Security header.

Timestamp Disclosure

A timestamp was disclosed by the application/web server

User controllable HTML element attribute (potential XSS)

This check looks at user-supplied input in query string parameters and POST data to identify where certain
HTML attribute values might be controlled. This provides hot-spot detection for XSS (cross-site scripting)
that will require further review by a security analyst to determine exploitability.

User controllable charset

This check looks at user-supplied input in query string parameters and POST data to identify where Content-Type
or meta tag charset declarations might be user-controlled. Such charset declarations should always be
declared by the application. If an attacker can control the response charset, they could manipulate the
HTML to perform XSS or other attacks.

User controllable javascript event (XSS)

This check looks at user-supplied input in query string parameters and POST data to identify where certain
HTML attribute values might be controlled. This provides hot-spot detection for XSS (cross-site scripting)
that will require further review by a security analyst to determine exploitability.

User controllable javascript property (XSS)

This check looks at user-supplied input in query string parameters and POST data to identify where URL's
in certain javascript properties (e.g. createElement src) might becontrolled. This provides hot-spot
detection for XSS (cross-site scripting) that will require further review by a security analyst to determine
exploitability.

X-Powered-By Header Information Leak

This checks response headers for the presence of X-Powered-By details.

X-Backend-Server Header Information Leak

This checks response headers for the presence of X-Backend-Server details.

Big Redirect

This check predicts the size of various redirect type responses and generates an alert if the response
is greater than the predicted size. A large redirect response may indicate that although a redirect has
taken place the page actually contained content (which may reveal sensitive information, PII, etc).