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
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.
There are a few types of cookies that you will see in the web: First-party cookies, Third-party cookies, Zombie cookies, and Supercookie.
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.
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.
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.
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.
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.
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.
- 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
localStorageis to provide user convenience and experience by saving website states and settings, not authentication. Consider
sessionStorageas when a session ends, such as a browser or tab closing, the associated cookie will also be deleted
- Restrict access to cookies though the
Secureattribute and the
HttpOnlyattribute. (see below for more info)
- Use of the
SameSiteattribute to prevent cross-origin requests
- Never render the token on screen, in URLs and/or in source code.(6)
Secure attribute is good to use as it is sent to the server only with an encrypted request over the HTTPS protocol.
"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
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.
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.
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.