Frequent Responses after security reviews
It's common that security reviews pick up some of these things. Here are some standard responses to them:
The autocomplete=off function used to hint to a browser that it should not allow the password to be saved in the browser. Since 2015, this function has been disabled in all modern web browsers and regardless if this is configured or not, the browser will still save the users password in the local password store.
Please see this article for more information: Disable Password Autocomplete FAQ
Nothing gets security debate going more than discussing password complexity requirements. If you disagree with the default password complexity requirements, you can configure your own. If you have fairly simple requirements that can be fullfilled with a regular expression, you can follow the instructions at the Password Policy page. If you have more complex requirements that are not easily fullfilled with a regular expression, you can follow the instructions here: Advanced custom password validation with external script.
Checking of Filetype by file extension only
It is relatively easy to circumvent the file type checking by renaming the file. If you block say .exe files, anyone can rename the .exe file and bypass this check. When this gets picked up in a security audit the suggestion is generally to implement checking using content-type instead. The problem is that for the most part, we don't know content-types of the top of our minds making it difficult to edit, and things like .pif and .exe often have the same content-type (application/octet-stream) and we could want to enable one but not the other. And if someone really wants to send the file, they can in almost all cases just zip the file instead in an encrypted zip file we couldn't scan and so on. The current simple check stops most people from doing the wrong thing. If you want to implement a more stringent check, please see this article: Custom file scanning
Too nice error messages
Often auditors feel that the error messages in LiquidFiles are too nice and should be more generic, like displaying just "error" regardless what the problem was. You can change any user visible string, including error messages, in Admin → Locales if you wish to display less helpful error messages to your users if you believe this will make your system more secure.
HTTPs protocols and encryption algorithms
By default, LiquidFiles has enabled TLSv1, TLSv1.1 and TLSv1.2 encryption protocols and medium strength encryption algorithms for maximum compatibility (down to Internet Explorer 8). You can change this to TLSv1.2 in Admin → System → Network if you want. Setting TLSv1.2 only will also only enable strong encryption algorithms with the drawback that only Internet Explorer 11 and newer will be able to connect.
Leaking Internal IP Address information
On default, LiquidFiles permits that you connect to it using anything you configure in DNS, a local host file, ip address or whatever. This configuration is very flexible but has the unfortunate side effect that LiquidFiles can reveal it's ip address. Some security auditors wants us to belive that this is a major problem but in reality there's very little that can be done with this information on it's own. You can change the LiquidFiles configuration if you want. Please see: Web server redirect configuration for more information.
False Positive (at least as far as the attack is concerned). There's TCP performance enhancement that's outlined in RFC1323 that has been enabled by default in CentOS 7, the underlying operating system of LiquidFiles. It uses a TCP timestamp to calculate round-trip times and uses that for enhanced performance in TCP. What the attack outlines is by using the value of the TCP timestamp, it can determine when the system was last rebooted and use that to figure out if there's been any kernel vulnerabilities that's been discovered since the system was rebooted and could possibly be exploited on the target system. But in the RedHat/CentOS default implementation, the timestamp is based on a randomized offset and cannot be used to determine the uptime of the LiquidFiles system. Feel free to ignore.
The secure cookie flag is a flag that you can set on a cookie if it's only supposed to be sent back to the website if transmitted of https. If you configure LiquidFiles to use the protocol Force HTTPs in Admin → System → Network (this is the default), the secure cookie flag will be set.
If you're using a reverse proxy and use http between the proxy and LiquidFiles, you will need to configure the secure cookie flag in the reverse proxy. Please see the Reverse Proxy configuration for more information.
HSTS is a function that will tell the browser that on subequent requests, it should only be allowed to use HTTPs. If you configure LiquidFiles to use the protocol Force HTTPs in Admin → System → Network (this is the default), HSTS will be configured as per the recommended standard.
If you're using a reverse proxy and use http between the proxy and LiquidFiles, you will need to configure HSTS in the reverse proxy. Please see the Reverse Proxy configuration for more information about reverse proxies and the HSTS guide for more information about HSTS.