How to remediate – Strict Transport Security (STS) Detection

1. Introduction

Strict Transport Security (STS) is a web server mechanism that forces browsers to connect using HTTPS. It helps prevent man-in-the-middle attacks and accidental downgrades to insecure HTTP connections. Web servers are commonly affected, particularly those handling sensitive data or user authentication. A successful compromise could lead to loss of confidentiality, integrity, and availability of transmitted information.

2. Technical Explanation

STS works by the server sending a specific header in its responses. This tells the browser to only connect over HTTPS for a defined period. An attacker can exploit this if STS is incorrectly configured or missing on a server that should have it, allowing them to intercept traffic. There isn’t a CVE associated with simply *having* STS enabled; rather, misconfiguration is the risk.

• Root cause: The web server is configured to implement Strict Transport Security (STS).
• Exploit mechanism: An attacker could attempt a man-in-the-middle attack on an HTTP connection if HTTPS isn’t enforced. STS prevents this by redirecting all unencrypted requests to the secure protocol.
• Scope: Any web server capable of sending HTTP headers, including Apache, Nginx, IIS and cloud services like AWS ELB or Azure Application Gateway.

3. Detection and Assessment

You can confirm STS is implemented by checking the response headers from a web server. A thorough assessment involves verifying the policy duration and included domains.

• Quick checks: Use `curl -I https://example.com` (replace example.com with your target) and look for the ‘Strict-Transport-Security’ header in the output.
• Scanning: Nessus vulnerability ID 2fb3aca6 can detect STS implementation. This is an informational check, not a direct exploit.
• Logs and evidence: Web server access logs will show all requests, including redirects to HTTPS if STS is active.

curl -I https://example.com

4. Solution / Remediation Steps

The following steps outline how to ensure correct STS implementation.

4.1 Preparation

• Dependencies: Ensure you have access to modify the web server’s configuration files. Roll back by restoring the original configuration file if needed.
• Change window: A short maintenance window may be required, depending on the server and traffic levels.

4.2 Implementation

1. Step 1: Add the `Strict-Transport-Security` header to your web server’s configuration file. The exact method varies by server type (see examples below).
2. Step 2: Restart or reload the web server to apply the changes.
3. Step 3: Test that HTTPS is enforced and redirects are working as expected.

4.3 Config or Code Example

Before

# No Strict-Transport-Security header configured

After

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

4.4 Security Practices Relevant to This Vulnerability

• Secure Headers: Implementing secure headers like STS, HSTS, X-Frame-Options and Content-Security-Policy helps protect against common web attacks.
• Patch Cadence: Regularly updating your web server software ensures you have the latest security fixes.

4.5 Automation (Optional)

If using a configuration management tool like Ansible, you can automate STS header deployment.

# Example Ansible task
- name: Add Strict-Transport-Security header to Nginx config
  lineinfile:
    path: /etc/nginx/conf.d/default.conf
    regexp: '^add_header'
    line: 'add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"'

5. Verification / Validation

Confirm the fix by checking for the STS header in browser developer tools or using `curl`. A negative test involves attempting to connect over HTTP.

• Post-fix check: Run `curl -I https://example.com` and verify that the ‘Strict-Transport-Security’ header is present with your configured values.
• Re-test: Re-run the initial `curl` command from the Detection section to confirm the header is now visible.
• Smoke test: Ensure users can still access the website over HTTPS without any issues.
• Monitoring: Monitor web server logs for redirects to HTTPS and errors related to SSL/TLS connections.

curl -I https://example.com

6. Preventive Measures and Monitoring

• Baselines: Include STS configuration in your security baseline or hardening guide.
• Pipelines: Integrate SAST tools into your CI/CD pipeline to identify missing or misconfigured headers.
• Asset and patch process: Review web server configurations regularly as part of your asset management process.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Incorrect STS configuration can lock users out of the website if HTTPS is not properly set up.
• Risk or side effect 2: Preloading STS requires careful planning as it’s difficult to undo once submitted.
• Roll back: Remove the `Strict-Transport-Security` header from your web server configuration and restart/reload the server.

8. References and Resources

• Vendor advisory or bulletin: Check your web server vendor’s documentation for STS implementation details (e.g., Apache, Nginx).
• NVD or CVE entry: Not applicable as this is a configuration issue, not a specific vulnerability.
• Product or platform documentation relevant to the fix: http://www.nessus.org/u?2fb3aca6