https://man.liquidfiles.com
LiquidFiles Documentation

A common issue that is raised in security audits is that LiquidFiles is "leaking ip address" information.

Background

The "leakage" happens during website redirects (http 301 responses). It's an unfortunate part of the HTTP standard that relative redirect are not permitted, all redirects require a full URL including a hostname.

Normally a web request will include the hostname in the request. To illustrate we'll use the HEAD command, which is like GET but only returns the headers (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4), like this:

% telnet files.liquidftest.com 80
Trying 172.16.5.251...
Connected to files.liquidftest.com.
Escape character is '^]'.
HEAD http://files.liquidftest.com/images HTTP/1.0 HTTP/1.1 301 Moved Permanently Server: nginx Date: Fri, 17 Jul 2015 08:07:58 GMT Content-Type: text/html Content-Length: 178 Location: http://files.liquidftest.com/images/ Connection: close

What we're looking for is Location, and we can see that the hostname matches what we sent in the HEAD command.

Where this becomes a problem is when we don't include the hostname in the HEAD request like:

% telnet files.liquidftest.com 80
Trying 172.16.5.251...
Connected to files.liquidftest.com.
Escape character is '^]'.
HEAD /images HTTP/1.0 HTTP/1.1 301 Moved Permanently Server: nginx Date: Fri, 17 Jul 2015 08:10:17 GMT Content-Type: text/html Content-Length: 178 Location: http://172.16.5.251/images/ Connection: close

Since we didn't include a hostname and the HTTP standard requires that we send a full URL including a hostname part, in this case the webserver in LiquidFiles (nginx) sends its own ip address. This is what's the information "leakage" is that gets highlighted in security scans.

Why is LiquidFiles configured like this on default

We have two options when it comes to the configuration options, either:

  • Permit any host, so that you can type: https://files.company.com, https://files, https://10.2.3.4 and whatever you use to reach the LiquidFiles system will work just fine; or
  • Force the use of one hostname so if you configure files.company.com, that's the only one that works so https://10.2.3.4 will no longer work.

We have choosen the less restrictive option because it offers the most flexibility and will make sure that LiquidFiles will work in most situations, and we believe that "leaking" the ip address of the LiquidFiles system really isn't that bad as there's in reality almost nothing that you can do with that information alone.

How can I change configuration

Starting with LiquidFiles v2.6.16, please login to the console and run `ft webserver_redirect_config` and you can choose from:

  1. Don't use hostname in redirects (default)
  2. Use the system hostname (files.liquidftest.com)
  3. Use a specified hostname

Option 1 works as described above. Option 2 and 3 will force the use of a hostname. Option 2 will use whatever the hostname of the system is set to, and if you change hostname this configuration will be automatically changed. Option 3 lets you set a hostname to whatever you want, it won't be changed regardless of external changes. If anything in your environment changes, you will manually have to change using option 3.

As an example lets select option 2. Here's how that will look:

% telnet files.liquidftest.com 80
Trying 172.16.5.251...
Connected to files.liquidftest.com.
Escape character is '^]'.
HEAD /images HTTP/1.0 HTTP/1.1 301 Moved Permanently Server: nginx Date: Fri, 17 Jul 2015 08:10:17 GMT Content-Type: text/html Content-Length: 178 Location: http://files.liquidftest.com/images/ Connection: close

This is good, we are no longer "leaking" information. Where this can become a problem is like this:

% telnet files.liquidftest.com 80
Trying 172.16.5.251...
Connected to files.liquidftest.com.
Escape character is '^]'.
HEAD http://other.host.com/images HTTP/1.0 HTTP/1.1 301 Moved Permanently Server: nginx Date: Fri, 17 Jul 2015 08:10:17 GMT Content-Type: text/html Content-Length: 178 Location: http://files.liquidftest.com/images/ Connection: close

As you can see, the system is now no longer paying any attention to the hostname that we sent in the request, with this configuration it doesn't matter what ip address or hostname you typed to get to the LiquidFiles system, you will be redirected using the hostname we configured. In a carefully configured production environment, this shouldn't be an issue, and if for some reason the hostname can't be used, it can definitely cause issues connecting to the LiquidFiles system.