HTTP Strict Transport Security (HSTS) is an IETF specification to instruct web browsers to strengthen HTTPS requirements when connecting to a host. HSTS accomplishes this in two ways: 1. The web browser shall make all future requests to the given host over HTTPS. If content is included over insecure channels, or the user follows a direct link to an insecure channel, the browser will ensure only requests over HTTPS are made. This protects session tokens from being disclosed as well as the 2. Users cannot accept SSL warnings. Browsers supporting HSTS will not give users the ability to accept SSL warnings. If a user is the victim of a MITM attack, they will not be able to accept SSL warnings and continue to use the application. Below shows the error a user sees when an SSL warning is induced, no options so accept the error are presented:
The HSTS header takes the following form:
Strict-Transport-Security: max-age=31536000
The max-age parameter specifies the length of time the browser should enforce the policy. 31536000 is the maximum allowed value, which equates to one years’ time (in seconds). There are a few very important things to understand about the limitations of HSTS:
- HSTS is not a compensating control for having application functionality accessible over HTTP. Applications should still forcefully redirect users via 301/302 redirects to HTTPS URLs.
- HSTS cannot prevent a MITM attack on the first visit to a website. An attacker conducting a MITM attack on the initial connection can successfully man in the middle the victim if the very first plain text session is hijacked.
- HSTS can be issued over HTTPS only. Browsers will not observe any Strict-Transport-Security headers issued over plain text. Pentest service providers should raise issues surrounding HSTS similar to that of cookies missing http-only flags (ie. “Low Risk” or “Note”). One thing to keep in mind is that although this is an optional security enhancement, the current model of HTTP is far from ideal.
HSTS simply brings us a step closer to a secure trust model. So although this is an optional feature, it is highly recommended this is adopted for secure applications. Strict-Transport-Security is just one of many new headers developed in the recent years to combat increasing web attacks. Similar headers such as X-Frame-Options exist to prevent Clickjacking attacks, and X-XSS-Protection/CSP headers can in some cases protect against XSS attacks. It is more important than ever that security professionals understand the latest security web browser controls and ensure they are implemented where appropriate. In summary, below are the do’s and don’ts of using HTTP Strict-Transport-Security:
- Do use HSTS to secure return visits to your application.
- Do send your Strict-Transport-Security over HTTPS.
- Do use an appropriate ‘max-age’ value for return visits.
- Do NOT use HSTS as a replacement for server-side HTTPS enforcement.
- Do NOT expect HSTS will prevent a first contact MITM attack, The IETF RFC can be found at the following URL: