Scanning for and fixing an Open Redirect Vulnerability

At work, I am responsible for managing some web-services hosted on VMs at the company’s data center. Yesterday, I received a mail from the CERT department about a configuration error in the redirection from http to https. The relevant part of the Apache HTTP Server’s configuration reads as follows:

<VirtualHost *:80>
    ServerName service.company.com
    Redirect permanent / https://service.company.com
</VirtualHost>

So nothing complex, very basic stuff. However, line 3 holds a minor but potentially dangerous issue, making the server vulnerable for an open redirect attack. To demonstrate this, consider the following command that allows analyzing the chain of requests when requesting a specific URL:

$ curl -sLD - http://service.company.com -o /dev/null | egrep "^(HTTP|Location)"
HTTP/1.1 301 Moved Permanently
Location: https://service.company.com
HTTP/1.1 200 OK

The redirect is performing just as intended. However, as soon as there is a path attached to the URL, this will break:

$ curl -sLD - http://service.company.com/login -o /dev/null | egrep "^(HTTP|Location)"
HTTP/1.1 301 Moved Permanently
Location: https://service.company.comlogin

As you can see, the slash between the base URL and the path gets lost, leading to an issue called the Open Redirect vulnerability. The problem arises when an attacker, having control over the URL malicious.com, manages to make one of the employes click on a link that seems trustworthy, like company.com/importantinfo, which essentially goes to http://company.com/.malicious.com. So while the request initially goes to the company’s server, due to the misconfiguration, the redirect looks as follows:

$ curl -sLD - http://service.company.com/.malicious.com -o /dev/null | egrep "^(HTTP|Location)"
HTTP/1.1 301 Moved Permanently
Location: https://service.company.com.malicious.com

However, the fix to the issue is quite trivial. It’s important to add a trailing slash to the target URL of the redirect:

<VirtualHost *:80>
    ServerName service.company.com
    Redirect permanent / https://service.company.com/
</VirtualHost>

Now the redirect stays on our own server, revealing the attack:

$ curl -sLD - http://service.company.com/.malicious.com -o /dev/null | egrep "^(HTTP|Location)"
HTTP/1.1 301 Moved Permanently
Location: https://service.company.com/.malicious.com
HTTP/1.1 404 Not Found