KB Article #176715

HttpOnly flag is not set on the JSESSIONID cookie for /admin portion of the UI

Problem

HttpOnly is an additional flag included in a Set-Cookie HTTP protocol response header. If supported by the browser, using the HttpOnly flag when generating a cookie helps mitigate the risk of client side script accessing the protected cookie. If a browser that supports HttpOnly detects a cookie containing the HttpOnly flag, and client side script code attempts to read the cookie, the browser returns an empty string as the result.

In versions 5.4 - 5.4.1 of MailGate, the HttpOnly flag is set on both cookies for the end-user UI (/enduser portion of the UI) - JSESSIONID and  ta. However,  for the Admin UI (/admin portion of the UI) the flag is only set for the ta cookie and not for the JSESSIONID. This will most likely cause any potential vulnerability scans against MailGate to report back a "Missing HttpOnly Flag From Cookie (http-cookie-http-only-flag)" vulnerability.

Given that the only plausible attack vector includes a successful Cross-Site Scripting (XSS) attack and access to the Admin UI (which is limited to administrators only), exploiting this flaw would be extremely difficult and a successful exploit has never been reported against MailGate. However, the lack of the flag may still cause security concerns in large enterprise structures, as it affects a business-critical application. Axway plans to implement a code fix in the next major release of MailGate. Until then, should the lack of the cookie causes any security concerns, administrators should follow the approach, outlined below, in order to secure their systems.

Resolution

1. Since the only possible attack vector includes a successful XSS attack, administrators should enable the "Cross-Site Request Forgery Protection" (CSRF) under Administration > Security > Cross-Site Request Forgery Protection.

CSRF attacks are different in nature than XSS. The first exploits the fact that the system trusts the user, while in the case with XSS is vice-versa. However, this protection can still secure the system against a cookie exploit: in the event of JSESSIONID cookie being compromised, the system should prevent authentication due to the lack of the ta cookie, which does have the HttpOnly flag set and furthermore, MailGate is configured to not accept authentication when the CSRF protection is ON and the cookie is either not sent or invalid.

2. To further prevent malicious parties from accessing the system, compromising the cookies, brute-force attempts or attempting to reuse stolen data, administrators are advised to contact Axway Global Support and request for the access to the /admin portion to be restricted to a set of trusted, internal IP addresses only. This option is not exposed in the Admin UI, so the setting will need to be implemented by Axway Global Support via the "Remote Support" mode.

3. The HttpOnly flag is not relevant to whether HTTP or HTTPS connection is used - if an attack is successfully carried out, it can be exploited regardless of the security of the connection (or the lack thereof). To further secure the system against the aforementioned XSS attacks, therefore making the exploit of the HttpOnly flag being missing extremely difficult (or impossible), administrators are highly encouraged to ensure that plain-text HTTP connections to the Admin UI are not allowed and always forwarded to the secure HTTPS protocol. This can be set under Administration > Security > Web Options > Forward Port 80 HTTP Requests to Port 443 HTTPS.


More information:
https://www.owasp.org/index.php/HttpOnly
http://resources.infosecinstitute.com/securing-cookies-httponly-secure-flags/

Still need help?

If this information wasn't helpful to you, just drop us a line. We'll get back to you as soon as possible.