The following beta status passive scan rules are included in this add-on:
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.).
Latest code: BigRedirectsScanRule.java
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.
Latest code: UserControlledCookieScanRule.java
Passively scans responses for signatures that are indicative that Directory Browsing is possible.
Latest code: DirectoryBrowsingScanRule.java
Passively scans 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.
Note: This scan rule will only analyze JavaScript responses on LOW Threshold.
Latest code: HashDisclosureScanRule.java
Passively scans for HTTP header responses that may indicate that the server is vulnerable to the critical HeartBleed OpenSSL vulnerability.
Latest code: HeartBleedScanRule.java
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.
Latest code: ServerHeaderInfoLeakScanRule.java
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.
Latest code: InsecureFormLoadScanRule.java
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.
Latest code: InsecureFormPostScanRule.java
This raises an informational alert if a site appears to be a modern web application.
It does not indicate any potential vulnerabilities but it could indicate that the ajax spider might be more effective at exploring this site compared to the traditional spider.
Latest code: ModernAppDetectionScanRule.java
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.
Latest code: UserControlledOpenRedirectScanRule.java
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 (images and CSS are ignored).
At MEDIUM and HIGH threshold it attempts to use three characters of context on each side of potential matches to exclude matches within deicmal like content. At LOW threshold, alerts will be raised for such matches.
Note: In the case of suspected credit card values, the potential credit card numbers are looked up against a Bank Identification Number List (BINList). If a match is found the alert is raised at High confidence and additional details are added to the ‘Other Information’ field in the alert, otherwise the alerts will have Medium confidence. See: binlist-data for more information.
Latest code: PiiScanRule.java
This scan rule detects content that has been served from a shared cache.
Latest code: RetrievedFromCacheScanRule.java
This checks to see if any links use a target attribute using “opener” keyword in the “rel” attribute, as this may 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.
Latest code: LinkTargetScanRule.java
Searches response content for HTML forms which fail to specify an action element. Version 3 of the Java Servlet spec calls for aggregation of query string and post data elements which may result in unintended handling of user controlled data. This may impact other frameworks and technologies as well. Note: This scan rule will only analyze responses on LOW Threshold, and in Context URLs for which the Tech JSP/Servlet is applicable.
Latest code: ServletParameterPollutionScanRule.java
This rule 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:
Redirects to HTTPS URLs on the same domain will only be reported at Low threshold.
Latest code: StrictTransportSecurityScanRule.java
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.
Latest code: UserControlledCharsetScanRule.java
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.
Latest code: UserControlledHTMLAttributesScanRule.java
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.
Latest code: UserControlledJavascriptEventScanRule.java
This checks response headers for the presence of X-Backend-Server details.
Latest code: XBackendServerInformationLeak.java
This checks response headers for the presence of X-ChromeLogger-Data or X-ChromePhp-Data details.
Latest code: XChromeLoggerDataInfoLeakScanRule.java