When developing applications, you should always ask yourself: “Is my product secure?”
Security headers are an essential ingredient to include while developing applications; you could liken them to salt in a meal. To understand what security headers are, however, we must first navigate the maze of HTTP headers…
Disclaimer – pretty technical stuff lies beyond this point.
Simply put, HTTP headers are key and value pairs that enable the client and server to send supplementary information alongside a request or response. They’re used to instruct a server or a browser on how it should behave and what features are supported.
Security headers are HTTP headers with specific configurations that bolster the security of applications. They are usually categorized as either request or response headers; sometimes both.
Security headers in an HTTP request on Amazon
Structure of a security header
The first part of a security header is the name or key, usually the name of the specific header in use. The last part of the security header is the value that defines a specific configuration(s). The key and value are separated by a colon when sent in HTTP requests and responses.
Strict-Transport-Security: max-age=2300; includeSubDomainsThe structure of a security header
The security header in use above is Strict-Transport-Security, which is the key followed by a colon. The configurations applied are max-age and includeSubDomains, which are separated by the semi-colon.
Strict-Transport-Security is a response header that tells a browser a website can only be browsed using an HTTPS connection (encrypted). If any attempt is made to use an HTTP connection (unencrypted), the connection will be changed into an HTTPS connection instead.
The max-age value states that the HTTPS connection (encrypted) should subsist for 2300 seconds; approximately 38 minutes. The includeSubDomains value specifies that subdomains are included.
Applying this header to a banking application, for example, reduces the risk of customers being affected by a man-in-the-middle attack. An attacker would not be able to intercept the connection as it would be encrypted, preventing sensitive data from being exposed.
Common security headers
The good news is that there are various security headers available. The bad news, however, is that not all browsers support them. The site Can I Use is a good tool for verifying this.
Some common security headers include:
- Content Security Policy (CSP) – a powerful header, beneficial for mitigating the risks of injection and cross-site scripting (XSS) attacks when configured correctly.
- Cross-Origin Resource Sharing (CORS) – controls the permissions on what resources can be shared and the domains allowed.
- Strict-Transport-Security (HSTS) – an essential header that helps to ensure the security of your request and response connection.
- Set-Cookie – a response header that isn’t a security header in itself but possesses security elements. It can be used to regulate the directives around what should be sent to the server alongside user cookies. It can be effective against cross-site request forgery attacks when implemented correctly.
Demo
Rather than simply stating the importance of security headers, it would be better to show you. In this demo, we’ll look at how a CSP header can be used to avert an XSS attack using a simple TODO list application.
First attempt
The TODO List application
This is a simple TODO List application – no CSP header has been implemented.
The exploit
The XSS payload has been prepared using a script tag and placed in the form. The Add button has then been selected.
The attack
The attack has been executed on the application, changing the background color from white to teal.
In reality, an attacker could do more than just change the background color of an application. They could possibly execute stored XSS attacks to target every user that visits the site, compromise user accounts, and expose user data. The attacker could even take over the entire application!
Let’s look at what happens when we try to execute the same attack as before, but with a CSP header in place.
Second attempt
CSP header in place
Same payload as before
End result
The payload no longer executes despite the page being vulnerable to XSS. Instead, it shows a blank entry on the TODO List and an error on the console in the browser developer tools.
Behind the magic
Now, onto why security headers are so important – magical, in fact. Although there are no spells involved (sorry, Harry Potter fans), security headers require no installation, infrastructure, or hardware, and are entirely cost free.
Security headers can be used to prevent mainstream attacks against end-users and supply chains, such as data injection, man-in-the-middle, cache-poisoning, and data leakage, and avert state-sponsored disinformation campaigns. This is not a conspiracy theory, I assure you.
In 2011, in the wake of the Arab Spring movement, the Syrian government executed a man-in-the-middle attack via an HTTP connection on Facebook. This allowed it to track pro-rebel group supporters and even censor their accounts. This attack could have been avoided if the Strict-Transport-Security header had been added to the site.
Once you have security headers up and running on your application, you can use the site securityheaders.com to analyze their security level.
Epilogue
There’s no such thing as being too prepared when it comes to cybersecurity. This is the essence of a defense-in-depth approach, which we encourage at Immersive Labs.
Now that you’ve been introduced to the wonderful world of security headers, we suggest you check out our associated series to learn more about the best types to use and how to correctly configure them. Make haste, my friend, for the attackers are lurking!
