As the HTTP protocol is stateless by its nature, cookies and session cookies in particular play a vital role in the security of a web application.

An HTTP cookie is a small piece of data the server sends to the user’s web browser. The browser stores it and sends it back in following requests to the server.

When a user logs into an application, a session ID is generated. A session ID is a randomly generated string that is used to identify a user’s session in the system, they are stored inside an HTTP cookie known as a Session Cookie.

The ability of the attacker to view a session cookie or override it with one of his own could compromise users data and the entire security of the application.

In this guide I will explain some common attacks on session cookies(applies to all cookies as well), how to prevent each one of them and end with a list of best security practices to follow when handling cookies.

1- Session Sniffing

In its most basic form the attacker will listen on the network for any plain http requests, steal the session ID and use it to impersonate the user of the application.

One common security issue is applications that use HTTPS to authenticate the user and then send the session cookie in plain HTTP which allows the attacker to easily sniff the ID cookie after the authentication is done.

Source: owasp.org

Prevention:

• Use HTTPS everywhere on you site

• Set the secure Flag to true in order to prevent the cookie from being submitted over plain http

2- Session Fixation

In a session fixation attack the attacker tricks the user into sending a session ID generated by the attacker to the web server and then uses the session ID to impersonate the user.

Source:owasp.org

Prevention:

• Always generate a new session ID on the server and do not accept any session ID from the user

3- Session ID Brute Forcing

In session ID brute forcing the attacker tries to brute force (guess) the user session ID.

Source: kaspersky.com

###Prevention:

• Use at least 128 bit session identifier with 64 bits of entropy

• Block abusive IPs in your application

4- Cross-site scripting

In Cross-site scripting attack (XSS) the attacker is able to inject arbitrary JavaScript code into the page and use it to access the session cookie.

Source: owasp.org

Prevention:

• Set the HttpOnly flag on cookies to true in order to prevent javascript code from accessing them

• Harden your web app security to prevent XSS attacks

5- Cross-Site Tracing

In an Cross-Site Tracing attack (XST) the attacker uses Cross-site scripting(XSS) attack to send a TRACE request to the server and read the response thus bypassing the HttpOnly flag on the cookie.

Source: deadliestwebattacks.com

Prevention:

• Disable the TRACE method on the server

6- Cross-Site Request Forgery

In Cross Site Request Forgery attack (CSRF) the attacker tricks the user into performing some unwanted actions on the application and exploits the default behavior of the browser of sending the cookie to other domains the page requests resources from (eg. images, scripts etc).

Source: deadliestwebattacks.com

Prevention:

• Set the SameSite parameter to strict in order to prevent sending the cookie to any domain that did not generate it(the domain in the URL of the current page)

• Implement security measures to prevent CSRF attacks on your application

7- Information Leakage Through Cookies

In information leakage the attacker is able to know the user information by getting access to the user cookies (even an expired one).

Source: lepide.com

Prevention:

• Do not store any important information in a cookie, instead the user session information should be stored on the server and only use the cookie as an identifier of the user

8- Malware on User Device

In this attack the attacker is able to install malware on the user’s device and use it to steal the session cookie from disk or memory.

Prevention:

• Do not Set Expires / Max-Age value of the cookie, this way the browser only stores the cookie in memory and its deleted as soon as the browser is closed.

• Make the cookie lifetime short

• Invalidate the cookie on the server and do not rely on the client to delete the cookie

9- Cross-Subdomain Cookie Attacks

This attack relies on the attacker’s ability to obtain a subdomain of the original top level domain and exploit the ability of the browser to send cookies set by the top level domain or other subdomains to the subdomain owned by the attacker.

Another version of this attack is the attacker ability to override the session cookie of a legitimate user and fool the user into using the attacker account in order to perform actions on the application and then exploit any historical data left by the user(such as credit card number or bank credentials).

Source: brafton.com

Prevention:

• Do not share the session cookie across subdomains, instead generate a new session cookie for each sub domain

• Do not set the Domain attribute for cookies in order to prevent them from being shared with top level domains and other subdomains

• Avoid using subdomains for any untrusted applications and use seperate domains instead

10- Cross-page Cookie Attacks

In this attack the attacker uses his ability to attack a page on the application to get the cookie generated by another page on the same application.

This is more specific to web apps that host user specific sites on the same domain using seperate paths.

Source: pexels.com

Prevention:

• If only the cookie is only useful within a certain page or a number of pages in a certain path then set the path attribute of the cookie to that page as this will prevent it from being sent to other pages in the application

11- Cookie Overriding Attack

In this attack the attacker is able to write a cookie on the user’s browser by tricking the user to navigating into an HTTP version of the site or setting the cookie through a subdomain.

If a secure cookie is absent from the browser, the browser will accept the cookie sent by the attacker.

Source: exploresecurity.com

Prevention:

• Use _Secure and _Host prefixes to prevent the cookie from being written by an insecure host (prefer _Host prefix as this will also enforce the host to be secure)

Here’s a summary of best security practices for securing a web application’s cookies:##

• Use HTTPS everywhere

• Do not accept Session IDs from the user

• Generate Session IDs on the server

• Generate a new Session ID on each login

• Use at least 128 bit session identifier with 64 bits of entropy

• Set the secure flag to true

• Set the HttpOnly flag to true

• set the SameSite attribute to strict

• Set Path attribute to a suitable value

• Do not Set Expires / Max.Age attribute of the cookie

• Do not set the Domain attribute for cookies

• Do not store any information in a session cookie

• Do not share the session cookie across subdomains

• Generate a new session cookie for each sub domain

• Use seperate domains instead of subdomains

• Disable TRACE method on the server

• Log user out if the referer is suspicious

• Make the cookie lifetime short

• Invalidate the cookie on the server

• Use cookie prefixes _Secure and _Host

Congrats on finishing this article, now you have the knowledge to make tough cookies that can survive the web.