PCI Compliance Scan & Globalscape EFT Web App Cookies Not Marked Secure

Question

I have a situation where we are performing external PCI compliance scans against our Globalscape EFT server. The scan is reporting:

HTTP (443/tcp) - Web Application Cookies Not Marked Secure

Per our external PCI compliance vendor:

The cookies that need to be addressed are passchangesession and loginsession which are found in the Details section to the left of the Exception Request tab. For each, we need the following information: The name of the cookie detected A description of what the detected cookie's purpose is (e.g., load balancing, third-party tracking) If the cookies are session cookies, then the secure flag needs to be set and a rescan done to demonstrate this change.

Cookies in question:

Name : passchangesession 

Name : loginsession 

I have confirmed they are session cookies. But Globalscape has not provided a solution on how to set the secure flag. All EFT traffic is also restricted to TLS 1.2 HTTPS and we deny HTTP. But this is not an acceptable compensating control, or invalid finding per vendor.

Globalscapes response was:

EFT Server does secure its session cookies when accessed over HTTPS (HTTP over SSL). What the scanner is picking up is a special case where the server is being accessed over plain-text HTTP, and EFT Server is redirecting the session temporarily over to HTTPS (to secure the login sequence), and subsequently (post login), back to HTTP. In the case of plain-text HTTP sessions, the secure flag should not be set for cookies. Please refer to the recommendations section below for more information.

Has anyone else been able to mitigate this and/or get an exception approved?

Answer 1

Not using the Secure flag on cookies is a critical security issue, regardless of whether the site is actually available over HTTP or not. A man-in-the-middle (MITM) network attacker can very easily steal them if they aren't flagged Secure:

1. Attacker finds a user who is logged into the target site.
2. Attacker waits for the user to browse to literally any site over unsecured HTTP (it doesn't need to be related to the target site in any way).
3. Attacker injects a simple, invisible element into the HTTP response that will trigger an HTTP request (for example, <script src="http://targetsite.com/"></script>, even though the root page is presumably not a script).
4. The user's browser will attempt to connect to the target site over HTTP, which the attacker can complete on the server's behalf (the server never even sees the request, so it doens't matter that it won't respond to HTTP requests).
5. The user's browser will send the request, including all non-Secure-flagged cookies for the vulnerable site; the attacker can easily harvest these.

For modern browsers, this attack could be thwarted by using HTTP Strict Transport Security (HSTS) or possibly the new SameSite flag on cookies, but a server that isn't using Secure on its session cookies probably isn't using any of these other security measures either, and in any case they wouldn't protect users with old browsers.

I checked Globalscape's knowledge base, and didn't see any way to require the Secure flag on the cookies universally. The scenario described, where the user is redirected from HTTP to HTTPS for login and then back to HTTP, is NOT secure and never should be allowed (Firesheep, a simple Firefox extension that automated attacks against such sites, was released nearly 8 years ago!)

If Globalscape is still allowing that behavior, it should be considered a serious security bug in their product, and your compliance vendor is absolutely correct that it's not suitable for use with payment card info. On the other hand, you claim that the EFT server is only accessible over HTTPS, in which case (per the company's claim) then the scanner shouldn't be able to trigger the "special case" where the cookies are sent insecurely.

Without more information (does EFT Server set the Secure flag if accessed over HTTPS? If so, why was the scanner able to get insecure cookies, given that you say the server isn't available over HTTP? If not, there may be no short-term fix), I can't really tell you what will be needed to fix the issue in the short term. In the long term, you need to either convince Globalscape to bring their web security into this decade, isolate it behind a front-end that is written with security in mind, or change vendors.