Frequent Responses after security reviews
It's common that security reviews pick up some of these things. Here are some standard responses to them:
Password Complexity
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 create a Password Validation ActionScript.
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 → System → Locales if you wish to display less helpful error messages to your users if you believe this will make your system more secure.
User Enumeration
When a user can't login, LiquidFiles will tell the user if the email doesn't exist or if the password is incorrect. This is obviously very helpful to a user that can't login to the system. If a brute-force scanner was permitted to send unlimited requests to the LiquidFiles system, it would be possible to enumerate (try every possible email address) to figure out if a user/email exists on the system or not, and use that information for some extended attack on that user somewhere else. But the scanner won't be permitted to do that.
LiquidFiles has a builtin Brute-Force Protection mechanism that on default will block the client for 15 minutes after 5 failed attempts within 5 minutes. You can adjust Brute Force Protection settings in Admin → System → Firewall and Brute Force Configuration. This means that in practice, it's not possible to enumarate email addresses in the way your scanner/auditor has highlighted and the audit result is therefore a false positive.
If you believe that not telling users if the email doesn't exist vs if their password is incorrect will make your system more secure and your organisation safer, you can adjust error messages in Admin → System → Locales (see also Too nice error messages above).
HTTPs protocols and encryption algorithms
By default, LiquidFiles has enabled TLSv1.2 and TLSv1.3 encryption protocols and strong encryption algorithms. You can change this to only TLSv1.3 in Admin → System → Network if you want, or add TLSv1.1 and TLS1.0 if you need a wider browser support.
We also recommend that you check your system using SSLabs SSL Test. With the default LiquidFiles configuration, you will receive an A+ status.
If you have configured LiquidFiles with the default TLSv1.2 and TLSv1.3 and your scan is showing something else, the most likely explanation is that you have (an insecurely configured) reverse proxy in front of LiquidFiles.
System Function Version Numbers
Fairly often we get requests like "our scan showed that function X has version Y and according to our report that means we're vulnerable to exploit Z".
LiquidFiles uses Ubuntu 22.04 LTS as it's base operating system. Any updates to any system packages is distributed directly by Ubuntu. We, as in LiquidFiles, does not manually patch system packages outside of what is distributed by Ubuntu.
In order to see if the system is vulnerable, you'll need to do is to look at specific CVE numbers in the Ubuntu CVE database.
If the specific CVE number is listed as not vulnerable and you've enabled automatic system updates then you're not vulnerable. In fact, if this is a new exploit then the only thing you can really do is to enable automatic system updates and as soon as Ubuntu releases a fixed version, it will be installed on your system.
A follow-up question is sometimes — can we manually install the latest version of OpenSSH/OpenSSL/ProFTPd/... and no, you cannot. If you attempt to manually install or patch installed versions of anything that's installed, your system will no longer be supported and you will almost certainly end up in a situation where you'll have to reinstall LiquidFiles to get back to a functional system.
Secure Cookie
The secure cookie flag is a flag that you can set on a cookie if it's only valid if transmitted over 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 still need to use Force HTTPs and use HTTPs between the Reverse Proxy and LiquidFiles. Please see the Reverse Proxy configuration for more information.
HSTS
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.
Please note though that if you're looking at a system with a demo license, the HSTS timeout will be set to 1 hour. This is so that you can see that the header is working, but in case you don't want to use HTTPs for some reason, there's not a long timeout HSTS header forcing you to HTTPs.
If you're using a reverse proxy and wish to use HSTS, you will still need to configure Force HTTPs in LiquidFiles and use HTTPs between the Reverse Proxy and LiquidFiles. Please see the Reverse Proxy configuration for more information about reverse proxies and the HSTS guide for more information about HSTS.
Strict-Transport-Security includeSubdomains
There's an optional includeSubdomains directive to the Strict-Transport-Security header. According to the documentation If this optional parameter is specified, this rule applies to all of the site's subdomains as well. LiquidFiles is a single web application within an organization. It is not the job of LiquidFiles to say that every single internal and external site within the domain should use HTTPS and have valid SSL certificates from now and through the lifetime of the domain. The reason why there's no setting to include this is that even most security professionals don't understand the implication of setting this, which is — can you guarantee that every single site in your domain will use HTTPS and has valid SSL certificates from now and as long as the domain is used? And while we're certainly heading in that direction, we're not really there yet. This is especially true for larger organizations with lots of legacy applications.
If you're dead set on including this, you will need to add a reverse proxy in front of LiquidFiles and in the reverse proxy you can rewrite this header.
There's also a preload directive that's not part of the specification. In order to enable this, you will need to follow guidelines and submit the site to the HSTS preloading service maintained by Google. Again, if this is important to you you will need to submit the LiquidFiles site and add a reverse proxy where you set this header.
Path Based/Extension Vulnerability
This is a false positive and just the way the LiquidFiles web application framework (Ruby on Rails) work.
Back in "the old days" of cgi-bin scripts and PHP and similar, there was a direct correlation between files in filesystem and the URL. So if you had a /login path, it meant that somewhere in the file system there was a login.pl/login.php or something file. The default setting in a lot of text editors is to save a .old or .bak version of files so some vulneraility scanners check for paths like /login.old and /login.bak and if there's something responding it highlights this as a potential vulnerabilty as someone may have left an old/backup version in the filesystem.
LiquidFiles uses a modern web application framework (Ruby on Rails) and there's no correlation between paths and files in the filesystem, i.e. just because there's a /login path it doesn't mean there's a login.rails file anywhere in the filesystem. With Ruby on Rails, if there's a /login path, you can try /login.old, /login.bak, /login.xxx, login.1234 or whatever you want, and it will render the /login action each time. This is just the way Ruby on Rails work so if your scanner is highlight this, it's a false positive and you can easily verify this by trying some other extensions as well and you'll see the exact same page being rendered each time.
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, you can implement a Attachment Upload ActionScript and Share Files Upload ActionScript for more in-depth validation according to your security guidelines.
Missing Function Level Access Control
False Positive.
As of 2023, OWASP has listed "Broken Access Control" as their number #1 Security Risk in the OWASP Top 10 vulnerabilities. When this happened we started getting reports of this vulnerability, using with the heading "Missing Function Level Access Control", specifically for the LiquidFiles paths /user/registration & /user/password_reset.
What the vulnerability claims is that these paths are vulnerable because they are not authenticated. But if you actually stop and think about it, it's not that they are not authenticated. It's that they cannot be authenticated. I.e. if the user knew their username and password, they wouldn't need to visit the password_reset URL so this URL cannot be authenticated. Same with registration. Before a user has registered their account, we cannot authenticate them.
Starting with v3.7.13, LiquidFiles have moved these URLs to /register & /password_reset that will hopefully stop these automated findings. In case your vulnerability scanner still show this up as a vulnerability, please report this as a false positive to your vulnerability scanner vendor.
TCP Timestamp
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 Ubuntu, 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 Ubuntu 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.
Password Autocomplete
False positive. The autocomplete=off function used to hint to a browser that it should not allow the password to be saved in the browser. This function was permanently disabled in browsers in about 2014 (Chrome v27, Firefox v7, Safari v7, Internet Explorer 11 and later versions will all remember passwords regardless of settings). I.e. even if you could set this setting it wouldn't work anyway.