Skip to content

HelpAddonsPscanrulesAlphaPscanalpha

Jump to bottom
thc202 edited this page Aug 15, 2018 · 17 revisions

Passive Scan Rules - Alpha

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

An example passive scan rule which loads data from a file

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

Base64 Disclosure

  • 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

Big Redirect Detected (Potential Sensitive Information Leak)

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).

Content Cacheability

This scanner analyzes the cache control and pragma headers in HTTP traffic and resports on the cacheability of the requests from a RFC7234 point of view.

Alerts generated:

  • Non-Storable Content
  • Storable but Non-Cacheable Content
  • Storable and Cacheable Content

Content Security Policy (CSP) Header Not Set

This checks HTML response headers for the presence of a Content Security Policy header. By default this rule checks for the presence of the "Content-Security-Policy" header, and at the Low threshold also checks for the "X-Content-Security-Policy" and "X-WebKit-CSP" headers.

If a "Content-Security-Policy-Report-Only" header is found on a response an INFO alert is raised. This may represent an enforcement effort that is actively being refined or developed, or one which is only partially implemented.

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.

Cookie Without SameSite Attribute

This reports any cookies that do not have the SameSite attribute or that do not have a recognised valid value for that attribute.

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 Passive Scanner: Denial of Service

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 OpenSSL Vulnerability (Indicative)

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

HTTP Server Response Header Scanner

This checks response headers for the presence of a server header that contains version details. At LOW Threshold will raise an alert based on presence of the header field whether or not a version string is detected.

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.

In Page Banner Information Leak

Analyzes response body content for the presence of web or application server banners (when the responses have error status codes). If the Threshold is Low then status 200 - Ok responses are analyzed as well. The presence of such banners may facilitate more targeted attacks against known vulnerabilities.

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

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.

PII Disclosure scanner

PII is information like credit card number, SSN etc. This check currently reports only numbers which match credit card numbers and pass Luhn checksum, which gives high confidence, that this is a credit card number.

Retrieved from Cache

This scanner detect content that has been served from a shared cache.

Reverse Tabnabbing

This checks to see if any links use a target attribute without using both of the "noopener" and "noreferrer" keywords in the "rel" attribute, as this will allow target pages to take over the page that opens them. By default this rule will ignore all links that are in the same context as the page. At the LOW threshold it will only ignore links that are on the same host. At HIGH threshold it will only report links that use the "_blank" target. You can specify a comma separated list of URL regex patterns using the rules.domains.trusted parameter via the Options 'Rule configuration' panel. Any link URL that matches one of these patterns will be considered to be in a trusted domain and will therefore not be reported.

Server Leaks Information via "X-Powered-By" HTTP Response Header Field(s)

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

Source Code Disclosure

Application Source Code was disclosed by the web server

Strict Transport Security Header Scanner

This scanner checks HTTPS responses for the presence of a HTTP Strict Transport Security (HSTS) header and tests for various implementation concerns, alerting if they're found. Alerts generated:

  • Strict-Transport-Security Header Not Set: If the response is HTTPS and the header is completely missing.
  • Strict-Transport-Security Disabled: If the response is HTTPS and the max-age value is set to zero, thus resetting the browser's HSTS information for the site.
  • Strict-Transport-Security Multiple Header Entries (Non-compliant with Spec): If the response is HTTPS and there is more than one HSTS header on the response.
  • Strict-Transport-Security Missing Max-Age (Non-compliant with Spec): If the response is HTTPS, a HSTS header is specified but the max-age value does not contain a number.
  • Strict-Transport-Security Defined via META (Non-compliant with Spec): If the response body includes a META tag which attempts to define HSTS.
  • Strict-Transport-Security Header on Plain HTTP Response: If the response is HTTP and the HSTS header is present.
  • Strict-Transport-Security Max-Age Malformed (Non-compliant with Spec): If the response is HTTPS and the HSTS header is present, but there are quotes preceding the max-age directive (quotes are allowed around the max-age value, but not around the directive itself).
  • Strict-Transport-Security Malformed Content (Non-compliant with Spec): If the response is HTTPS and a HSTS header is present, but there is some unexpected content (such as curly quotes). The expectation is that the content be printable ASCII.

Timestamp Disclosure

A timestamp was disclosed by the application/web server

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 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 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.

Username Hash Found

If any context contains defined users this scanner checks all responses for the presence of hashed values representing those usernames. Discovery of any such value may represent an Insecure Direct Object Reference (IDOR) vulnerability. Alerts are only raised as informational items as further manual testing is required in order to confirm and assess impact.

X-AspNet-Version Response Header Scanner

This checks response headers for the presence of X-AspNet-Version/X-AspNetMvc-Version details.

X-Backend-Server Header Information Leak

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

X-ChromeLogger-Data Header Information Leak

This checks response headers for the presence of X-ChromeLogger-Data or X-ChromePhp-Data details.

X-Debug-Token Information Leak

This checks response headers for the presence of X-Debug-Token and X-Debug-Token-Link details. Which indicates the use/exposure of Symfony's Profiler. Symfony's Profiler provides access to a significant amount of information of interest to malicious individuals and Security Testers.

Clone this wiki locally