What About the Cookies??
Tags: codenewbie, security, cookies, todayilearned
Published: 2020-07-22 00:29:39

For my [password manager project](https://flatiron-passwordmanager.netlify.app/) I ran into an issue where my user information was not being persisted when I refresh a page. I dealt with it by clearing out the JWT from the sessionStorage in the browser and forcing the user to re-login, BUT this is annoying. It is one thing to log out when a tab is closed but another when simply refreshing for potentially updated information or maybe a lost Internet connection. 

Recently I've been looking at browser, their default actions, and their cookies. 
Cookies are very a very important part of the browsing experience and are used for everything from logging people into an application to tracking a user across their interactions. But what really are cookies? How do they work? How 




# What is a cookie?
Cookies are small bits of data (text only information) that servers send to web browsers to be send back with each request back. The data are key-value pairs, along with a number of attributes that are used to control when and where the cookie is used along with user ID, session ID, CSTF Tokens, or really anything used to validate who someone is and any settings they might have saved specific to their account.

![](https://media.giphy.com/media/b83SxCAghtl28/giphy.gif)


# Cookie Flavors
There are a few types of cookies that you will see in the web: First-party cookies, Third-party cookies, Zombie cookies, and Supercookie.

__First-party cookies__
Also called a "samesite" cookie, these cookies are directly created by the website that is using them. They are generally considered safer as long as the website is not compromised and you don't visit any compromised sites because the browsers should only send these cookies with requests originated from the same domain/site as the target domain.

__Third-party cookies__
These are cookies that belong to a domain different from the one shown in the address bar. These cookies can open up potential risk of tracking a user's browsing history.



__Zombie cookies__
These are cookies that automatically recreate themselves once they have been deleted. Though generally used for tracking, these cookies can be very dangerous as they generally are installed on the users computer on backups outside of the browser's dedicated cookie storage space.

__Supercookie__
Are cookies whose origin is a top-level domain (such as `.com`) or a public suffix (such as `.co.uk`). Supercookies pose a potential huge security issue because of the hierarchy of cookies. With a normal site (such as `exmaple.com`) the cookie's scope is restricted to its specific domain (in this case `example`), but a supercookie's scope is defined to the any site with the .com suffix.



# How are Cookies set?
Setting a cookie is not an automatic thing. A site will not automatically set one just because a user action is performed, so developers need to set the cookie and ensure that it is set properly. So, how do they get set? 

Cookies are set with the `Set-Cookie` HTTP response header. (Note:: In contrast to Cookies, JWT is generally set within the Authorization header.) You can set a cookie on the backend server and they are sent back in the HTTP response. 






# How to Protect Your Cookies?
The bad thing about cookies is that browsers automatically send back related cookies to a domain as part of the HTTP request header.

This is bad as it can lead to a CSRF vulnerability. 

While every implementation will be a bit different, there are a few things you can follow to harden your cookies to make them safer. ![](https://i.imgur.com/RFUhlya.gif)

- Define the life of a cookie.
    This is important to ensure that potentially important cookies are deleted and not just lingering in your local browser.
- NEVER store anything sensitive in `localStorage`; such as JWTs or any other credential for that matter. 
    The purpose of `localStorage` is to provide user convenience and experience by saving website states and settings, not authentication. Consider `sessionStorage` as when a session ends, such as a browser or tab closing, the associated cookie will also be deleted
- Restrict access to cookies though the `Secure` attribute and the `HttpOnly` attribute. (see below for more info)
- Use of the `SameSite` attribute to prevent cross-origin requests
- Never render the token on screen, in URLs and/or in source code.(6)







<hr>

## Secure attribute
The `Secure` attribute is good to use as it is sent to the server _only_ with an encrypted request over the HTTPS protocol.


## HttpOnly Cookies to the rescue!
"When you tag a cookie with the HttpOnly flag, it tells the browser that this particular cookie should only be accessed by the server. Any attempt to access the cookie from client script is strictly forbidden." (4) 

By using the `HttpOnly` flag in the `Set-Cookie` HTTP response header this will restrict all __read__ access to 'document.cookie', _if the browser supports it_. Currently, IE7, Firefox 3, and Opera 9.5 support the `HttpOnly` flag and in IE it also removes cookie information from the response headers in `XMLHttpObject.getAllResponseHeaders()`, and `XMLHttpObjects` may only be submitted to the domain they originated from, so there is no cross-domain posting of the cookies. (7)

![](https://media.giphy.com/media/1gWhwASWCtFeu44aes/giphy.gif)

Be careful though! Sure. `HttpOnly` can keep cookies from being __read__, _but_ like any file in a computer there are 3 actions that can be performed on it: read, write, and execute.
`Httponly` only takes away from read action, and if the site is vulnerable the cookie can still be sent along with a request(execute)... even from the samesite. 



## Is a `SameSite` Cookie an Option?
The `SameSite` attribute is an option that allows you to declare if your cookie should be sent with cross-origin requests via a "Strict", "Lax", or "None" property.

The difference between the "strict" and "lax" property is that a strict cookie will only be sent if the site for the cookie matches the site currently shown in the browser's URL bar. This means that when a user is on a site, the cookie will be sent with the request but if the user is following a link into that site, say from another site or via an email, that the cookie will not be sent. 
The strict property is good where there are cookies relating to functionality that will always be behind an initial navigation, such as changing a password or making a purchase.

A "Lax" property similar to "Strict", but only allows the cookie to be sent with top-level navigations and allows for the exception for when the user navigates to a URL from an external site.

See, a `strict` property is too restrictive for things like promos where if a user follows an email link into the site, they want the promo cookie sent so their promo can be applied. This is where the Lax property comes into play. 
The lax property is a good choice for cookies that will affect the display of a site where strict is useful for cookies related to actions your user will be taking taking.




<hr>

#### References 
1. https://www.owasp.org/index.php/HttpOnly
2. https://www.owasp.org/index.php/SameSite
3. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie
4. https://blog.codinghorror.com/protecting-your-cookies-httponly/
5. https://web.dev/samesite-cookies-explained
6. https://medium.com/redteam/stealing-jwts-in-localstorage-via-xss-6048d91378a0
7. https://www.instantssl.com/digital-signature
8. https://www.geeksforgeeks.org/hmac-algorithm-in-computer-network/
9. https://en.wikipedia.org/wiki/HMAC
10. 


###### Please Note that I am still learning and if something that I have stated is incorrect please let me know. I would love to learn more about what I may not understand fully.