Skip to content

Mitigating False Positive SSL Certificate Findings

When a vulnerability scanner is showing an untrusted SSL certificate vulnerability for a web server when scanning by IP address, despite having a valid certificate for the domain itself, we can remediate this by simply adding a 301 redirect into the web server’s configuration file for all requests to the server that are not specifying the domain.

Implementing a 301 redirect can help address the untrusted SSL certificate vulnerability that occurs when accessing a web server using its IP address instead of its domain name. Here’s how and why this approach works:

Understanding the Issue

  • SSL Certificates and Domain Names: SSL certificates are typically issued for specific domain names. When a web server is accessed via its IP address, the SSL certificate for the domain does not match the IP address, resulting in an “untrusted certificate” warning.

Remediation with a 301 Redirect

  • 301 Redirect: By configuring your web server to issue a 301 redirect for requests made to the server’s IP address, you can automatically redirect users to the correct domain name. This ensures that the SSL certificate matches the domain, eliminating the untrusted certificate warning.

Steps to Implement a 301 Redirect

  1. Edit Web Server Configuration: Access the configuration file for your web server (e.g., Apache’s httpd.conf or Nginx’s nginx.conf).

  2. Add Redirect Rules:

    • For Apache, you can use the RewriteEngine and RewriteRule directives in your .htaccess file or in the main configuration file:

      RewriteEngine On
RewriteCond %{HTTP_HOST} ^your.ip.address$
RewriteRule ^(.*)$ https://yourdomain.com$1 [R=301,L]

    • For Nginx, use the return directive in the server block handling the IP address:

      server {
    listen 80;
    server_name your.ip.address;
    return 301 https://yourdomain.com$request_uri;
}

  3. Test the Configuration: After applying the changes, restart your web server to ensure the new configuration is loaded. Test the redirect by accessing the server using the IP address to verify that it correctly redirects to the domain.

Considerations

  • Security: Ensure that the redirection does not inadvertently expose any security vulnerabilities, such as open redirects.
  • SEO Impact: While 301 redirects are generally safe for SEO, ensure that all external links and bookmarks use the domain name to prevent unnecessary redirects.

By implementing the 301 redirect, you can effectively mitigate the untrusted SSL certificate vulnerability when users attempt to access your web server using its IP address.

But what about those open redirects?

An open redirect is a type of security vulnerability that occurs when a web application accepts user-controlled input to generate a URL for redirection without proper validation or restrictions. This can be exploited by attackers to redirect users to malicious sites without their knowledge or consent. It's important to understand how open redirects work, why they are problematic, and what we can do to prevent them.

How Open Redirects Work

  1. User Input for Redirection: A web application may take a URL as input to redirect users to a different page or site. This is often used in login processes, URL shorteners, or page forwarding functionalities.

  2. Lack of Validation: If the application does not validate or restrict the destination URL, an attacker can manipulate the input to redirect users to a malicious website.

  3. Exploitation: An attacker crafts a URL that appears legitimate because it originates from a trusted domain but includes a parameter pointing to a malicious site. When users click the link, they are unknowingly redirected to the attacker’s site.

Why Open Redirects Are Dangerous

  • Phishing Attacks: Attackers can use open redirects in phishing attacks to make malicious links appear trustworthy. Users are more likely to click on a link if it seems to originate from a known and trusted site.

  • Credential Theft: Once redirected to a malicious site, users may be prompted to enter sensitive information, like login credentials, which can then be harvested by attackers.

  • Reputation Damage: If a trusted website is used in open redirect attacks, it can damage the reputation of the organization owning the site and erode user trust.

Preventing Open Redirects

To prevent open redirects, developers should:

  1. Restrict Redirection Targets: Only allow redirection to a predefined list of trusted URLs. Avoid using user input directly for redirection purposes.

  2. Validate Input: Implement strict validation on any URL parameters used for redirection to ensure they point to expected domains or paths.

  3. Use Relative URLs: Where possible, use relative URLs for redirection within the same domain, reducing the risk of redirecting to an external site.

  4. Educate Users: Inform users about the risks of clicking on links, even if they seem to originate from a trusted source, and encourage them to verify URLs.

Example Configurations

Here are examples of both Apache and Nginx configurations that incorporate mitigation techniques to prevent open redirect vulnerabilities, complete with comments explaining each part of the configuration. Let’s include the configuration to ensure that all incoming HTTP requests are redirected to HTTPS, which prevents downgrade attacks by enforcing secure connections.

Apache Configuration Example with HTTPS Redirection

<VirtualHost *:80>
    # Define the server name and alias
    ServerName example.com
    ServerAlias www.example.com

    # Enable the rewrite engine for URL manipulation
    RewriteEngine On

    # Redirect all HTTP requests to HTTPS
    # This ensures all traffic is encrypted and secure
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

    # Redirect all requests to the domain name using HTTPS
    # This ensures that requests using the IP or non-HTTPS are redirected securely
    RewriteCond %{HTTP_HOST} !^example\.com$ [NC]
    RewriteRule ^(.*)$ https://example.com$1 [R=301,L]

    # Example of a fixed internal page redirect
    # This line redirects a specific old page to a new page within the same domain
    RewriteRule ^old-page$ /new-page [R=301,L]

    # Use a whitelist approach if dynamic redirection is necessary
    # Ensure you specify exact match patterns for allowed destinations
    RewriteCond %{QUERY_STRING} ^(.*)(redirect=allowed-page1|redirect=allowed-page2)(.*)$ [NC]
    RewriteRule ^.*$ https://example.com/%2 [R=301,L]
</VirtualHost>

Nginx Configuration Example with HTTPS Redirection

server {
    # Listen on port 80 for incoming HTTP requests
    listen 80;

    # Define the server name and alias
    server_name example.com www.example.com;

    # Redirect all HTTP requests to HTTPS
    # This ensures all traffic is encrypted and secure
    return 301 https://example.com$request_uri;
}

server {
    # Listen on port 443 for incoming HTTPS requests
    listen 443 ssl;

    # Define the server name and alias
    server_name example.com www.example.com;

    # SSL configuration (example)
    ssl_certificate /path/to/ssl_certificate.crt;
    ssl_certificate_key /path/to/ssl_certificate.key;

    # Example of a fixed internal page redirect
    # This line redirects a specific old page to a new page within the same domain
    location = /old-page {
        return 301 /new-page;
    }

    # Use a whitelist approach if dynamic redirection is necessary
    # Ensure you specify exact match patterns for allowed destinations
    location / {
        if ($arg_redirect = "allowed-page1" ) {
            return 301 /allowed-page1;
        }
        if ($arg_redirect = "allowed-page2" ) {
            return 301 /allowed-page2;
        }
    }
}

Explanation of Key Points

  • Fixed Redirect Destinations: These configurations use fixed destinations (/new-page) for redirection within the same domain, eliminating reliance on user input for determining redirect targets.

  • Domain and Protocol Enforcement: Both configurations redirect requests to the canonical domain name and enforce HTTPS, ensuring secure access and reducing the risk of open redirects.

  • Whitelist Approach: In scenarios where dynamic redirection is needed, a whitelist of allowed pages is implemented. This ensures only predefined, safe paths can be redirected to, avoiding redirects to arbitrary user-supplied URLs.

  • Comments: Each line is commented to explain its purpose, aiding in understanding and maintaining the configuration.

  • HTTPS Redirection in Apache: The RewriteCond %{HTTPS} off condition checks if the request is not using HTTPS. If true, the request is redirected to the same URL with HTTPS, ensuring encrypted communication.

  • HTTPS Redirection in Nginx: The return 301 https://example.com$request_uri; directive in the server block listening on port 80 automatically redirects all HTTP traffic to the HTTPS version of the site.