-
-
Notifications
You must be signed in to change notification settings - Fork 720
HelpAddonsPscanrulesAlphaPscanalpha
The following alpha quality passive scan rules are included in this add-on:
An ASP.NET ViewState was disclosed by the application/web server
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 encoded data was disclosed by the application/web server
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.
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.
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.
Passively scan responses for signatures that are indicative that Directory Browsing is possible.
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
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
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.
Passively scans for HTTP header responses that may indicate that the server is vulnerable to the critical HeartBleed OpenSSL vulnerability.
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.
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.
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
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 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
This checks response headers for the presence of a server header that contains version details.
Application Source Code was disclosed by the web server
This scanner checks HTTPS response headers for the presence of a HTTP Strict Transport Security header (alerts if it is not found). Also checks if the HTTP Strict Transport Security (HSTS) header contains a max-age directive with value 0, which instructs clients to reset the entire HSTS Policy associated with the HSTS Host.
A timestamp was disclosed by the application/web server
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.
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.
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.
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.
This checks response headers for the presence of X-Powered-By details.
This checks response headers for the presence of X-Backend-Server details.
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).
This checks response headers for the presence of X-ChromeLogger-Data or X-ChromePhp-Data details.