Dispute HSTS-Failed PCI Scans

Alert Logic® PCI scans may fail on "HTTP Strict Transport Security Missing". This article can help you understand why your scan is failing and how you can dispute it.

In This Article

• HTTP Strict Transport Security Background
• Why Alert Logic Fails PCI Scans on HSTS
  • Possible Causes
• How to Dispute an HSTS-Failed PCI Scan

HTTP Strict Transport Security Background

The HTTP Strict Transport Security (HSTS) standard was introduced in 2012 and has become best practice within the industry. HSTS protects against:

• SSL Stripping in man-in-the-middle attacks
• Misconfigured web servers that inadvertently allow sensitive traffic on HTTP
• User overrides of invalid certificates, typically introduced by man-in-the-middle attacks
• Browsers that miss an HTTP to HTTPS redirect, typically due to bookmark or deep link

Why Alert Logic Fails PCI Scans on HSTS

HSTS is relevant on both HTTP and HTTPS for servers that handle sensitive information, and Alert Logic checks all HTTPS connections for HSTS.

HSTS is rated as a "PCI Fail" based on either of the following two requirements:

1. Secure web server configuration requirement
   
   "The ASV scanning solution must be able to test for all known vulnerabilities and configuration issues on web servers" (PCI Data Security Standard Approved Scanning Vendor v3.0, pg 25).
   
   "The ASV scan solution must be able to detect via automated or manual means current vulnerabilities and configuration issues (for example, OWASP Top 10, SANS CWE Top 25, etc.)" (PCI Data Security Standard Approved Scanning Vendor v3.0, pg 25).
   
   HSTS violates the web server misconfigurations requirement due to OWASP Top 10 A6-Sensitive-Data-Exposure sub-requirements 5, which reads "Are any browser security directives or headers missing when sensitive data is provided by/sent to the customer?"
   
   
2. Common Vulnerability Scoring System (CVSS) base score of 4.0 or higher requirement
   
   "To assist customers in providing the solution or mitigating identified issues, ASV must assign a severity level to each identified vulnerability or misconfiguration ... whenever possible. ASVs must use ... CVSS version 2.0 ... Any vulnerability with a CVSS score of 4.0 or higher will result in a non-compliant scan, and all such vulnerabilities must be remediated by the scan customer" (PCI Data Security Standard Approved Scanning Vendor v2.0, pg 22 & v3.0, pg 30).
   
   HSTS rates as 4.8 on CVSS base score, and thus violates the requirement that the CVSS base score stay under 4.0 in order to pass. Additionally, there are exploits in the wild.

Possible Causes

The test checks for the presence of the header and will trigger if it is not presented. We have not seen this as a false positive, but if it is believed to have been triggered in error, it is important to determine the underlying cause. The evidence details should be the first place you look. The details should look similar to one of the following:

• "Evidence: Port: TCP/443 https://example.com/ No http strict transport_security detected"
• "Evidence: Port: TCP/443 https://192.168.1.1/ No http strict transport_security detected"

Common Causes

1. Test was against an IP.
   
   In nearly every case, the scan target should be the FQDN of the host. However, the scan will test the FQDN and the resolved IP. It is common for load balancers, cloud services/devices, and hosts serving virtual sites to respond with an error message that has minimal headers when the request is made to the IP (Ex. "404 Page Not Found").
   
   
2. Host presents a redirect at the root.
   
   Redirects - commonly "301" and "302" - will not contain security headers in many cases. The test does not follow these and will see the lack of security header on the initial return as a positive result.
   
   
3. SSL/TLS service error.
   
   In some cases, there may be an issue with the SSL/TLS service. The most common error is a handshake failure. These should be addressed, and a re-scan performed.
   
   
4. Services do not support the browser (Ex. APIs, VPN clients, etc.).
   
   
5. HSTS lifetime is too short.
   
   It is recommended to have a lifetime of at least 10368000 seconds (120 days) with a year being preferred. The directive "includeSubDomains" should also be included.
   
   
6. The header was sent over HTTP.
   
   The RFC states that the header should not be sent over plaintext (HTTP) communication.
   
   
7. A redirect is in place that sends the client to a different host.
   
   When scanning, efforts are made to restrict traffic to the configured target. A redirection from https://alertlogic.com to https://www.alertlogic.com are logically different hosts under same-origin policy. The test will not follow this redirection and will alert that the header is missing.

How to Dispute an HSTS-Failed PCI Scan

Restricting connections to HTTPS does not address all security concerns HSTS is intended to protect against. Take the following scenarios:

• "The visitor types http://www.foo.com/ or even just foo.com. This creates an opportunity for a man-in-the-middle attack. The redirect could be exploited to direct visitors to a malicious site instead of the secure version of the original site."
  
  
• "You log into a free Wifi access point at an airport and start surfing the web, visiting your online banking service to check your balance and pay a few bills. Unfortunately, the access point you are using is actually a hacker's laptop, and they are intercepting your original HTTP request and redirecting to a clone of your bank's site. Now your private data is exposed to the hacker."

"Strict Transport Security resolves these problems; as long as you have accessed your bank's website once using HTTPS and the bank's websiite uses Strict Transport Security, your browser will know to automatically use only HTTPS, which prevents hackers from performing these sorts of man-in-the-middle attacks" (MDN Web Docs, Strict-Transport-Security).

For a PCI dispute to be approved for the "HSTS Missing" scan failure, the customer must substantiate one of the following after examining the evidence and determining the cause:

1. If there is a redirect used or the evidence shows the test was against the IP, the behavior needs to be described in the dispute statement.
   
   - Example: Incorrect - "We have HSTS configured."
   - Example: Correct - "HSTS is configured when using FQDN. The host refuses requests made to IP."
   
   
2. The service does not serve browser-based traffic (i.e. APIs). The dispute should describe the service and behavior.
   
   
3. You are using an older Cisco AnyConnet VPN, which:
   
   - Does not support web browsing services
   - Client-based VPN
   - Is running a supported version of Cisco IOS and version is provided
   - On which you have enabled Cisco Strict Certificate Trust
   
   
4. SSL/TLS Failures for web applications need to be corrected and a re-scan performed.