March 31, 2020
Test services and applications that scan servers (usually Web servers) for vulnerabilities have been around for a while, but are increasingly used in practice. I've discussed them in the past, like here, in my SSL Vulnerabilities blog entry, but get questions about them a lot, so it's time to revisit the topic. In this update, we'll take a look at a number of specific test results, and how you can address them.
The HTTP Strict-Transport-Security response header (often abbreviated as HSTS) lets a web site tell browsers that it should only be accessed using HTTPS, instead of using HTTP. It's a useful tool that lets the browser know that the service should not be accessed by unencrypted means.
On Rumpus servers with HTTPS enabled and that should be accessed only by HTTPS, make sure that the "Enable HTTP Strict Trans. Security" option is enabled on the Network Settings window, Secure Services tab. This will cause Rumpus to include the header.
The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object>. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.
On Rumpus servers that should not be accessible via 3rd party frames, make sure that the "Prevent CLickjacking" option is enabled on the Web Settings window, Advanced tab. This will cause Rumpus to include the header.
Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. Use of this directive requires that you adopt a security policy, which may vary from organization to organization. For this reason, Rumpus does not currently offer a configuration option in the standard server UI. However, knowledgable administrators can specify a policy by including a directive the the Rumpus.conf configuration file.
The most common policy for Rumpus administrators is to allow content to be delivered to the browser only through the Rumpus server itself. In other words, on many servers, it is reasonable to disallow cross-site content altogether. In order to accomplish this, add the following line to your Rumpus.conf file:
CSPHeader "default-src 'self'"
The Cache-Control HTTP header holds instructions for caching in both requests and responses. In other words, the feature allows the server to indicate what content is relatively static (cacheable) and what content is dynamic (not cacheable).
For example, in the Rumpus interafce, you'll see images representing buttons, files, logos and more. These small images rarely, if ever, change and so are highly cacheable. A page displaying a directory listing, on the other hand, can change constantly, and so should never be cached.
Rumpus does an excellent job of recognizing what content is cacheable and what isn't, and marks each bit of content accordingly. However, Rumpus is a dynamic file server, not a typical Web server, so much more of the content delivered through Rumpus is not cacheable than a general purpose Web service. For this reason, some scanners may flag a Rumpus server as being too lenient with the Cache-Control header. Unfortunately, there is nothing to be done to eliminate the warning. Administrators simply need to understand that some tests designed to identify potential vulnerabilities in typical Web sites are not relevant for a file transfer server, even one that is implemented via HTTP/HTTPS.
The Cache-Control header is an excellent example of a feature that makes good sense for a typical Web server, but that isn't applicable to a file transfer server. Another good example is the "X-Content-Type-Options" header. This feature allows the server administrator to essentially make promises about how the server handles file content types. It essentially says "when I send you a file, I'll tell you it's type, and the browser should always process the file data accordingly."
On a typical Web server, the server administrator has control over all of the content, so making a promise like this makes sense and is worthwhile. But a file transfer server, by nature, contains content that is not directly posted by the site administrator. In fact, the whole point of a file transfer server is to allow outside users to send and receive files of virtually any type. Since Rumpus processes a range of different end user file types, it would be incorrect for the server to issue a directive restricting how various types of files should be processed.
Of course, in many settings, there is pressure to simply pass the security test. However, in cases like this, understand that Rumpus is not a traditional Web service. Rumpus implements a file transfer service via the Web (HTTP) protocol. Some traditional Web server behaviors, which are perfectly reasonable in a typical Web site, just can't be applied to a file transfer service like Rumpus.
I'll continue to update this page as new warning messages are reported, so if you have questions not covered above, please contact us at support@maxum.com and we'll do our best to stay up to date on the latest security scan reports.