How to remediate – Non-compliant Strict Transport Security (STS)

1. Introduction

Strict Transport Security (STS) tells browsers to only connect to a web server using HTTPS. A non-compliant implementation means the server isn’t fully following the STS standard, potentially leaving it open to downgrade attacks. This affects any web servers that use HTTPS and aim for strong security. Impact on confidentiality is likely if an attacker can force HTTP connections; integrity may be compromised by man-in-the-middle attacks; availability is less directly affected.

2. Technical Explanation

• Root cause: Incorrectly configured Strict-Transport-Security header in the web server’s response.
• Scope: Web servers running Apache, Nginx, IIS or other web server software with STS enabled. Affected versions depend on the specific server software and its STS implementation.

3. Detection and Assessment

Confirming a non-compliant STS configuration involves checking the HTTP response headers. A quick check is to use browser developer tools. Thorough assessment uses dedicated security scanners.

• Quick checks: Open your web server in Chrome, Firefox or Edge. Press F12 to open Developer Tools and navigate to the Network tab. Reload the page and inspect the HTTP response headers for the Strict-Transport-Security header.
• Scanning: Nessus plugin ID 2fb3aca6 can identify non-compliant STS configurations. Other scanners like Qualys SSL Labs may also report this issue.
• Logs and evidence: Web server access logs might show both HTTP and HTTPS requests, indicating potential downgrade attempts. Look for responses without the Strict-Transport-Security header on initial HTTPS connections.

curl -I https://yourdomain.com | grep "Strict-Transport-Security"

4. Solution / Remediation Steps

Fixing this requires correctly configuring the Strict-Transport-Security header in your web server. The steps below outline a general approach, but specifics vary by server software.

4.1 Preparation

• Ensure you have access to modify the web server’s configuration file. A roll back plan is to restore the original configuration file if issues occur.
• A change window may be needed for production systems, requiring approval from the security or infrastructure team.

4.2 Implementation

1. Step 1: Open your web server’s main configuration file (e.g., httpd.conf for Apache, nginx.conf for Nginx).
2. Step 2: Add or modify the Strict-Transport-Security header within the virtual host configuration. Use a syntax like `Strict-Transport-Security: max-age=31536000; includeSubDomains; preload`.
3. Step 3: Save the configuration file.
4. Step 4: Restart your web server to apply the changes.

4.3 Config or Code Example

Before

Strict-Transport-Security: max-age=10800

After

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

4.4 Security Practices Relevant to This Vulnerability

Several security practices help prevent STS misconfigurations and related attacks. These focus on secure configuration, header policies, and regular review.

• Practice 1: Secure headers – implementing strong HTTP security headers like HSTS, X-Frame-Options, and Content-Security-Policy reduces attack surface.
• Practice 2: Patch cadence – keeping web server software up to date ensures you have the latest security fixes and improvements.

4.5 Automation (Optional)

If using configuration management tools like Ansible, Puppet or Chef, automate the deployment of STS headers across your infrastructure.

# Example Ansible task to set HSTS header
- name: Set Strict-Transport-Security header in Apache virtual host
  lineinfile:
    path: /etc/apache2/sites-available/yourdomain.conf
    regexp: '^Strict-Transport-Security:'
    line: 'Strict-Transport-Security: max-age=31536000; includeSubDomains; preload'
    state: present
  notify: Restart Apache

5. Verification / Validation

• Post-fix check: Run `curl -I https://yourdomain.com | grep “Strict-Transport-Security”`. Expected output should include `Strict-Transport-Security: max-age=31536000; includeSubDomains; preload`.
• Re-test: Re-run the Nessus scan (ID 2fb3aca6) and confirm that it no longer reports a non-compliant STS configuration.

curl -I https://yourdomain.com | grep "Strict-Transport-Security"

6. Preventive Measures and Monitoring

Regular security baselines and automated checks help prevent STS issues. For example, update your CIS benchmark or GPO/Intune settings to include a strong HSTS policy.

• Baselines: Update your web server security baseline to require the correct Strict-Transport-Security header configuration.
• Asset and patch process: Implement a regular review cycle for web server configurations to identify and address any misconfigurations or outdated settings.

7. Risks, Side Effects, and Roll Back

Incorrectly configuring STS can cause browser compatibility issues. A roll back involves restoring the original configuration file.

• Risk or side effect 2: Very long max-age values can be difficult to revert quickly if needed. Mitigation is to start with a shorter value and increase it gradually.
• Roll back: Restore the original web server configuration file from your backup. Restart the web service.

8. References and Resources

• Vendor advisory or bulletin: Check your web server vendor’s documentation for specific STS configuration guidance (e.g., Apache, Nginx, IIS).
• NVD or CVE entry: No specific CVE is associated with a general non-compliant STS configuration; however