HTTP Security Header not detected
Doing a scan for PCI compliance and this is coming across on the scanner. Has anyone come across this on the SMA6200 appliance or any other SonicWall device and found a fix for it? I will attach the file info below that came from the scanner.
Here is the detailed info for HTTP Security Header not detected:
This QID reports the absence of the following HTTP headers<https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#tab=Headers> according to CWE-693: Protection Mechanism Failure<https://cwe.mitre.org/data/definitions/693.html>:
X-Frame-Options: This HTTP response header improves the protection of web applications against clickjacking attacks. Clickjacking, also known as a "UI redress attack", allows an attacker to use multiple transparent or opaque layers to trick a targeted user into clicking on a button or link on another page when they were intending to click on the top level page.
X-XSS-Protection: This HTTP header enables the browser built-in Cross-Site Scripting (XSS) filter to prevent cross-site scripting attacks. X-XSS-Protection: 0; disables this functionality.
X-Content-Type-Options: This HTTP header prevents attacks based on MIME-type mismatch. The only possible value is nosniff. If your server returns X-Content-Type-Options: nosniff in the response, the browser will refuse to load the styles and scripts in case they have an incorrect MIME-type.
Strict-Transport-Security: The HTTP Strict-Transport-Security response header (HSTS) is a security feature that lets a website tell browsers that it should only be communicated with using HTTPS, instead of using HTTP.
QID Detection Logic:
This unauthenticated QID looks for the presence of the following HTTP responses:
Valid directives for X-Frame-Options are:
X-Frame-Options: DENY - The page cannot be displayed in a frame, regardless of the site attempting to do so.
X-Frame-Options: SAMEORIGIN - The page can only be displayed in a frame on the same origin as the page itself.
X-Frame-Options: ALLOW-FROM RESOURCE-URL - The page can only be displayed in a frame on the specified origin.
Valid directives for X-XSS-Protections are:
X-XSS-Protection: 1 - Enables XSS filtering (usually default in browsers). If a cross-site scripting attack is detected, the browser will sanitize the page (remove the unsafe parts).
X-XSS-Protection: 1; mode=block - Enables XSS filtering. Rather than sanitizing the page, the browser will prevent rendering of the page if an attack is detected.
X-XSS-Protection: 1; report=URI - Enables XSS filtering. If a cross-site scripting attack is detected, the browser will sanitize the page and report the violation. This uses the functionality of the CSP report-uri directive to send a report.
X-XSS-Protection: 0 disables this directive and hence is also treated as not detected.
A valid directive for X-Content-Type-Options: nosniff
A valid HSTS directive Strict-Transport-Security: max-age=<expire-time>; [; includeSubDomains][; preload]
NOTE: All report-only directives (where applicable) are considered invalid.
Depending on the vulnerability being exploited, an unauthenticated remote attacker could conduct cross-site scripting, clickjacking or MIME-type sniffing attacks.
Note: To better debug the results of this QID, it is requested that customers execute commands to simulate the following functionality: curl -lkL --verbose.
CWE-693: Protection Mechanism Failure mentions the following - The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product. A "missing" protection mechanism occurs when the application does not define any mechanism against a certain class of attack. An "insufficient" protection mechanism might provide some defenses - for example, against the most common attacks - but it does not protect against everything that is intended. Finally, an "ignored" mechanism occurs when a mechanism is available and in active use within the product, but the developer has not applied it in some code path.
Customers are advised to set proper X-Frame-Options<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options>, X-XSS-Protection<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection>, X-Content-Type-Options<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options> and Strict-Transport-Security<https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security> HTTP response headers.
Depending on their server software, customers can set directives in their site configuration or Web.config files. Few examples are:
Apache: Header always append X-Frame-Options SAMEORIGIN
nginx: add_header X-Frame-Options SAMEORIGIN;
HAProxy: rspadd X-Frame-Options:\ SAMEORIGIN
IIS: <HTTPPROTOCOL><CUSTOMHEADERS><ADD NAME="X-Frame-Options" VALUE="SAMEORIGIN"></ADD></CUSTOMHEADERS></HTTPPROTOCOL>
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");
Apache: Header always set X-Content-Type-Options: nosniff
Apache: Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Nginx: add_header Strict-Transport-Security max-age=31536000;
Note: Network devices that include a HTTP/HTTPS console for administrative/management purposes often do not include all/some of the security headers. This is a known issue and it is recommend to contact the vendor for a solution.