logo NTT APPSEC
Web Application Security

HTTP Strict Transport Security

What is it and why should I care?

HTTP Strict Transport Security (HSTS) is a new(ish) technology 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.

Here are the basic steps of the flow:

Step 1: A user visits the application, either over HTTP or HTTPS. For most users this will be HTTP, because they often forget (or don’t know) to type in https://

Step 2: The application renders the response, including the HSTS response header, which specifies that the site should be loaded over HTTPS for only the next 90 days

Step 3: The supporting browser will not issue a non-SSL request to that application for the next 90 days

What should I do about it?

Set the header! This is another no-brainer. There are no backwards-compatibility issues, and setting the header only enhances your security posture. By adding the header, you give your users greater security with very little effort on your part. Here’s a quick example of what setting the header might look like if you happen to code in Java:

HttpServletResponse …;

response.setHeader(“Strict-Transport-Security”, “max-age=7776000; includeSubdomains”);

The snippet above sets the amount of time that the browser should use only HTTPS when accessing the application (or any subdomains) to the next 90 days.

max-age

The max-age attribute is required, and it sets the number of seconds that only HTTPS should be used. This can be set to whatever length of time you want. Setting this to “0” tells the browser to delete the existing policy and, therefore, not to require HTTPS.

includeSubdomains

The includeSubdomains attribute is optional. It does not take a value; its presence signifies that any sub-domains should abide by the same HSTS policy.

Expiration Reset

The time length (90 days in our example above) should be reset (overwritten) by the supporting browser every time the HSTS response header is received. This means that if you set the length to 90 days, and visitors never go more than 90 days without entering your site, they’ll always be visiting over HTTPS because the 90 days re-sets every time they visit. Just keep in mind that if you change the setting, all browsers that access your site (post-change) will get the update. If you set the expiration for 90 days today, and then for 10 days tomorrow, the browsers will discard the 90-day setting and replaces it with the new one of 10 days.

Click-Through Insecurity

The HSTS spec also recommends (though the current spec doesn’t seem to require it) that the browser not send any data to the server if the channel is insecure for any reason (certificate issues, domain issues, etc.). Apparently, current browser implementers are following this recommendation because it is the most secure option. This means that the warning pop-ups that users often see over HTTPS connections (mixed content, expired cert) no longer appear and, instead, users simply see an error.

Pre-Loaded HSTS Lists

If you want to have even more assurance that your site is visited only over HTTPS, you can request that your site be pre-loaded into a list of HSTS sites. This means that the browser will require users to go that site over HTTPS on their very first visit!

HSTS is a simple and effective control that lets an application provide users with further protection by forcing them over HTTPS. If your site is (or it at least should be) HTTPS-only, then implementing HSTS can provide you and your users with enhanced assurance.

References

_________________

http://hacks.mozilla.org/2010/08/firefox-4-http-strict-transport-security-force-https/

http://dev.chromium.org/sts

http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec

http://michael-coates.blogspot.com/2011/07/enhancing-secure-communications-with.html

http://www.troyhunt.com/2011/11/owasp-top-10-for-net-developers-part-9.html