THE INFORMATION IN THIS ARTICLE APPLIES TO:

EFT, all versions

DISCUSSION

Fortra's customers often run third-party penetration tests on EFT. Below are answers to some of the penetration test results, which are either false positives, misconfiguration, addressed in newer versions, or simply misunderstanding of how EFT works.

1. EFT appears to allow unrestricted file uploads. What prevents people from uploading malicious files?
• The purpose of EFT, as with any Managed File Transfer (MFT) application, is to facilitate file transfers from authorized users. Risk mitigation controls include: access-level controls that control whether users can upload, download, or perform other CRUD operations on files; disk quota limits to avoid resource abuse; and ICAP integration for optionally analyzing uploaded files for malware, viruses, or unauthorized data (via integration with DLP devices). EFT also provides the ability to specify banned file types (by extensions), and controls that can limit the number of connections, bandwidth utilized, and more.
2. It appears that certain headers are missing, such as X-FRAME-OPTIONS header and/or CSP headers. Is this a Clickjacking vulnerability?
• In addition to frame-busting code, two HTTP headers should be employed to protect against clickjacking. The X-FRAME-OPTIONS header supports options that help protect against clickjacking. The "DENY" option prevents supporting browsers from rendering the page if it resides inside any iframe. The "SAMEORIGIN" option prevents browsers from rendering the page in an iframe on all pages hosted outside the framed page's domain. The Content-Security-Policy header, which specifies whitelists of trusted content that the browser may load along with page content, can be set to prevent a page from being framed using the "frame-ancestors" option “Content-Security-Policy: frame-ancestors 'none'. EFT v7.4.11 and later provide full control over CSP headers and sends them by default. (To configure, refer to Specify CSP to Pass Security Web Scans.) EFT supplies the X-FRAME-OPTIONS (DENY and SAMEORIGIN) in all response except the root page, as navigating to root results in a redirect to /login, which does include that header.
3. Is EFT’s web app using a vulnerable version of the Jquery library?
• EFT uses the latest libraries for the particular track of Jquery leveraged by the web client (as there are multiple version tracks). Furthermore, EFT’s web client does not leverage the handful of methods exposed by the library that are deemed vulnerable.
  (jQuery was removed from EFT in v8.0.5.7.)
4. Does EFT support HSTS?
• This feature is available as of 7.4.10 and is enabled by default in v7.4.13 and later. To enable HSTS, you must first enable HTTPS and the HTTP->HTTPS redirect feature under Site>Connection settings. In an upcoming version, HSTS only requires that HTTPS be enabled (it is decoupled from the HTTP->HTTPS redirect feature). Note that HSTS is only ever sent when either an HTTPS connection is made directly by a client, or the client attempted to connect over HTTP and EFT’s HTTP->HTTPS redirect feature is enabled. When HSTS is enabled, EFT sends a special response header "Strict-Transport-Security" to the client with a duration of time specified (the default, which is set to 15 minutes by default in 7.4.10, changed to 1 year in an upcoming version, configurable by the EFT admin). Once a supported browser receives this header, that browser records this setting and will only make requests to the application over HTTPS for the duration of time specified in the header, even if the user types in “http:”, without the “s”. Any links to resources over HTTP will be redirected to HTTPS before the request is made. Applications that do not use the "HTTP Strict-Transport Security" policy are more susceptible to man-in-the-middle attacks via SSL stripping, which occurs when an attacker transparently downgrades a victim's communication with the server from HTTPS to HTTP. Once this is accomplished, the attacker will gain the ability to view and potentially modify the victim's traffic, exposing sensitive information and gaining access to unauthorized functionality
5. When analyzing the secure connection, it appears that TLS v1.0 is in use. Isn’t that insecure?
• TLSv1 is disabled by default.
• TLSv1.2 is enabled by default in v8.x and later.
• EFT can be configured to use TLSv1, v1.1, 1.2, or v1.3.
• As of EFT 8.0.6, EFT supports TLSv1.3.
• As of EFT 8.2.1, EFT also supports TLSv1.3 for FIPS mode.
6. The path attribute of the session cookie is set to "/". Isn’t that overly broad?
• This is by design, as all resources under "/" are meant to be accessible to users, depending on the ACLs of that user or their inherited permissions group. Keep in mind that EFT is a file transfer server app, not a SaaS app where restricting resources under the domain would normally apply.
7. After I authenticate, if I close my browser or browser tab, then re-open my browser and navigate back to my same path, it appears I’m still authenticated. Shouldn’t closing my browser kill the active session?
• The only guaranteed method of killing a session is to log off (upper right corner in the web client). If you close your browser then the session will expire naturally (set to 5 minutes by default, admin configurable). The reason why closing your browser doesn’t kill the session boils down to the fact that when the browser is exiting, its priority is to exit, without much care for what each open app (in each tab) wants. This behavior is common, whether it be an online file sharing app, your bank, or any other secure sites. As such, you should always instruct your users to log-off manually, or for further risk mitigation, set the session timeout value to a shorter timeframe. We do have an optional, experimental feature that attempts to kill the session on tab or browser unload, but the usability side effects are pretty bad (such as Refresh page results in log-off). Contact support if you want more details on that override.
8. Does EFT provide any sort of protection against cross-site request forgery?
• Yes. EFT supports an anti-CSRF technique called double-cookie submit, where a CRSF token is sent with each request in a header (or in the URL in some cases) and in a cookie, which mitigates against common CSRF style of attacks.
9. It appears the token cookie is not set to HttpOnly. Doesn’t this create a vulnerability where the cookie can be read by Javascript?
• EFT designates the web session cookie, which is the authentication cookie, as HttpOnly. What you are seeing is the CRSF token cookie. It is not marked as HttpOnly because the web client needs to read in this value so that it can pass the token along to EFT when requesting resources. There are plenty of resources online that explain why making the CSRF token HttpOnly is completely unnecessary.