Web communications can be routed over the Hypertext Transfer Protocol (HTTP) and the Hypertext Transfer Protocol Secure (HTTPS). The latter ensures encrypted data transfer between a website and a user. Some sites will offer both HTTP and HTTPS connections, but any HTTP connection may be vulnerable to cyber attacks. To require that all connections route over HTTPS, you can set up an HTTPS Strict Transport Policy (HSTS) to enforce secure connections.
This article includes a brief description of HSTS, documentation on the HSTS risk exposures that UpGuard identifies, and concrete actions you can take to resolve your HSTS risk findings.
What is HSTS (HTTPS Strict Transport Security)?
Ensuring HTTPS connections is the preferred method for web security and protecting sensitive data transfer. HTTPS Strict Transport Security (HSTS) requires all connections over HTTPS, which means that you can be confident that your users' data is secure when connecting to your website. The Internet Engineering Task Force (IETF) defined the standards for HTTPS Strict Transport Security in a 2012 document, RFC-6797.
Rerouting traffic to HTTPS through an HSTS configuration is not the same as running a 301 redirect. The [.rt-script]301[.rt-script] response to a redirect, which provides a [.rt-script]Moved Permanently[.rt-script] message, serves a website that can still be intercepted by a malicious attacker through a man-in-the-middle attack (MITM) because the initial connection was over HTTP. The first request with an HTTP connection would not validate that the server is authentic, which an HTTPS connection does through SSL certificates as part of the TLS handshake. Your site could then be vulnerable to a variety of MITM or downgrade attacks, including SSL stripping and cookie hijacking.
Your security policies should include assessing how your users will access your website. Encrypted traffic is the web standard, so it is important to set up HTTPS policies and force all HTTP traffic to route over a more secure method. You can protect your users' credentials and other sensitive information by enforcing a strict HTTPS policy. It is possible, however, that you may forget to disallow HTTP connections and not notice it for some time. Identifying your HSTS-related risk exposure will help you respond proactively to prevent attacks on unsecured HTTP connections.
Common HSTS Risk Findings
If you have not yet set up HSTS for your assets or you are unsure if you have configured your HSTS policy properly, you can scan your assets with a continuous monitoring tool like UpGuard BreachSight to help you identify if your assets are using HTTPS or if they still allow traffic over HTTP.
In addition to common issues with HTTPS setup, UpGuard also scans for HSTS configuration issues and informs users of the following risks:
- HTTP Strict Transport Security (HSTS) not enforced
- HSTS header does not contain includeSubDomains
- Domain was not found on the HSTS preload list
HTTP Strict Transport Security (HSTS) ensures that all client connections use HTTPS, which maintains encryption at all times. If you have not set up HSTS, you will receive the HTTP Strict Transport Security (HSTS) not enforced finding for your domain. Sometimes an old link may be overlooked or your users may have bookmarked an old URL that uses HTTP connection, which can mean that the risk of data interception would remain on your site. Enforcing HSTS by setting the necessary HSTS response header ensures that any lingering HTTP links that might serve an HTTP request will automatically be routed to the HTTPS version of your site.
The [.rt-script]includeSubDomains[.rt-script] directive enforces HSTS across all subdomains of your domain. For example, if your organization's blog is held on a subdomain, such as [.rt-script]blog.your_domain.com[.rt-script], this directive would ensure that all access to the blog routes over HTTPS only. If the [.rt-script]includeSubdomains[.rt-script] directive is not specified, subdomains will not be required to use HTTPS. While your main website would be secured, any resources in subdomains would be vulnerable to attacks because the subdomains could establish unencrypted HTTP connections. In circumstances like this, UpGuard will notify you with the HSTS header does not contain includeSubDomains finding for your domain. You can then update your HTTP header with the requisite parameters for secured traffic.
Most common web browsers support HSTS, including Google Chrome (and Chromium-based browsers), Mozilla Firefox, Opera, Safari, Internet Explorer, and Microsoft Edge. When you enforce a strict HTTPS policy, browsers will ensure that any request is sent to the secure HTTPS version of your site. The HSTS preload list, maintained by the Chromium project, is a list of domains that are known to route over HTTPS only. The HSTS preload list has specific deployment recommendations, which you can set up for your site. To check if your domain has already been included in the HSTS preload, visit [.rt-script]https://hstspreload.org/[.rt-script] in your browser and enter your domain in the preload status search.
UpGuard's scanning will check if your domain is on the HSTS preload list. If your website adheres to the recommendations and has been added to the list, your domain will pass the HSTS check for that domain and its subdomains. However, if your domain is not available in the preload list, you will receive the Domain was not found on the HSTS preload list finding for that domain.
If you receive one of these findings for your website, you can take action to implement HTTPS Strict Transport Security and protect communications to and from your web application.
How to Resolve HSTS Risk Findings
To set up HSTS or repair an issue in your configuration, you can follow the guide in this section for implementing fixes to common HSTS issues. For a specific finding identified by UpGuard, navigate to that section heading.
You can do some quick research to gauge if your domains, nested subdomains, and other assets are routing over HTTPS:
- If you have few domains and subdomains, you can visit each in a browser to check if the secure padlock loads to indicate HTTPS connection.
- If you have many subdomains, run [.rt-script]curl -v https://your_domain[.rt-script] against each of your owned sites for any common patterns among subdomains that do not serve content over HTTPS.
- Use browser-based testing frameworks or web crawlers to ensure all links to resources, such as images or CSS files, are being offered and served over HTTPS.
You can also take specific actions to resolve each of the HSTS risk findings. Because the requirements to be included on the HSTS preload list will fulfill the requirements of the other checks that UpGuard conducts, we recommend adhering to the HSTS preload list recommendations as you set up your HSTS policy. Ensure that you have also established a process to monitor or audit the status of your HSTS setup on all internet-facing systems.
Resolving "HTTP Strict Transport Security (HSTS) not enforced"
Enable HSTS on your web server by including the [.rt-script]Strict-Transport-Security[.rt-script] header for the system. Add the [.rt-script]includeSubDomains[.rt-script] directive to ensure all subdomains use HTTPS and specify a duration for browsers to remember the HSTS policy:
[.rt-script]Strict-Transport-Security: max-age=63072000; includeSubDomains[.rt-script]
You can also enable HSTS for all HTTPS responses and stage increases to the [.rt-script]max-age[.rt-script] parameter so that you can review any issues during the duration you provide. The [.rt-script]max-age[.rt-script] value determines how long in seconds that a browser should remember to use HTTPS exclusively when accessing a site. During this time, you can check for broken pages and improper redirection, while also monitoring your site's metrics. We recommend testing this approach in your staging or development environment first. If you have the ability to serve your HSTS header to a subset of users in production, you can also do a beta analysis in production where you observe server logs for errors in real-time experience by users.
The [.rt-script]max-age[.rt-script] value is specified in seconds. To set testing durations, you can use the following headers:
- 5 minutes: [.rt-script]Strict-Transport-Security: max-age=300; includeSubDomains[.rt-script]
- 1 week: [.rt-script]Strict-Transport-Security: max-age=604800; includeSubDomains[.rt-script]
- 1 month: [.rt-script]Strict-Transport-Security: max-age=2592000; includeSubDomains[.rt-script]
When you have completed your testing duration, you should set the [.rt-script]max-age[.rt-script] value to at least one year ([.rt-script]31536000[.rt-script] seconds), though two years ([.rt-script]36072000[.rt-script] seconds) is recommended by the HSTS preload service.
You can optionally exclude the [.rt-script]includeSubDomains[.rt-script] parameter if you wish to focus on your primary domain exclusively. However, excluding this parameter will return the HSTS header does not contain includeSubDomains finding for your domain.
Resolving "HSTS header does not contain includeSubDomains"
The [.rt-script]includeSubDomains[.rt-script] parameter ensures that all subdomains associated with your domain name will route traffic over HTTPS. Add that directive to your HSTS header to resolve this issue.
The HSTS preload list requires HTTPS support for your entire site and all subdomains, so it is also a prerequisite for resolving the Domain was not found on the HSTS preload list finding.
Resolving "Domain was not found on the HSTS preload list"
You can follow the best practices for deploying HSTS and then submit your domain to the HSTS preload list. The preload list is included with most browsers and will automatically route connections to your domain over an encrypted channel.
To be accepted to the preload list, you will need to ensure you have the necessary prerequisites and satisfactory configuration parameters:
- Serve a valid SSL/TLS certificate.
- Ensure all port [.rt-script]80[.rt-script] listening on the same host redirects from HTTP to HTTPS.
- Support HTTPS for all subdomains, including the [.rt-script]www[.rt-script] subdomain if a DNS record exists for it.
- Serve an HSTS header with the necessary parameters on all requests to the base domain.
When you have satisfied the requirements, you can include the [.rt-script]preload[.rt-script] directive for your HSTS policy and request inclusion in the preload list:
[.rt-script]Strict-Transport-Security: max-age=63072000; includeSubDomains; preload[.rt-script]
The [.rt-script]preload[.rt-script] directive will create a request to be preloaded into the HSTS list for browser support with HSTS. You can request removal from this list if you have an issue that requires HTTP access, but removal is slow and may not reach all browsers that use the preload list.
How UpGuard Can Help
UpGuard BreachSight scans for a variety of risk exposures due to issues with HTTPS and HSTS configuration. If you receive any of these findings, our system identifies which of your owned assets are at risk so that you can update the configuration settings.
Current UpGuard users with the BreachSight feature can log in and access their Risk Profile to search for these risks among their assets.
If you're not a current UpGuard user and you want to scan your assets with BreachSight, sign up for a trial.
