scanners/zap/parser/__testFiles__/example.com.xml
<!--
SPDX-FileCopyrightText: the secureCodeBox authors
SPDX-License-Identifier: Apache-2.0
-->
<?xml version="1.0"?><OWASPZAPReport version="D-2020-10-13" generated="Thu, 22 Oct 2020 08:51:36">
<site name="http://example.com" host="example.com" port="80" ssl="false"><alerts><alertitem>
<pluginid>10036</pluginid>
<alert>Server Leaks Version Information via "Server" HTTP Response Header Field</alert>
<name>Server Leaks Version Information via "Server" HTTP Response Header Field</name>
<riskcode>1</riskcode>
<confidence>3</confidence>
<riskdesc>Low (High)</riskdesc>
<desc><p>The web/application server is leaking version information via the "Server" HTTP response header. Access to such information may facilitate attackers identifying other vulnerabilities your web/application server is subject to.</p></desc>
<instances>
<instance>
<uri>http://example.com/robots.txt</uri>
<method>GET</method>
<evidence>ECS (mic/9B13)</evidence>
</instance>
<instance>
<uri>http://example.com</uri>
<method>GET</method>
<evidence>ECS (mic/9A9C)</evidence>
</instance>
<instance>
<uri>http://example.com/sitemap.xml</uri>
<method>GET</method>
<evidence>ECS (dab/4AD5)</evidence>
</instance>
<instance>
<uri>http://example.com/</uri>
<method>GET</method>
<evidence>ECS (dab/DC46)</evidence>
</instance>
</instances>
<count>4</count>
<solution><p>Ensure that your web server, application server, load balancer, etc. is configured to suppress the "Server" header or provide generic details.</p></solution>
<reference><p>http://httpd.apache.org/docs/current/mod/core.html#servertokens</p><p>http://msdn.microsoft.com/en-us/library/ff648552.aspx#ht_urlscan_007</p><p>http://blogs.msdn.com/b/varunm/archive/2013/04/23/remove-unwanted-http-response-headers.aspx</p><p>http://www.troyhunt.com/2012/02/shhh-dont-let-your-response-headers.html</p></reference>
<cweid>200</cweid>
<wascid>13</wascid>
<sourceid>3</sourceid>
</alertitem>
<alertitem>
<pluginid>10050</pluginid>
<alert>Retrieved from Cache</alert>
<name>Retrieved from Cache</name>
<riskcode>0</riskcode>
<confidence>2</confidence>
<riskdesc>Informational (Medium)</riskdesc>
<desc><p>The content was retrieved from a shared cache. If the response data is sensitive, personal or user-specific, this may result in sensitive information being leaked. In some cases, this may even result in a user gaining complete control of the session of another user, depending on the configuration of the caching components in use in their environment. This is primarily an issue where caching servers such as "proxy" caches are configured on the local network. This configuration is typically found in corporate or educational environments, for instance. </p></desc>
<instances>
<instance>
<uri>http://example.com/robots.txt</uri>
<method>GET</method>
<evidence>Age: 214571</evidence>
</instance>
<instance>
<uri>http://example.com</uri>
<method>GET</method>
<evidence>HIT</evidence>
</instance>
<instance>
<uri>http://example.com/sitemap.xml</uri>
<method>GET</method>
<evidence>Age: 447454</evidence>
</instance>
<instance>
<uri>http://example.com/</uri>
<method>GET</method>
<evidence>HIT</evidence>
</instance>
</instances>
<count>4</count>
<solution><p>Validate that the response does not contain sensitive, personal or user-specific information. If it does, consider the use of the following HTTP response headers, to limit, or prevent the content being stored and retrieved from the cache by another user:</p><p>Cache-Control: no-cache, no-store, must-revalidate, private</p><p>Pragma: no-cache</p><p>Expires: 0</p><p>This configuration directs both HTTP 1.0 and HTTP 1.1 compliant caching servers to not store the response, and to not retrieve the response (without validation) from the cache, in response to a similar request.</p></solution>
<otherinfo><p>The presence of the 'Age' header indicates that that a HTTP/1.1 compliant caching server is in use.</p></otherinfo>
<reference><p>https://tools.ietf.org/html/rfc7234</p><p>https://tools.ietf.org/html/rfc7231</p><p>http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html (obsoleted by rfc7234)</p></reference>
<sourceid>3</sourceid>
</alertitem>
<alertitem>
<pluginid>10038</pluginid>
<alert>Content Security Policy (CSP) Header Not Set</alert>
<name>Content Security Policy (CSP) Header Not Set</name>
<riskcode>1</riskcode>
<confidence>2</confidence>
<riskdesc>Low (Medium)</riskdesc>
<desc><p>Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware. CSP provides a set of standard HTTP headers that allow website owners to declare approved sources of content that browsers should be allowed to load on that page — covered types are JavaScript, CSS, HTML frames, fonts, images and embeddable objects such as Java applets, ActiveX, audio and video files.</p></desc>
<instances>
<instance>
<uri>http://example.com/sitemap.xml</uri>
<method>GET</method>
</instance>
<instance>
<uri>http://example.com/robots.txt</uri>
<method>GET</method>
</instance>
<instance>
<uri>http://example.com/</uri>
<method>GET</method>
</instance>
<instance>
<uri>http://example.com</uri>
<method>GET</method>
</instance>
</instances>
<count>4</count>
<solution><p>Ensure that your web server, application server, load balancer, etc. is configured to set the Content-Security-Policy header, to achieve optimal browser support: "Content-Security-Policy" for Chrome 25+, Firefox 23+ and Safari 7+, "X-Content-Security-Policy" for Firefox 4.0+ and Internet Explorer 10+, and "X-WebKit-CSP" for Chrome 14+ and Safari 6+.</p></solution>
<reference><p>https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Introducing_Content_Security_Policy</p><p>https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html</p><p>http://www.w3.org/TR/CSP/</p><p>http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html</p><p>http://www.html5rocks.com/en/tutorials/security/content-security-policy/</p><p>http://caniuse.com/#feat=contentsecuritypolicy</p><p>http://content-security-policy.com/</p></reference>
<cweid>16</cweid>
<wascid>15</wascid>
<sourceid>3</sourceid>
</alertitem>
<alertitem>
<pluginid>10021</pluginid>
<alert>X-Content-Type-Options Header Missing</alert>
<name>X-Content-Type-Options Header Missing</name>
<riskcode>1</riskcode>
<confidence>2</confidence>
<riskdesc>Low (Medium)</riskdesc>
<desc><p>The Anti-MIME-Sniffing header X-Content-Type-Options was not set to 'nosniff'. This allows older versions of Internet Explorer and Chrome to perform MIME-sniffing on the response body, potentially causing the response body to be interpreted and displayed as a content type other than the declared content type. Current (early 2014) and legacy versions of Firefox will use the declared content type (if one is set), rather than performing MIME-sniffing.</p></desc>
<instances>
<instance>
<uri>http://example.com</uri>
<method>GET</method>
<param>X-Content-Type-Options</param>
</instance>
<instance>
<uri>http://example.com/</uri>
<method>GET</method>
<param>X-Content-Type-Options</param>
</instance>
</instances>
<count>2</count>
<solution><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.</p><p>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></solution>
<otherinfo><p>This issue still applies to error type pages (401, 403, 500, etc.) as those pages are often still affected by injection issues, in which case there is still concern for browsers sniffing pages away from their actual content type.</p><p>At "High" threshold this scan rule will not alert on client or server error responses.</p></otherinfo>
<reference><p>http://msdn.microsoft.com/en-us/library/ie/gg622941%28v=vs.85%29.aspx</p><p>https://owasp.org/www-community/Security_Headers</p></reference>
<cweid>16</cweid>
<wascid>15</wascid>
<sourceid>3</sourceid>
</alertitem>
<alertitem>
<pluginid>10020</pluginid>
<alert>X-Frame-Options Header Not Set</alert>
<name>X-Frame-Options Header Not Set</name>
<riskcode>2</riskcode>
<confidence>2</confidence>
<riskdesc>Medium (Medium)</riskdesc>
<desc><p>X-Frame-Options header is not included in the HTTP response to protect against 'ClickJacking' attacks.</p></desc>
<instances>
<instance>
<uri>http://example.com</uri>
<method>GET</method>
<param>X-Frame-Options</param>
</instance>
<instance>
<uri>http://example.com/</uri>
<method>GET</method>
<param>X-Frame-Options</param>
</instance>
</instances>
<count>2</count>
<solution><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></solution>
<reference><p>https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options</p></reference>
<cweid>16</cweid>
<wascid>15</wascid>
<sourceid>3</sourceid>
</alertitem>
</alerts></site></OWASPZAPReport>