How to remediate – Web Site Accepts Credit Card Data over cleartext HTTP

1. Introduction

The Web Site Accepts Credit Card Data over cleartext HTTP vulnerability means a website is sending credit card details without encryption. This exposes sensitive information to interception, potentially leading to fraud and data breaches. Websites handling payment information are usually affected, especially those not using Transport Layer Security (TLS). A successful attack could compromise the confidentiality of customer payment data.

2. Technical Explanation

The vulnerability occurs when HTML forms accept credit card details via unencrypted HTTP connections. The server contains an HTML form field with an input type of ‘cc-number’ or similar, indicating it’s designed to collect payment information. An attacker can intercept this data in transit using network sniffing tools. There is no direct risk to the webserver itself, but customer data is at risk.

• Root cause: The website does not enforce HTTPS for pages handling credit card details.
• Exploit mechanism: An attacker uses a packet sniffer (like Wireshark) on the same network as the user or intercepts traffic through a man-in-the-middle attack to capture the unencrypted data sent from the user’s browser to the web server. For example, an attacker could set up a rogue Wi-Fi hotspot and intercept traffic from users connecting to it.
• Scope: Any website using HTML forms to collect credit card details without TLS is affected.

3. Detection and Assessment

Confirming the vulnerability involves checking if payment pages use HTTPS. A quick check can be done through a browser, while thorough assessment requires network analysis.

• Quick checks: Use your web browser to visit the page where credit card details are entered. Check that the address bar shows “https://” and a padlock icon.
• Scanning: Nessus vulnerability scanner ID 75653fc3 can identify this issue. This is an example only, other scanners may also detect it.
• Logs and evidence: Web server access logs might show requests to payment pages over HTTP instead of HTTPS. Look for form submissions on port 80.

curl -I https://example.com/paymentpage # Check the response headers for TLS configuration. Replace example.com with your domain.

4. Solution / Remediation Steps

The solution is to enforce TLS (HTTPS) on all web pages handling credit card data.

4.1 Preparation

• Ensure you have valid SSL/TLS certificates installed and configured. A roll back plan involves reverting to the previous web server configuration.
• A change window may be needed depending on service impact. Approval from a security team is recommended.

4.2 Implementation

1. Step 1: Configure your web server (e.g., Apache, Nginx, IIS) to redirect all HTTP traffic to HTTPS for the payment pages or entire website.
2. Step 2: Ensure that the SSL/TLS certificate is correctly installed and configured on the web server.
3. Step 3: Restart the web server to apply the changes.

4.3 Config or Code Example

Before

# Apache example - no redirect
Listen 80
<VirtualHost *:80>
  ServerName example.com
  DocumentRoot /var/www/html
</VirtualHost>

After

# Apache example - redirect HTTP to HTTPS
Listen 80
<VirtualHost *:80>
  ServerName example.com
  Redirect permanent / https://example.com/
</VirtualHost>

4.4 Security Practices Relevant to This Vulnerability

Several security practices help prevent this issue.

• Practice 1: Secure defaults – configure web servers with HTTPS enabled by default, or enforce redirects.
• Practice 2: Input validation – while not directly preventing the transmission issue, validate all input data to reduce risks if interception occurs.

4.5 Automation (Optional)

If using infrastructure-as-code tools like Ansible, you can automate the web server configuration.

# Example Ansible task to configure HTTP to HTTPS redirect
- name: Redirect HTTP to HTTPS for example.com
  apache2_module:
    name: rewrite
    state: present
  become: true
- name: Add redirect rule
  lineinfile:
    path: /etc/apache2/sites-available/example.com.conf
    regexp: '^Redirect permanent /'
    line: 'Redirect permanent / https://example.com/'
    state: present
  become: true
  notify: Restart Apache

5. Verification / Validation

Confirm the fix by checking that all payment pages redirect to HTTPS and that no sensitive data is transmitted over HTTP.

• Post-fix check: Use `curl -I http://example.com/paymentpage` and verify the response code is 301 (Permanent Redirect) or 302 (Temporary Redirect).
• Re-test: Re-run the quick check from Section 3 to confirm that all payment pages now use HTTPS.
• Smoke test: Test submitting a dummy credit card form on the payment page to ensure it processes correctly over HTTPS.
• Monitoring: Monitor web server access logs for any requests to payment pages over HTTP. A simple query could look for entries with “HTTP” and “/paymentpage”. This is an example only.

curl -I http://example.com/paymentpage # Expected output should show a 301 or 302 redirect to HTTPS

6. Preventive Measures and Monitoring

Update security baselines and implement checks in your CI/CD pipeline.

• Baselines: Update your web server security baseline to require HTTPS for all sensitive pages, aligning with CIS benchmarks or similar standards.
• Pipelines: Add static analysis (SAST) tools to your CI/CD pipeline to detect insecure configurations like missing HTTP redirects.
• Asset and patch process: Review web server configurations regularly as part of a vulnerability management program. A monthly review is sensible for high-risk systems.

7. Risks, Side Effects, and Roll Back

Redirecting to HTTPS could cause compatibility issues with older browsers or require updates to client-side code.

• Risk or side effect 1: Compatibility issues with very old browsers that do not support TLS 1.2. Mitigation: Ensure users are using modern browsers.
• Risk or side effect 2: Potential for mixed content warnings if other resources on the page are loaded over HTTP. Mitigation: Update all resources to use HTTPS.
• Roll back: Revert the web server configuration changes made in Section 4.2, removing the redirect rule and restarting the web server.

8. References and Resources

Links to official advisories and documentation.

• Vendor advisory or bulletin: http://www.nessus.org/u?75653fc3
• NVD or CVE entry: No specific CVE is associated with this general finding, but related vulnerabilities may exist depending on the web server software used.
• Product or platform documentation relevant to the fix: Refer to your web server’s documentation for instructions on configuring HTTPS and redirects (e.g., Apache TLS configuration guide).