org.sonar.zaproxy.rules.xml Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of sonar-zap-plugin Show documentation
Show all versions of sonar-zap-plugin Show documentation
Integrates ZAP reports into SonarQube
<!-- TODO this file should be automatically generated with the ZAProxy report -->
<!-- A rule model -->
<!--<rule>
<key></key>
<name></name>-->
<!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<!--<description>
<![CDATA[<h3>Solution :</h3>
<p></p>
<h3>References:</h3>
<ul>
<li><a href=""></a></li>
</ul>]]>
</description>
<severity></severity>
<status>READY</status>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
-->
<!--
For the moment, this file contains only rules of the ZAP core.
If you want to add a rule, you can, following the model above.
-->
<rules>
<rule>
<key>0</key>
<name>Directory Browsing</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Disable directory browsing. If this is required, make sure the listed files does not induce risks.</p>
<h3>References:</h3>
<ul>
<li><a href="http://httpd.apache.org/docs/mod/core.html#options">Directive Options</a></li>
<li><a href="http://alamo.satlug.org/pipermail/satlug/2002-February/000053.html">Apache Dir/Browsing Question</a></li>
</ul>]]>
</description>
<severity>MAJOR</severity>
<status>READY</status>
<tag>cweid-548</tag>
<tag>wascid-48</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>2</key>
<name>Private IP Disclosure</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Remove the private IP address from the HTTP response body. For comments, use JSP/ASP comment instead of HTML/JavaScript comment which can be seen by
client browsers.</p>
<h3>References:</h3>
<ul>
<li><a href="https://tools.ietf.org/html/rfc1918">Address Allocation for Private Internets</a></li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>cweid-200</tag>
<tag>wascid-13</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>3</key>
<name>Session ID in URL Rewrite</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>For secure content, put session ID in a cookie. To be even more secure consider using a combination of cookie and URL rewrite.</p>
<h3>References:</h3>
<ul>
<li><a href="http://seclists.org/lists/webappsec/2002/Oct-Dec/0111.html">Hijacking URL Encoded Session IDs using Referer Logs</a></li>
</ul>]]>
</description>
<severity>MAJOR</severity>
<status>READY</status>
<tag>cweid-200</tag>
<tag>wascid-13</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>6</key>
<name>Path Traversal</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to
specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on
looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or
determining which inputs are so malformed that they should be rejected outright.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or
extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid
because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
For filenames, use stringent whitelists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses,
and exclude directory separators such as "/". Use a whitelist of allowable file extensions.
Warning: if you attempt to cleanse your data, then do so that the end result is not in the form that can be dangerous. A sanitizing mechanism can remove characters
such as '.' and ';' which may be required for some exploits. An attacker can try to fool the sanitizing mechanism into "cleaning" data into a dangerous form.
Suppose the attacker injects a '.' inside a filename (e.g. "sensi.tiveFile") and the sanitizing mechanism removes the character resulting in the valid filename,
"sensitiveFile". If the input data are now assumed to be safe, then the file may be compromised.
Inputs should be decoded and canonicalized to the application's current internal representation before being validated. Make sure that your application does not
decode the same input twice. Such errors could be used to bypass whitelist schemes by introducing dangerous inputs after they have been checked.
Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".."
sequences and symbolic links.
Run your code using the lowest privileges that are required to accomplish the necessary tasks. If possible, create isolated accounts with limited privileges that
are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For
example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the
actual filenames or URLs, and reject all other inputs.
Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict
which files can be accessed in a particular directory or which commands can be executed by your software.
OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in
the Java SecurityManager allows you to specify restrictions on file operations.
This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
</p>
<h3>References:</h3>
<ul>
<li><a href="http://projects.webappsec.org/Path-Traversal">Path Traversal</a></li>
<li><a href="http://cwe.mitre.org/data/definitions/22.html">CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')</a></li>
</ul>]]>
</description>
<severity>CRITICAL</severity>
<status>READY</status>
<tag>cweid-22</tag>
<tag>wascid-33</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>7</key>
<name>Remote File Inclusion</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Phase: Architecture and Design</p>
<p>
When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs)
to the actual filenames or URLs, and reject all other inputs.
For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap provide this capability.
</p>
Phases: Architecture and Design; Operation
<p>
Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively
restrict which files can be accessed in a particular directory or which commands can be executed by your software.
OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example,
java.io.FilePermission in the Java SecurityManager allows you to specify restrictions on file operations.
This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
Be careful to avoid CWE-243 and other weaknesses related to jails.
For PHP, the interpreter offers restrictions such as open basedir or safe mode which can make it more difficult for an attacker to escape out of the
application. Also consider Suhosin, a hardened PHP extension, which includes various options that disable some of the more dangerous PHP features.
</p>
Phase: Implementation
<p>
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to
specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on
looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or
determining which inputs are so malformed that they should be rejected outright.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values,
missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be
syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
For filenames, use stringent whitelists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid
weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a whitelist of allowable file extensions, which will help to
avoid CWE-434.
</p>
Phases: Architecture and Design; Operation
<p>
Store library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web
server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling
program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and
it can exit immediately.
This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include
files. It will also reduce your attack surface.
</p>
Phases: Architecture and Design; Implementation
<p>
Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network,
environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, databases, and any external systems that provide
data to the application. Remember that such inputs may be obtained indirectly through API calls.
Many file inclusion problems occur because the programmer assumed that certain inputs could not be modified, especially for cookies and URL components.
</p>
<h3>References:</h3>
<ul>
<li><a href="http://projects.webappsec.org/Remote-File-Inclusion">Remote File Inclusion</a></li>
<li><a href="http://cwe.mitre.org/data/definitions/98.html">CWE-98: Improper Control of Filename for Include/Require Statement in PHP Program
('PHP Remote File Inclusion')</a></li>
</ul>]]>
</description>
<severity>CRITICAL</severity>
<status>READY</status>
<tag>cweid-98</tag>
<tag>wascid-5</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10010</key>
<name>Cookie set without HttpOnly flag</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Ensure that the HttpOnly flag is set for all cookies.</p>
<h3>References:</h3>
<ul>
<li><a href="https://www.owasp.org/index.php/HttpOnly">HttpOnly</a></li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>wascid-13</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10011</key>
<name>Cookie set without secure flag</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Whenever a cookie contains sensitive information or is a session token, then it should always be passed using an encrypted tunnel.
Ensure that the secure flag is set for cookies containing such sensitive information.</p>
<h3>References:</h3>
<ul>
<li><a href="http://www.owasp.org/index.php/Testing_for_cookies_attributes_(OWASP-SM-002)">Testing for cookies attributes (OTG-SESS-002)</a></li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>wascid-13</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10012</key>
<name>Password Autocomplete in Browser</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Turn off AUTOCOMPLETE attribute in form or individual input elements containing password by using AUTOCOMPLETE='OFF'</p>
<h3>References:</h3>
<ul>
<li><a href="http://msdn.microsoft.com/library/default.asp?url=/workshop/author/forms/autocomplete_ovr.asp">Autocomplete</a></li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>cweid-525</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10015</key>
<name>Incomplete or No Cache-control and Pragma HTTP Header Set</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Whenever possible ensure the cache-control HTTP header is set with no-cache, no-store, must-revalidate, private; and that the pragma HTTP header is
set with no-cache.</p>
<h3>References:</h3>
<ul>
<li><a href="https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Web_Content_Caching">Web Content Caching</a></li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>cweid-525</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10016</key>
<name>Web Browser XSS Protection Not Enabled</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Ensure that the web browser's XSS filter is enabled, by setting the X-XSS-Protection HTTP response header to '1'.</p>
<h3>References:</h3>
<ul>
<li><a href="https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet">XSS (Cross Site Scripting) Prevention Cheat Sheet</a></li>
<li><a href="https://blog.veracode.com/2014/03/guidelines-for-setting-security-headers">Guidelines for Setting Security Headers</a></li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>cweid-933</tag>
<tag>wascid-14</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10017</key>
<name>Cross-Domain JavaScript Source File Inclusion</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Ensure JavaScript source files are loaded from only trusted sources, and the sources can't be controlled by end users of the application</p>
<h3>References:</h3>
<ul>
<li>No reference.</li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10019</key>
<name>Content-Type Header Missing</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Ensure each page is setting the specific and appropriate content-type value for the content being delivered</p>
<h3>References:</h3>
<ul>
<li><a href="http://msdn.microsoft.com/en-us/library/ie/gg622941%28v=vs.85%29.aspx">Reducing MIME type security risks</a></li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10020</key>
<name>X-Frame-Options Header Not Set</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Most modern Web browsers support the X-Frame-Options HTTP header. Ensure it's set on all web pages returned by your site
(if you expect the page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then you'll want to use SAMEORIGIN, otherwise
if you never expect the page to be framed, you should use DENY. ALLOW-FROM allows specific websites to frame the web page in supported web browsers).</p>
<h3>References:</h3>
<ul>
<li><a href="http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx">Combating ClickJacking With X-Frame-Options</a></li>
</ul>]]>
</description>
<severity>MAJOR</severity>
<status>READY</status>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10021</key>
<name>X-Content-Type-Options Header Missing</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Ensure that the application/web server sets the Content-Type header appropriately, and that it sets the X-Content-Type-Options header to 'nosniff' for
all web pages.</br>If possible, ensure that the end user uses a standards-compliant and modern web browser that does not perform MIME-sniffing at all, or that
can be directed by the web application/web server to not perform MIME-sniffing.</p>
<h3>References:</h3>
<ul>
<li><a href="http://msdn.microsoft.com/en-us/library/ie/gg622941%28v=vs.85%29.aspx">Reducing MIME type security risks</a></li>
<li><a href="https://www.owasp.org/index.php/List_of_useful_HTTP_headers">List of useful HTTP headers</a></li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>wascid-15</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10023</key>
<name>Information Disclosure - Debug Error Messages</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Disable or limit detailed error handling. In particular, do not display debug information to end users, stack traces, or path information.
Ensure that the entire software development team shares a common approach to exception handling.
</p>
<h3>References:</h3>
<ul>
<li><a href="https://www.owasp.org/index.php/Top_10_2007-Information_Leakage_and_Improper_Error_Handling">List of useful HTTP headers</a></li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>wascid-13</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10024</key>
<name>Information Disclosure - Sensitive Informations in URL</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>When sensitive information is sent, use of the POST method is recommended (e.g. registration form).
</p>
<h3>References:</h3>
<ul>
<li><a href="https://www.owasp.org/index.php/Information_exposure_through_query_strings_in_url">List of useful HTTP headers</a></li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>wascid-13</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10025</key>
<name>Information Disclosure - Sensitive Information in HTTP Referrer Header</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>When sensitive information is sent, use of the POST method is recommended (e.g. registration form).
</p>
<h3>References:</h3>
<ul>
<li><a href="https://www.owasp.org/index.php/Information_exposure_through_query_strings_in_url">List of useful HTTP headers</a></li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>wascid-13</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10026</key>
<name>HTTP Parameter Override</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>In order to prevent these kinds of vulnerabilities, an extensive and proper input validation should be performed.
There are safe methods to conform to with each web technology/language. Moreover, awareness about the fact that clients/users can provide more than one parameter should be raised.
</p>
<h3>References:</h3>
<ul>
<li><a href="https://www.owasp.org/index.php/Testing_for_HTTP_Parameter_pollution_(OTG-INPVAL-004)">Testing for HPP</a></li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10027</key>
<name>Information Disclosure - Suspicious Comments</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Remove comments that suggest the presence of bugs, incomplete functionality, or weaknesses, before deploying the application.
</p>
<h3>References:</h3>
<ul>
<li><a href="https://cwe.mitre.org/data/definitions/546.html">CWE-546</a></li>
</ul>]]>
</description>
<severity>INFO</severity>
<status>READY</status>
<tag>cweid-546</tag>
<tag>wascid-13</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10032</key>
<name>Viewstate Scanner</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Do not store the ViewState within the HTML page (implement a handler). Protect the ViewState contents (configuration).
</p>
<h3>References:</h3>
<ul>
<li><a href="https://www.owasp.org/images/2/22/20110412-aspnet_viewstate_security-alexandre.pdf">ASP Security ViewState flaw</a></li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>wascid-13</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10040</key>
<name>Secure Pages Include Mixed Content</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>A page that is available over TLS must be comprised completely of content which is transmitted over TLS.
The page must not contain any content that is transmitted over unencrypted HTTP.
This includes content from unrelated third party sites.</p>
<h3>References:</h3>
<ul>
<li><a href="https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet">Transport Layer Protection Cheat Sheet</a></li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10094</key>
<name>Base64 Disclosure</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Manually confirm that the Base64 data does not leak sensitive information, and that the data cannot be aggregated/used to exploit other vulnerabilities.</p>
<h3>References:</h3>
<ul>
<li><a href="https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure">Top 10 2013-A6-Sensitive Data Exposure</a></li>
<li><a href="http://projects.webappsec.org/w/page/13246936/Information%20Leakage">WASC - Information Leakage</a></li>
</ul>]]>
</description>
<severity>INFO</severity>
<status>READY</status>
<tag>wascid-13</tag>
<tag>cweid-200</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10105</key>
<name>Weak Authentication Method</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Disable and block all authentication methods so that only forms-based authentication and SSL client certificates are allowed.
Whitelist or proxy all inlined content in order to block malicious authentication requests.
</p>
<h3>References:</h3>
<ul>
<li><a href="https://www.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_Weak_Authentication_Methods">Weak Authentication Methods</a></li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>10202</key>
<name>Absence of Anti-CSRF Tokens</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Check standard headers to verify the request is same origin and Check CSRF token.
</p>
<h3>References:</h3>
<ul>
<li><a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet">CSRF Prevention Cheat Sheet</a></li>
</ul>]]>
</description>
<severity>CRITICAL</severity>
<status>READY</status>
<tag>wascid-9</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>20019</key>
<name>External Redirect</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to
specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on
looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or
determining which inputs are so malformed that they should be rejected outright.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values,
missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be
syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
Use a whitelist of approved URLs or domains to be used for redirection.
Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving your site. Implement a long timeout before the
redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems when generating the disclaimer page.
When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs)
to the actual filenames or URLs, and reject all other inputs.
For example, ID 1 could map to "/login.asp" and ID 2 could map to "http://www.example.com/". Features such as the ESAPI AccessReferenceMap provide this
capability.
Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network,
environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, databases, and any external systems that provide
data to the application. Remember that such inputs may be obtained indirectly through API calls.
Many open redirect problems occur because the programmer assumed that certain inputs could not be modified, such as cookies and hidden form fields.</p>
<h3>References:</h3>
<ul>
<li><a href="http://projects.webappsec.org/URL-Redirector-Abuse">URL Redirector Abuse</a></li>
<li><a href="http://cwe.mitre.org/data/definitions/601.html">CWE-601: URL Redirection to Untrusted Site ('Open Redirect')</a></li>
</ul>]]>
</description>
<severity>MAJOR</severity>
<status>READY</status>
<tag>wascid-38</tag>
<tag>cweid-601</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>30002</key>
<name>Check for proper format string handling in back end c code</name>
<description>
<![CDATA[<h3>Solution :</h3>
<p>Many of the back end interfaces use a secondary programming language, often compiled,
to interface to a variety of system functions. C and C++ are two of the more popular
"traditional" languages that are used. The Format String exploit occurs when the submitted
data of an input string is evaluated as a command by the application. In this way,
the attacker could execute code, read the stack, or cause a segmentation fault in the
running application, causing new behaviors that could compromise the security or the
stability of the system.</p>
<h3>References:</h3>
<ul>
<li>No Reference.</li>
</ul>]]>
</description>
<severity>MAJOR</severity>
<status>READY</status>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>40003</key>
<name>CRLF Injection</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Type check the submitted parameter carefully. Do not allow CRLF to be injected by filtering CRLF.</p>
<h3>References:</h3>
<ul>
<li><a href="http://www.securityfocus.com/bid/9804">Multiple Vendor HTTP Response Splitting Vulnerability</a></li>
<li><a href="https://www.owasp.org/index.php/HTTP_Response_Splitting">HTTP Response Splitting</a></li>
</ul>]]>
</description>
<severity>MAJOR</severity>
<status>READY</status>
<tag>wascid-25</tag>
<tag>cweid-113</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>40008</key>
<name>Parameter Tampering</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Identify the cause of the error and fix it. Do not trust client side input and enforce a tight check in the server side. Besides, catch the exception
properly. Use a generic 500 error page for internal server error.</p>
<h3>References:</h3>
<ul>
<li>No reference.</li>
</ul>]]>
</description>
<severity>MAJOR</severity>
<status>READY</status>
<tag>wascid-20</tag>
<tag>cweid-472</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>40009</key>
<name>Server Side Include</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Do not trust client side input and enforce a tight check in the server side. Disable server side includes.</br>
Refer to manual to disable Sever Side Include.</br>
Use least privilege to run your web server or application server.</br>
For Apache, disable the following:
<ul>
<li>Options Indexes FollowSymLinks Includes</li>
<li>AddType application/x-httpd-cgi .cgi</li>
<li>AddType text/x-server-parsed-html .html</li>
</ul>
</p>
<h3>References:</h3>
<ul>
<li><a href="http://www.carleton.ca/~dmcfet/html/ssi.html">Server Side Includes</a></li>
</ul>]]>
</description>
<severity>CRITICAL</severity>
<status>READY</status>
<tag>wascid-31</tag>
<tag>cweid-97</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>40012</key>
<name>Cross Site Scripting (Reflected)</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
Phase: Architecture and Design
<p>
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
</p>
Phases: Implementation; Architecture and Design
<p>
Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.
Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed.
</p>
Phase: Architecture and Design
<p>
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.
</p>
Phase: Implementation
<p>
For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page. This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping.
To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.
</p>
<h3>References:</h3>
<ul>
<li><a href="http://projects.webappsec.org/Cross-Site-Scripting">Cross Site Scripting</a></li>
<li><a href="http://cwe.mitre.org/data/definitions/79.html">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a></li>
</ul>]]>
</description>
<severity>CRITICAL</severity>
<status>READY</status>
<tag>wascid-8</tag>
<tag>cweid-79</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>40014</key>
<name>Cross Site Scripting (Persistent)</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
Phase: Architecture and Design
<p>
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
</p>
Phases: Implementation; Architecture and Design
<p>
Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.
Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed.
</p>
Phase: Architecture and Design
<p>
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.
</p>
Phase: Implementation
<p>
For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page. This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping.
To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.
</p>
<h3>References:</h3>
<ul>
<li><a href="http://projects.webappsec.org/Cross-Site-Scripting">Cross Site Scripting</a></li>
<li><a href="http://cwe.mitre.org/data/definitions/79.html">CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')</a></li>
</ul>]]>
</description>
<severity>CRITICAL</severity>
<status>READY</status>
<tag>wascid-8</tag>
<tag>cweid-79</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>40016</key>
<name>Cross Site Scripting (Persistent) - Prime</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>N/A</p>
<h3>References:</h3>
<ul>
<li>No reference.</li>
</ul>]]>
</description>
<severity>INFO</severity>
<status>READY</status>
<tag>wascid-8</tag>
<tag>cweid-79</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>40017</key>
<name>Cross Site Scripting (Persistent) - Spider</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>N/A</p>
<h3>References:</h3>
<ul>
<li>No reference.</li>
</ul>]]>
</description>
<severity>INFO</severity>
<status>READY</status>
<tag>wascid-8</tag>
<tag>cweid-79</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>40018</key>
<name>SQL Injection</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Do not trust client side input, even if there is client side validation in place. In general, type check all data on the server side.</br>
If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'</br>
If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.</br>
If database Stored Procedures can be used, use them.</br>
Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!</br>
Do not create dynamic SQL queries using simple string concatenation.</br>
Escape all data received from the client.</br>
Apply a 'whitelist' of allowed characters, or a 'blacklist' of disallowed characters in user input.</br>
Apply the privilege of least privilege by using the least privileged database user possible.</br>
In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.</br>
Grant the minimum database access that is necessary for the application.
</p>
<h3>References:</h3>
<ul>
<li><a href="https://www.owasp.org/index.php/Top_10_2010-A1">Top 10 2010-A1-Injection</a></li>
<li><a href="https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet">SQL Injection Prevention Cheat Sheet</a></li>
</ul>]]>
</description>
<severity>CRITICAL</severity>
<status>READY</status>
<tag>wascid-19</tag>
<tag>cweid-89</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>40029</key>
<name>Trace.axd Information Leak</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Consider whether or not Trace Viewer is actually required in production, if it isn't then disable it. If it is then ensure access to it requires authentication and authorization.</p>
<h3>References:</h3>
<ul>
<li><a href="https://msdn.microsoft.com/en-us/library/bb386420.aspx">ASP.NET Tracing Overview</a></li>
<li><a href="https://msdn.microsoft.com/en-us/library/wwh16c6c.aspx">How to: View ASP.NET Trace Information with the Trace Viewer</a></li>
<li><a href="https://www.dotnetperls.com/trace">ASP.NET Trace Examples - Dot Net Perls</a></li>
</ul>]]>
</description>
<severity>MAJOR</severity>
<status>READY</status>
<tag>wascid-13</tag>
<tag>cweid-215</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>50001</key>
<name>Script Passive Scan Rules</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>
N/A
</p>
<h3>References:</h3>
<ul>
<li>No reference</li>
</ul>]]>
</description>
<severity>CRITICAL</severity>
<status>READY</status>
<tag>wascid-19</tag>
<tag>cweid-89</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>90001</key>
<name>Insecure JSF ViewState</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Protect the ViewState value.
</p>
<h3>References:</h3>
<ul>
<li>No reference</li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>90011</key>
<name>Charset Mismatch</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>The declaration in the HTTP Content-Type header doesn't match what is declared in a META Content-Type tag, or
the declaration in the HTTP Content-Type header doesn't match what is declared in a META Charset tag. Another possibility is that
the response doesn't contain a META Content-Type declaration, which may overlook older clients. Correct the declarations.
</p>
<h3>References:</h3>
<ul>
<li><a href="http://www.w3.org/TR/html401/charset.html#h-5.2.2">Charset</a></li>
<li><a href="http://www.w3.org/TR/html5/document-metadata.html#charset">Document Metadata Charset</a></li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>90019</key>
<name>Server Side Code Injection</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>Do not trust client side input, even if there is client side validation in place. </br>
In general, type check all data on the server side and escape all data received from the client.</br>
Avoid the use of eval() functions combined with user input data.
</p>
<h3>References:</h3>
<ul>
<li><a href="http://cwe.mitre.org/data/definitions/94.html">CWE-94: Improper Control of Generation of Code ('Code Injection')</a></li>
<li><a href="https://www.owasp.org/index.php/Direct_Dynamic_Code_Evaluation_('Eval_Injection')">Direct Dynamic Code Evaluation ('Eval Injection')</a></li>
</ul>]]>
</description>
<severity>CRITICAL</severity>
<status>READY</status>
<tag>cweid-94</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>90020</key>
<name>Remote OS Command Injection</name>
<description> <!-- Corresponding to "<solution>" and "<reference>" of the ZAP report -->
<![CDATA[<h3>Solution :</h3>
<p>If at all possible, use library calls rather than external processes to recreate the desired functionality.
Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict
which files can be accessed in a particular directory or which commands can be executed by your software.
OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in
the Java SecurityManager allows you to specify restrictions on file operations.
This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
For any data that will be used to generate a command to be executed, keep as much of that data out of external control as possible. For example, in web applications,
this may require storing the command locally in the session's state instead of sending it out to the client in a hidden form field.
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
For example, consider using the ESAPI Encoding control or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less
prone to error.
If you need to use dynamically-generated query strings or commands in spite of the risk, properly quote arguments and escape any special characters within those
arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict whitelist (such as everything that is not
alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be
careful of argument injection.
If the program to be executed allows arguments to be specified within an input file or from standard input, then consider using that mode to pass arguments instead
of the command line.
If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant
quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.
Some languages offer multiple functions that can be used to invoke commands. Where possible, identify any function that invokes a command shell using a single
string, and replace it with a function that requires individual arguments. These functions typically perform appropriate quoting and filtering of arguments. For
example, in C, the system() function accepts a string that contains the entire command to be executed, whereas execl(), execve(), and others require an array of
strings, one for each argument. In Windows, CreateProcess() only accepts one command at a time. In Perl, if system() is provided with an array of arguments, then
it will quote each of the arguments.
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to
specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for
malicious or malformed inputs (i.e., do not rely on a blacklist). However, blacklists can be useful for detecting potential attacks or determining which inputs are
so malformed that they should be rejected outright.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or
extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid
because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
When constructing OS command strings, use stringent whitelists that limit the character set based on the expected value of the parameter in the request. This will
indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping.
Note that proper output encoding, escaping, and quoting is the most effective solution for preventing OS command injection, although input validation may provide
some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent OS command injection, especially
if you are required to support free-form text fields that could contain arbitrary characters. For example, when invoking a mail program, you might need to allow the
subject field to contain otherwise-dangerous inputs like ";" and ">" characters, which would need to be escaped or otherwise handled. In this case, stripping the
character might reduce the risk of OS command injection, but it would produce incorrect behavior because the subject field would not be recorded as the user
intended. This might seem to be a minor inconvenience, but it could be more important when the program relies on well-structured subject lines in order to pass
messages to other components.
Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from
injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack
surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.</solution>
</p>
<h3>References:</h3>
<ul>
<li><a href="http://cwe.mitre.org/data/definitions/78.html">CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')</a></li>
<li><a href="https://www.owasp.org/index.php/Command_Injection">Command Injection</a></li>
</ul>]]>
</description>
<severity>CRITICAL</severity>
<status>READY</status>
<tag>wascid-31</tag>
<tag>cweid-78</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>90022</key>
<name>Application Error Disclosure</name>
<description>
<![CDATA[<h3>Solution :</h3>
<p>Review the source code of this page. Implement custom error pages. Consider implementing a mechanism to provide a unique error reference/identifier to
the client (browser) while logging the details on the server side and not exposing them to the user.</p>
<h3>References:</h3>
<ul>
<li>No Reference.</li>
</ul>]]>
</description>
<severity>MAJOR</severity>
<status>READY</status>
<tag>wascid-13</tag>
<tag>cweid-200</tag>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>90030</key>
<name>WSDL File Passive Scanner</name>
<description>
<![CDATA[<h3>Solution :</h3>
<p>
N/A
</p>
<h3>References:</h3>
<ul>
<li>No Reference.</li>
</ul>]]>
</description>
<severity>MINOR</severity>
<status>READY</status>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>90033</key>
<name>Loosely Scoped Cookie</name>
<description>
<![CDATA[<h3>Solution :</h3>
<p>Always scope cookies to a FQDN (Fully Qualified Domain Name).</p>
N/A
<h3>References:</h3>
<ul>
<li><a href="https://tools.ietf.org/html/rfc6265#section-4.1/></li>
<li><a href="https://www.owasp.org/index.php/Testing_for_cookies_attributes_(OTG-SESS-002)/></li>
<li><a href="http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies/></li>
</ul>]]>
</description>
<severity>INFO</severity>
<status>READY</status>
<tag>security</tag>
<tag>zaproxy</tag>
<tag>wascid-15</tag>
<tag>cweid-565</tag>
</rule>
<rule>
<key>100000</key>
<name>A Server Error response code was returned by the server</name>
<description>
<![CDATA[<h3>Solution :</h3>
<p>A response code of 400 was returned by the server.</p><p>This may indicate that the application is failing to handle unexpected input correctly.</p><p>Fix the handling of unexpected input.</p>
N/A
<h3>References:</h3>
<ul>
</ul>]]>
</description>
<severity>INFO</severity>
<status>READY</status>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
<rule>
<key>100001</key>
<name>Unexpected Content-Type was returned</name>
<description>
<![CDATA[<h3>Solution :</h3>
<p>A Content-Type that was returned is not one of the types expected to be returned by an API. Fix the Content-Type header.</p>
N/A
<h3>References:</h3>
<ul>
</ul>]]>
</description>
<severity>INFO</severity>
<status>READY</status>
<tag>security</tag>
<tag>zaproxy</tag>
</rule>
</rules>