This is based on an email I send my .NET team at work
Today I want to talk about some of the new HTTP headers you can set to help protect your users from various online attacks.
securityheaders.io is a really interesting site that scans a domain and reports on the HTTP headers it sets related to security. For example, here’s the scan for facebook.com: https://securityheaders.io/?q=https%3A%2F%2Fwww.facebook.com%2F
For each of the headers it finds, it includes links to detailed information about what the header does and how it protects your users. I think anytime we deploy a site for a client, we should strongly consider spending a little bit of time setting up the relevant headers. Most of the time we could accomplish that through a little ASP.NET HTTP Module that slipped the right headers into the Response object.
But I want to talk about some of these that I think are interesting.
The X-Frame-Options header
tells the browser how your site can be
iframed. In a lot of cases, you
would prefer it never be iframed as this can allow attackers to perform
against your users. You can also, if needed, specify that your site can
only be iframed into sites you trust.
The Content-Security-Policy header tells the browser what its allowed to do with embedded or referenced content. This can be used to protect against cross site scripting attacks (XSS) where an attacker is able to embed their own malicious content into your site (perhaps through a comments feature for example).
There’s a ton of policies you can tweak with this header. You can
specify from which domains the browser is allowed to load scripts,
images, styles and other media. You can restrict
attributes. You can even give it a URL where the browser will report
violations so you can further refine your policy.
These options make it so that even if your site is vulnerable to XSS, there is a limit to the types of things the attacker can accomplish with the vulnerability
The Strict-Transport-Security header tells your browser to never, ever, under any circumstances, connect to your site using HTTP : It must always use HTTPS. The concept is also known as HTTP Strict Transport Security (HSTS).
This protects against an attack by a Man in the Middle (MiTM) where the
attacker sits between your user and your site, and proxies the data. The
issue is that by default browsers initialize an HTTP connection. When
you just type
mybank.com into your browsers URL bar, it defaults to an
HTTP connection. But since the bank wants you to be secure, it issues a
301 Redirect Permanently header and tells you to come back using
HTTPS. The MiTM, though, can strip that header out on the way back to
your browser, while maintaining the secure connection with the server:
You <==== HTTP ====> MiTM <==== HTTPS ====> Bank
Both you and the bank are none the wiser.
Without this header, the only defense is the vigilance of the user: they would need to notice that there is no green lock on their URL bar. Most non-technical users are not inclined to be this attentive.
Strict-Transport-Security header works in conjunction with that
301 redirect and tells the browser to never again connect
Now there is still a hole in this: if the MiTM is in place during that
first initial connection, they can easily strip out the HSTS header
along with the redirect. However, the use of the
Strict-Transport- Security header helps greatly reduce the exposure to the MiTM: the only
way the attack can work is to be in place during the first connection.
To combat that attack, there is another extension called HSTS preloading. This is a browser feature where the software ships with a pre-existing list of sites to which it should never connect using HTTP. You can submit your site to the preload list using https://hstspreload.appspot.com/ and if accepted, the next versions of all the major browsers will add your site to their list.
For example, here’s the list for Chrome: https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json
Lets do our best to keep our clients and our users secure.