Cookies are one of the most important elements in web applications, but unfortunately, many developers use it very loosely thus increasing the security risks to the website. I will teach here the importance of HTTP Cookies and best practices for using it securely in web applications. Lets gets started 🙂
Jump Directly To
What is a Cookie?
Cookies are text files with small pieces of data that is used to identify your computer as you use a computer network. Specific cookies known as HTTP cookies are used to identify specific users and improve your web browsing experience. Cookies are simple mechanisms to make HTTP stateful.
What Are Cookies Used For?
Cookies bring state to the HTTP protocol. It is used to make our web experiences streamlined. It is used to when a user logins to the website, Its used when relevant ads are shown to the user and its used when we shop using eCommerce shopping cart etc. These make cookies an important part of the internet,
- Session Management
- Personalization
- Tracking
Types of Cookies
A session cookie, also known as an in-memory cookie, transient cookie or non-persistent cookie, exists only in temporary memory while the user navigates the website.Web browsers normally delete session cookies when the user closes the browser. Unlike other cookies, session cookies do not have an expiration date assigned to them, which is how the browser knows to treat them as session cookies.
Persistent cookies remain on a computer indefinitely, although many include an expiration date and are automatically removed when that date is reached. For the persistent cookie’s lifespan set by its creator, its information will be transmitted to the server every time the user visits the website that it belongs to, or every time the user views a resource belonging to that website from another website. Persistent cookies are generally used for authentication and tracking.
Classification of Cookies
First-party cookies are directly created by the website you are using. These are generally safer, as long as you are browsing reputable websites or ones that have not been compromised.
Third-party cookies are generated by websites that are different from the web pages users are currently surfing, usually because they’re linked to ads on that page. This sort of cookie typically appears when web pages feature content from external websites, such as banner advertisements.
A supercookie is a cookie with an origin of a top-level domain (such as .com) or a public suffix (such as .co.uk). Ordinary cookies, by contrast, have an origin of a specific domain name, such as example.com. Supercookies can be a potential security concern and are therefore often blocked by web browsers. If unblocked by the browser, an attacker in control of a malicious website could set a supercookie and potentially disrupt or impersonate legitimate user requests to another website that shares the same top-level domain or public suffix as the malicious website. For example, a supercookie with an origin of .com, could maliciously affect a request made to example.com, even if the cookie did not originate from example.com. This can be used to fake logins or change user information.
Zombie cookies are persistent third-party cookies which gets installed on clients machine, even when they opt not to install cookies. They also might reappear after they’ve been deleted.
Cookie Attributes
A cookie has following attributes which must be correctly set to ensure safety, security & best practices for cookie usage.
Name
It is used to set the name of the cookie
Value
It is used to set the value of the cookie
Expire
It is used to set the expiry timestamp of the cookie after which the cookie can’t be accessed. If the expiration time of the cookie is set to 0, or omitted, the cookie will expire at the end of the session i.e. when the browser closes. The Expires attribute is used to set persistent cookies, limit lifespan if a session lives for too long, remove a cookie forcefully by setting it to a past date
Path
It is used to specify the path on the server for which the cookie will be available. The Path attribute plays a major role in setting the scope of the cookies in conjunction with the domain. In addition to the domain, the URL path that the cookie is valid for can be specified. If the domain and path match, then the cookie will be sent in the request. Just as with the domain attribute, if the path attribute is set too loosely, then it could leave the application vulnerable to attacks by other applications on the same server. For example, if the path attribute was set to the web server root /, then the application cookies will be sent to every application within the same domain (if multiple application reside under the same server)
Domain
It is used to specify the domain for which the cookie is available.The Domain attribute is used to compare the cookie’s domain against the domain of the server for which the HTTP request is being made. If the domain matches or if it is a subdomain, then the path attribute will be checked next.
Secure
The Secure attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed in unencrypted requests.
Http-Only
The HttpOnly attribute is used to help prevent attacks such as session leakage, since it does not allow the cookie to be accessed via a client-side script such as JavaScript. This doesn’t limit the whole attack surface of XSS attacks, as an attacker could still send request in place of the user, but limits immensely the reach of XSS attack vectors.
SameSite
The SameSite attribute is used to assert that a cookie ought not to be sent along with cross-site requests. This feature allows the server to mitigate the risk of cross-orgin information leakage. In some cases, it is used too as a risk reduction (or defense in depth mechanism) strategy to prevent cross-site request forgery attacks. This attribute can be configured in three different modes: Strict, Lax and None
Hostonly
Extended Security
Cookie prefixes make it possible to flag your cookies to have different behavior, in a backward compatible way. It uses a dirty trick to put a flag in the name of the cookie. When a cookie name starts with this flag, it triggers additional browser policy on the cookie in supporting browsers.
The __Secure- prefix makes a cookie accessible from HTTPS sites only. A HTTP site can not read or update a cookie if the name starts with __Secure-. This protects against the attack we earlier described, where an attacker uses a forged insecure site to overwrite a secure cookie.
The __Host- prefix does the same as the prefix and more. A __Host--prefixed cookie is only accessible by the same domain it is set on. This means that a subdomain can no longer overwrite the cookie value.
How to Use Cookies Securely
Based on the application needs, and how the cookie should function, the attributes and prefixes must be applied. The more the cookie is locked down, the better. Putting all this together, we can define the most secure cookie attribute configuration as: Set-Cookie: __Host-SID=; path=/; Secure; HttpOnly; SameSite=Strict.
Practical Implementation in PHP
The same path, domain, and other arguments should be passed that were used to create the cookie in order to ensure that the correct cookie is deleted.
It is used to indicate that the cookie should be sent only if a secure HTTPS connection exists.
