A guide to HTTP security headers for better web browser security – 10 minute mail

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 Disposable mail 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 Disposable mail 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.

Disposable mail is automated web application scanner checking for 1000+ known vulnerabilities including OWASP Top 10 and SSRF. Start your Disposable mail free trial today to see whether your applications are missing HTTP headers and more.

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.

HTTP response splitting exploitations and mitigations – 10 minute mail

HTTP Response Splitting is a type of attack that occurs when an attacker can manipulate the response headers that will be interpreted by the client. This article goes into details on how this can be abused by an attacker to insert arbitrary headers and the impact of this type of attack.

But first… HTTP headers and CRLF

The HTTP protocol partly consists of the header section and the body of each response and request between a web server and a client. In the headers section several things can be transmitted such as URI, cookies, server information and status codes. These headers will be interpreted by the web server or client.

A simple HTTP response (from the server) may look something like:

A simple HTTP response (from the server) may look something like:

In the above response we can see rn after each line which are two characters, carriage return (r) and a line feed (n), also abbreviated as CRLF. In the HTTP specification, you can set a CRLF to specify the end of the header.

How HTTP Response Splitting exploitations work

One of the most common attacks are to inject a second HTTP-response with defined headers and HTML content, which then leads to XSS. A vast majority of HTTP Response Splitting vulnerabilities occur due to the value of the `Location` header is not properly sanitized, and this is problematic for hackers as the browser will do the redirect and the hackers injected HTML will be ignored.

Imagine the following HTTP response (the red part is injected by the hacker):   

The above attempt won’t be successful because the web browser will redirect to /username and the injected HTML will simply just be ignored.

But what if the attacker had complete control over the value in the `Location` header?

Because the `Location` value is empty, the web browser will ignore that header, meaning that the rest of the headers will be parsed by the web browser. As a result, no redirect will be made which means that the above attack would be successful.

If the attacker can control headers other than `Location`, then XSS is very easy as no redirect will take place that would otherwise ignore the injected headers. Headers that also may be vulnerable to HRS are `Link` and `Set-Cookie` as they often can be controlled by the user.

How about ‘Set-cookie’?

Another common attack is to inject a `Set-Cookie` header which will set a new cookie for the user. This can lead to Session Fixation, or even XSS if the value of the cookie is somewhere reflected and not sanitized. Example:

Which the server then will respond with:

The web browser then saves a cookie with the value of username=. If the website outputs this somewhere, for example in this context: “Welcome back username”, it would then display “Welcome back

Because the attacker can control the headers, it is possible to split the headers from the HTML content, and consequently some headers are reflected in the HTML (see first image). In some cases this can be headers with sensitive information, such as `Set-Cookie` thus bypassing cookie attributes such as `HttpOnly`. XSS via HRS can therefore be much more serious than standard XSS.

Learn more on HTTP-headers and the basics to securing web browsers here.

Mitigations

  • Properly sanitize values in the `Location` header. Filter characters such as r and n
  • Don’t let users control the whole value in the `Location` header
  • When using a Content-Security-Policy, it should also be defined in the HTML

How does Disposable mail help?

Using Disposable mail’s online vulnerability scanner, you can check whether your web applications are vulnerable to HTTP-response splitting exploitations mentioned in this article. We also check for other HTTP-header vulnerabilities.

Disposable mail is automated web application scanner checking for 1000+ known vulnerabilities including OWASP Top 10 and SSRF. Start your Disposable mail free trial today to see whether your applications are missing HTTP headers and more.


Written by:
Kristian Bremberg

Edited by:
Jocelyn Chan

Temp Mails (https://tempemail.co/) is a new free temporary email addresses service. This service provide you random 10 minutes emails addresses. It is also known by names like: temporary mail, disposable mail, throwaway email, one time mail, anonymous email address… All emails received by Tempmail servers are displayed automatically in your online browser inbox.