HTTP Security Header not detected
CBack85
Newbie ✭
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.
Impact
Depending on the vulnerability being exploited, an unauthenticated remote attacker could conduct cross-site scripting, clickjacking or MIME-type sniffing attacks.
Solution
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:
X-Frame-Options:
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>
X-XSS-Protection:
Apache: Header always set X-XSS-Protection "1; mode=block"
PHP: header("X-XSS-Protection: 1; mode=block");
X-Content-Type-Options:
Apache: Header always set X-Content-Type-Options: nosniff
HTTP Strict-Transport-Security:
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.
Answers
You havent provided enough information. Is the IP address being 'scanned' the one used by the Sonicwalls WAN interface? Do you have HTTP or HTTPS management enabled on the interface? If so, are you not limiting access to the management interface via its Access Rule? Do you have SSLVPN running on port 443? What firmware version are you running?
Either turn off HTTP/S management on your WAN interface or restrict access to HTTP/S management to only known good IPs.
Hope that helps.
Did you have any luck with figuring this out?
TKWITS
Is there a tutorial for Sonicwall TZ Series settings to allow for PCI Compliance pass. I have the issue the CBACK85 is having but he does not provide any solution. You have asked the correct question, in my opinion. On my TZ series I have turned off Remote Access, I do not have any VPN services running on it. I would like to re enable remote administration on the WAN port but need to pass PCI compliance test. Are there any suggestions that you can give me that will allow for PCI compliance. Will purchasing a security cert. instead of Self Signed Cert help. Self Signed Cert is currently pointing to LAN IP? Advice would be appreciated
Other than some old, vague documentation, not that I am aware of. But most compliance requirements are explicitly written to be vague...
As mentioned prior: restrict access to HTTP/S WAN management to only known good IPs; update your firmware; if you are using SSLVPN / GVPN get a cert from a public CA.
Specific failures and details on each environment are a must.
The resolution for resolving some of the X-Content-Type PCI compliance scan failures was found here on page 13: https://www.sonicwall.com/techdocs/pdf/SMA-100-Series-Security-Best-Practices-Guide.pdf
Enable HTTP Strict Transport Security (HSTS) for SMA. I also disabled HTTP management and only left HTTPS management enabled.
In the end (with Qualys), we also had to submit a false-positive report because they were looking for max-age, which the SonicWall SMA is not responding with. Demonstration that HSTS is enabled is critical to acceptance of the false-positive conclusion by the ASV.