Frequent Responses after security reviews
Pretty much every single security review pick up a few of these things. Here are some standard responses to them:
The autocomplete=off is a function that will hint to a browser that it should not allow the password to be saved in the browser. The argument for allowing users to save the password is that by setting a stronger password that is saved in the browser, you'll actually use stronger passwords more often and it becomes much easier to use strong passwords that is different for each site, which makes web browsing in general more secure. The argument against saving passwords in the browser is that if someone gets local access to the machine, they will be able to authenticate as the user and send things on their behalf. This is a hint, meaning that it's up to the browser to honour this request and there are browser plugins available that will remove the autocomplete=off configuration when set so that the password can be saved regardless of what's shown on the site.
Please see this article on how to disable password automcomplete if you want it disabled: 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 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
This is another one where a lot of people have strong opinions. Security auditors generally want to enable on the very latest https protocols (TLS v1.2 as of this writing) and disable everything else. The problem in this case is that browser support is pretty poor. By default, Internet Explorer didn't enable support for TLS v1.1+ until Internet Explorer v11. Which means that with the current stance of supporting the last 2 browser versions for everything but IE, and the last 3 IE versions, we will have to keep TLS v1 support at least until Internet Explorer 13 is widely adopted (unless Microsoft back ports and default enables TLS v1.1+ in earlier browsers). The current configuration is:
- Protocol: TLSv1.2 TLSv1.1 TLSv1
- Encryption Algorithm: FIPS@STRENGTH:!RC4:!MD5:!EXPORT:!aNULL:!eNULL
This ensures maximum strength and compatibility for most browsers.
If you're running a closed internal system or can otherwise guarantee that internal and external users of the LiquidFiles system will not use Internet Explorer 10 or below (or other incompatible browsers), and you know how to configure a CentOS system, LiquidFiles uses the standard convention and you'll find the configuration file where you expect it to.
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. Since LiquidFiles can be configured to use both http and https, it's not possible to set the secure cookie flag for every scenario. However, if you configure your LiquidFiles system to Force HTTPS in Admin → Network, it will set the secure cookie flag.
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.