How to remediate – Missing HTTP Strict Transport Security Policy

1. Introduction

Missing HTTP Strict Transport Security Policy means the server isn’t telling browsers to always use HTTPS for connections. This leaves users open to Man-in-The-Middle attacks where attackers intercept data sent over unencrypted HTTP. Systems using both HTTP and HTTPS are usually affected, especially web applications handling sensitive information. A successful attack could compromise confidentiality of user data.

2. Technical Explanation

The root cause is the absence of the `Strict-Transport-Security` header in the server’s HTTP response. An attacker can exploit this by intercepting an initial request over HTTPS, then redirecting subsequent requests to a fake HTTP site. The browser won’t enforce HTTPS because it hasn’t been instructed to do so. This is possible even if the user initially accessed the site via HTTPS.

• Root cause: missing `Strict-Transport-Security` header in server responses.
• Exploit mechanism: An attacker intercepts an HTTPS connection and redirects future requests to a malicious HTTP endpoint, potentially stealing credentials or other sensitive data. For example, using tools like mitmproxy to downgrade the connection.
• Scope: Web servers and applications configured with HTTPS but lacking HSTS header configuration.

3. Detection and Assessment

You can confirm vulnerability by checking server responses for the HSTS header. A quick check is using a browser’s developer tools, while thorough assessment involves dedicated security scanners.

• Quick checks: Use your browser’s developer tools (Network tab) to inspect the response headers when accessing the site via HTTPS. Look for the `Strict-Transport-Security` header.
• Scanning: Nessus or OpenVAS may flag this as a vulnerability with ID 105398 and 76248 respectively, but these are examples only.
• Logs and evidence: Web server access logs won’t directly show this issue; focus on response headers during testing.

curl -I https://example.com

4. Solution / Remediation Steps

Configure the `Strict-Transport-Security` header on your server to enforce HTTPS connections. The implementation varies depending on your web server or framework.

4.1 Preparation

• Ensure you have access to modify the server’s HTTP response headers. A roll back plan is to remove the added header from the configuration file.
• Change windows may be needed depending on service criticality; approval from a security team might be necessary.

4.2 Implementation

1. Step 1: Edit your web server’s configuration file (e.g., Apache’s httpd.conf, Nginx’s nginx.conf).
2. Step 2: Add the `Strict-Transport-Security` header to the HTTP response. A common setting is `Strict-Transport-Security: max-age=31536000; includeSubDomains`.
3. Step 3: Restart your web server to apply the changes.

4.3 Config or Code Example

Before

# No HSTS header configured

After

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

4.4 Security Practices Relevant to This Vulnerability

Several security practices help prevent this issue. Secure headers are key, as is a regular patch cadence.

• Practice 1: Implement secure HTTP headers like HSTS to enforce encryption and protect against MiTM attacks.
• Practice 2: Maintain a consistent patch cadence for your web server software to address known vulnerabilities promptly.

4.5 Automation (Optional)

If using configuration management, automate the header addition.

# Example Ansible task
- name: Add HSTS header to Nginx config
  lineinfile:
    path: /etc/nginx/nginx.conf
    regexp: '^# No HSTS header configured'
    line: 'Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"'

5. Verification / Validation

Confirm the fix by checking for the `Strict-Transport-Security` header in browser developer tools and re-running a vulnerability scan.

• Post-fix check: Use `curl -I https://example.com` and verify that the output includes `Strict-Transport-Security: max-age=31536000; includeSubDomains`.
• Re-test: Re-run your vulnerability scanner to confirm it no longer flags the missing HSTS header.
• Smoke test: Verify users can still access the site via HTTPS without issues and that all functionality remains operational.
• Monitoring: Check web server logs for any errors related to the new header configuration (example query: search for “HSTS” in your logs).

curl -I https://example.com

6. Preventive Measures and Monitoring

Update security baselines to include HSTS, and add checks to CI/CD pipelines.

• Baselines: Update your web server security baseline or policy to require the `Strict-Transport-Security` header with a suitable `max-age`.
• Pipelines: Add static analysis (SAST) tools to your CI/CD pipeline to check for missing HTTP headers in configuration files.
• Asset and patch process: Review web server configurations regularly as part of your asset management or change control process.

7. Risks, Side Effects, and Roll Back

Incorrect header configuration can cause browser compatibility issues. Ensure the `max-age` is appropriate for your environment.

• Risk or side effect 1: Setting a very long `max-age` without proper testing could cause issues with older browsers.
• Risk or side effect 2: Incorrect header syntax can prevent the browser from accepting it.
• Roll back: Remove the added `Strict-Transport-Security` header line from your web server configuration file and restart the service.

8. References and Resources

Link only to sources that match this exact vulnerability. Use official advisories and trusted documentation.

• Vendor advisory or bulletin: Check your web server vendor’s security documentation for specific guidance on HSTS configuration.
• NVD or CVE entry: https://nvd.nist.gov/vuln/detail/CVE-2018-13379
• Product or platform documentation relevant to the fix: https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet