Cookies are widely used on the web because they allow publishers to store data directly on the user’s web browser. They are particularly used to identify the user’s session, allowing the web server to recognize the user when browsing the site and generally contain sensitive data. You have to protect them properly.
The Set-Cookie HTTP header
Little reminder: each time a server responds to a request, the HTTP response can contain a Set-Cookie instruction (as an HTTP header) asking the web browser to create one or more cookies associated with one or more domains . These cookies store information that will be transmitted during future requests on these domains.
Here is the syntax of such a header:
Set-Cookie: <name>=<value>[; <Max-Age>=<age>] [; expires=<date>][; domain=<domain_name>] [; path=<some_path>][; secure][; HttpOnly]
Each cookie is identified by its name and stores a value. A lifetime (max-age) or an expiration date can be defined, to limit the conservation of data over time. Note that if both attributes are defined, the lifetime value (max-age) will prevail.
By default, a cookie is always associated with the location of the current document (domain as well as path) but the Set-Cookie header allows you to define custom values to restrict or extend the paths to which the cookie will be sent (by example, if a domain is specified, subdomains will be included). Therefore, one of the best practices in terms of cookie security is to manage their scope correctly.
The last 2 attributes, secure and HttpOnly deal specifically with security. Please note that they do not require any associated value: their very presence is sufficient for the browser to behave as expected with regard to the cookie.
Prevent the use of a cookie on the client side with HttpOnly
A cookie can be set and used over HTTP (communication between a web server and a web browser), but also directly on the web browser via JavaScript.
In an XSS violation, an attacker could inject malicious Javascript on the page, and potentially access cookies, which, as a reminder, often contain sensitive information. Needless to say, a website should not have XSS violations, this is a major security concern. But it’s barely possible to make sure you never have one (the content security policy can be an additional means of protecting your visitor from being exploited by an XSS attack).
The “HttpOnly” flag blocks access to the associated cookie from the client side (it cannot be used from Javascript code): if an attacker should succeed in injecting javascript despite all your precautions, he will not be able to access to cookies anyway. This will significantly limit the attack range.
Forbid to use a cookie without HTTPs thanks to the Secure flag
We regularly recommend it on this blog: your site must use HTTPs. If you have already adopted this protocol and applied our previous advice, you may think that your cookies are protected because they can only be transmitted by secure communication, nor can they be accessed via Javascript (thanks to the flag HttpOnly). Unfortunately, an important problem remains.
What happens if a user accesses your website via HTTP, for example because he types your URL without mentioning “https: //”? This can also happen if your web page contains mixed content.
Defining an HTTP Strict Transport Security (HSTS) header, which will apply HTTPS usage, will limit the risk for all future visits, but not the first. And not all browsers support this header …
In fact, only the Secure attribute will allow you to prohibit the transmission of a cookie over simple HTTP.
The value of this flag is clearly mentioned in the RFC HTTP state management mechanism:
Of course, remember that a cookie using this secure flag will in no case be sent to the HTTP version of your website. So be careful if your website still has HTTPS and HTTP zones.
Our web page analysis tool will allow you to check at a glance that all your cookies are secure, by checking whether HttpOnly and Secure are being used correctly!
Leave A Comment