Happy Safer Internet Day! We teamed up with anti-malware company Malwarebytes to provide web browser security tips for both workplace Internet users and web developers. If you’re an employee looking for best practices for web browsing at work, visit the Malwarebytes blog for their post on How to browse the Internet safely at work. If you’re looking for HTTP-header tips, let’s get to it.
As a website owner or web developer you can control which HTTP-headers your web server should send. The purpose of this article is to shine some light on the different response HTTP-headers that a web server can include in a request, and what impact they have on security for the web browser. Web developers can implement the following to make the user experience more secure:
X-Content-Options
The X-Content-Options header can only have one directive and that is nosniff. This header will tell the web browser that the MIME (indicated via the Content-Type header) for the requested content should be followed.
In the above image, we see a request to /uploads/not-an-image.png and because the server did not provide any Content-Type header which should indicate what the MIME of the document is, the web browser tried to guess based on the content. The content is HTML with Javascript in it and the browser, therefore, interpreted the content as such.
In the above image, we see the same request but the server included an X-Content-Type-Options header which told the web browser that it should not do a MIME sniffing on the document. In this case, the web browser user could be saved against an XSS attack.
X-XSS-Protection
This header tells the web browser that the built-in XSS protection should be enabled. In most modern web browsers, the XSS filter is enabled by default, but due to the headers ability to be disabled, enabled or enabled and block, the whole request it is still important to use depending on the website’s use case. The recommended value is 1; mode=block which means that the XSS filter should be enabled and the whole request will be blocked. Note that this is the default behaviour in Google Chrome even if the header is not explicitly set.
In the above image, we see that a request where malicious content is reflected in the document is blocked by Chrome.
If the server, for some reason, sets the X-XSS-Protection header to 0 this will disable the XSS Auditor. As a result, we see that the reflected malicious content was rendered.
If the server sets the X-XSS-Protection header to 1, the document will be loaded but the malicious content will just be removed and blocked (the red part). Other “non-malicious” content will not be blocked.
Note that the XSS Auditor is not a bulletproof XSS protection as there have been several bypasses, so it’s not recommended to rely on it.
Set-Cookie
The Set-Cookie header does exactly what it says; it sets a cookie. The header has a few attributes to keep in mind if the web application uses HTTP cookies for authentication.
HttpOnly: The HttpOnly attributes tells the web browser that the cookie should only be accessible through the HTTP request header, this means that the cookie can’t be accessed via Javascript. This attribute is very important to include because otherwise an XSS can be exploited to read the cookie and send it to the attacker who can then take over the session completely.
Secure: This attribute tells the web browser that the cookie should only be transmitted via a secure connection (valid HTTPS usually). This could protect a user if an attacker is listening in on the network to steal cookies.
SameSite: The SameSite attribute is rather new and provides excellent protection against CSRF attacks. If a cookie uses the SameSite attribute, the web browser will make sure that the request made with the cookie came from the origin that sat the cookie
__Host-and __Secure: cookie name prefix – This is not an attribute but a prefix for the cookie name. The reason why it is a prefix and not attribute is that if you change the cookie name, you will have to change the backend in order to accept the new cookie name. The benefit is that an attacker can’t add or remove attributes such as Secure or Path as they are required with a __Host- or __Secure- prefix.
To conclude: a perfect cookie should look something like:
Set-Cookie: __Host-user=admin; SameSite=Lax; Secure; Path=/; HttpOnly
Clear-Site-Data
The Clear-Site-Data is a new header with limited browser support, but can be useful on many web applications. The header has the ability to tell the web browser that cache, storage and cookies should be deleted for the origin that sent the header. One use case could be once a user logs out.
Referrer-Policy
Web servers previously defined the referrer policy via Content-Security-Policy but this has now been moved to a separate header. This header simply tells the web browser what the Referer header should include depending on the context. Web applications have a tendency to rely on the information in the Referer header, often in order to store data, for example validating that the request came from a specific URL or origin. Because of this, it is not uncommon for the web browser to include sensitive data in the URL.
This could also be a way to increase the integrity for the users of the website. For example, if a user reads a news article about cats and the article has a link to a cat shelter website, that website will see that the web browser came from that article.
Note for onion domains: a strict referrer-policy should be used in order to not share data across “dark web” and “clear net”.
Different directives can be used, read more about them on MDN.
Content-Security-Policy (CSP)
Content-Security-Policy is the most abstract header which makes it possible to fine-tune how different resources should be handled by the web browser. If configured correctly it can limit the attack surface greatly. It requires a higher understanding of the web application in order to utilize a policy that is both strict and does not block resources that it should not.
Google has a tool which makes it possible to evaluate a CSP in order to determine if it can be considered safe or not.
What about regular browser users?
As a browser user, there are steps you can take to make sure your web browsing at home and at work is a secure experience. Our friends at Malwarebytes have gathered their recommendations for the second part of this web browser blog series called, How to browse the internet safely at work.
How can Detectify help:
As a web developer you can follow this guide to add secure headers, and for those who like automation, you can use an automated scanner like Detectify to check your web applications for vulnerabilities and whether HTTP-headers are missing. Implementing these headers can prevent XSS attacks and lessen the opportunities for black hat hackers to listen in on user traffic. Why not give it a try? Get your free scan here and see whether you are missing any HTTP-headers in your web server.
Detectify is automated web application scanner checking for 1000+ known vulnerabilities including OWASP Top 10 and SSRF. Start your Detectify free trial today to see whether your applications are missing HTTP headers and more.