This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "HTTP Strict Transport Security"
m (cleanup) |
(switching warning to recommend the use of includeSubDomains) |
||
Line 22: | Line 22: | ||
The `preload` flag indicates the site owner's consent to have their domain preloaded. The site owner still needs to then go and submit the domain to the list. | The `preload` flag indicates the site owner's consent to have their domain preloaded. The site owner still needs to then go and submit the domain to the list. | ||
− | == | + | == Always Use includeSubDomains == |
− | + | The lack of use of includeSubDomains can lead to a significant privacy leak[http://www.leviathansecurity.com/blog/the-double-edged-sword-of-hsts-persistence-and-privacy]. Be sure to use includeSubDomains on all wildcard certificates, at least. | |
− | |||
− | |||
== Browser Support == | == Browser Support == |
Revision as of 19:39, 8 July 2015
Description
HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers.
The specification has been released and published end of 2012 as RFC 6797 (HTTP Strict Transport Security (HSTS)) by the IETF. (Reference see in the links at the bottom.)
Examples
Simple example, using a long (1 year) max-age:
Strict-Transport-Security: max-age=31536000
If all present and future subdomains will be HTTPS:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Recommended: If the site owner would like their domain to be included in the HSTS preload list maintained by Chrome (and used by Firefox and Safari), then use:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
The `preload` flag indicates the site owner's consent to have their domain preloaded. The site owner still needs to then go and submit the domain to the list.
Always Use includeSubDomains
The lack of use of includeSubDomains can lead to a significant privacy leak[1]. Be sure to use includeSubDomains on all wildcard certificates, at least.
Browser Support
Browser |
Support Introduced |
Internet Explorer |
Internet Explorer 11 on Windows 8.1 and Windows 7[2] |
Firefox |
4 |
Opera |
12 |
Safari |
Mavericks (Mac OS X 10.9) |
Chrome |
4.0.211.0 |
A detailed overview of supporting browsers can be found at caniuse.com.
Server Side
The web server side needs to inject the HSTS header.
For HTTP sites on the same domain it is not recommended to add a HSTS header but to do a permanent redirect (301 status code) to the HTTPS site.
An Apache HTTPd example that will permanently redirect a URL to the identical URL with a HTTPS scheme, is as follows:
<VirtualHost *:80> ServerAlias * RewriteEngine On RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [redirect=301] </VirtualHost>
On the HTTPS site configuration the following is needed to add the header as recommended by the standard:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
The following links show how to set response headers in other web servers:
IIS
Whilst custom headers can be configured in IIS without any extensions, it is not possible to restrict these headers to secure transport channels as per the HSTS specification. This leaves the following options.
Custom Module
HSTS has been implemented, per the specification, as an open source IIS module.
URL Rewrite
Install Microsoft URL Rewrite and use following rewrite rules.
<configuration> <system.webServer> <rewrite> <rules> <rule name="HTTPS_301_Redirect" stopProcessing="true"> <match url="(.*)" /> <conditions> <add input="{HTTPS}" pattern="^OFF$" /> </conditions> <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" appendQueryString="false" redirectType="Permanent" /> </rule> </rules> <outboundRules> <rule name="Add_HSTS_Header" preCondition="USING_HTTPS" patternSyntax="Wildcard"> <match serverVariable="RESPONSE_Strict-Transport-Security" pattern="*" /> <action type="Rewrite" value="max-age=31536000" /> </rule> <preConditions> <preCondition name="USING_HTTPS"> <add input="{HTTPS}" pattern="^ON$" /> </preCondition> </preConditions> </outboundRules> </rewrite> </system.webServer> </configuration>
Threats
HSTS addresses the following threats:
- User bookmarks or manually types http://example.com and is subject to a man-in-the-middle attacker
- HSTS automatically redirects HTTP requests to HTTPS for the target domain
- Web application that is intended to be purely HTTPS inadvertently contains HTTP links or serves content over HTTP
- HSTS automatically redirects HTTP requests to HTTPS for the target domain
- A man-in-the-middle attacker attempts to intercept traffic from a victim user using an invalid certificate and hopes the user will accept the bad certificate
- HSTS does not allow a user to override the invalid certificate message