For my password manager project 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.

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.

• 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)

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)

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.

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

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.