SecurID^® Discussions

ToddBrown · ‎2016-11-28

We just had a pen test performed which identified the missing header Strict-Transport-Security as an issue. How do we add this to our web-tier presence?

The application did not make use of the Strict-Transport-Security header to prevent SSL-stripping attacks.

Users may be victim to SSL-stripping man-in-the-middle attacks, causing session details and potentially sensitive
information to be sent over the network in cleartext. Client network traffic may also be potentially manipulated. In
order to exploit this flaw, an attacker would likely need to be able to intercept network traffic between a client and
server.

Since the world wide web consists of a mix of HTTP and HTTPS sites, it is often easy for attackers to conduct man-inthe-
middle downgrade attacks whenever users transition from an unencrypted (HTTP) site to an encrypted (HTTPS)
site. In these attacks, references from an HTTP site to an HTTPS are replaced with HTTP links. From there, an
attacker can intercept and translate requests to and from HTTP and HTTPS and provide users with little indication
that their traffic is being intercepted. A tool which implements many forms of this attack is sslstrip SSLStrip
[SSLSb].

In order to mitigate these attacks, the IETF the Strict-Transport-Security header HTTP Strict Transport
Security [HSTS], which instructs browsers to cache information about a site's SSL/TLS support. Once cached,
browsers which implement support for this header will refuse to access the site over unencrypted links in the future
(until a predefined time-out).

Reproduction:
The following response headers demonstrate the lack of the Strict-Transport-Security header:

curl -ki https://xxx.xxx.xxx.xxx/console-selfservice/

HTTP/1.1 200 OK
Cache-Control: no-cache
Date: Tue, 01 Nov 2016 15:54:36 GMT
Pragma: No-cache
Transfer-Encoding: chunked
Content-Type: text/html;charset=UTF-8
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: console-selfservicejsessionid=
K2yWYY6cZZQlnvn5hHjVTq1NvSnf6Sy1hTh32T2LnYGR2n73Vj3t!-1655169621;
path=/console-selfservice; secure; HttpOnly
X-Powered-By: Servlet/3.0 JSP/2.2
X-Frame-Options: SAMEORIGIN

EdwardDavis · ‎2016-11-28

We do not have a way to implement this at this time.

This is not an actual exploitable vulnerability with HSTS and RSA Authentication Manager web services.

In case of Authentication Manager we do not use HTTP anywhere in the system, so even enabling HSTS should not make any difference.

HSTS is about ensuring HTTPS is used for web browser connections, and RSA Authentication Manager forces this to be true by default.

Adding HSTS response headers will not change much in this regard.

The RSA Authentication Manager web applications, if they allow http at all, redirect immediately to https. Therefore, any advantage of implementing HSTS in its current state and format will not change the possibility that the first packet is http, therefore it is reasonable to say that there is no added risk on the RSA Authentication Manager Web Tier servers to not deploying HSTS that would be removed by implementing or enforcing it.

RFE AM-30255 was created to assess this vulnerability, and it was shown that lacking HSTS does not affect

RSA Authentication Manager and neither removes or increases risk.

HTTP Strict Transport Security (HSTS) is a new(ish) technology (2012) that allows an application to force browsers to use only SSL/TLS (HTTPS, not HTTP) when they visit that application. This occurs when the application sets an HSTS-specific HTTP response header. Browsers that support HSTS recognize the response header and only communicate with that application over HTTPS for the specified time.

View solution in original post

EdwardDavis · ‎2016-11-28