Hey there! Welcome to our guide on sessions and cookies.
So, what’s the big deal about sessions and cookies? In a nutshell, they’re all about remembering things. When you visit a website, sessions and cookies help the site remember who you are, what you’re doing, and even some of your preferences.
Think of cookies as little notes that websites leave in your browser. They can store bits of information like your login status, items in your shopping cart, or your favorite settings. On the other hand, sessions are like temporary storage lockers on the server side. They keep track of your activities while you’re on the site but usually forget everything once you leave.
In this article, we’ll break down what sessions and cookies are, how they work, and why they’re so important.
What are cookies?
Wikipedia describes the definition of cookies as follows.
“A cookie is a type of hypertext record (HTTP) and refers to a small record information file that is installed on the Internet user’s computer through the server that the site is using when the Internet user visits a website. HTTP cookie, web Also called cookies or browser cookies (hereinafter omitted).
As defined by Wikipedia, a cookie is a small temporary file consisting of a string of key=value pairs that is stored on the client side when a user visits a website. When a re-request is made to the same server, the web browser transmits the stored cookie data in the Cookie request header.
Due to statelessness, a characteristic of the HTTP protocol, cookies were created to identify whether successive user requests are from the same user or to remember the user’s state within the website. Although cookies are not sensitive, such as “recently viewed products” in an online shopping mall, they are used to set up data necessary to provide services. However, they are also used for user authentication, making them easy targets for attackers.
What are cookies used for?
The purpose of using cookies varies depending on the website, but they are generally used to remember the user’s status data to achieve the purposes below.
- Session Management : Allows a website to identify you and remember your login information.
- Personalization : Used to personalize the user’s website experience, such as customized advertisements for each user or preferences within the website.
- User Activity Tracking : We track and analyze the user’s website usage patterns and search habits to suggest other content that the user may prefer.
What types of cookies are there?
From the perspective of the cookie lifecycle, there are two types:
- Session Cookie : A cookie that is stored in memory while the user is visiting a website. Also called temporary cookies or in-memory cookies. Cookies that are deleted when the user closes the web browser and do not have a separate expiration date or validity period are considered session cookies.
- Persistent Cookie : A cookie with an expiration date (Expires attribute) or validity period (Max-Age attribute) set by the server and stored on the user’s hard disk. Unlike session cookies, which are deleted when your web browser is closed, they are deleted when the set expiration date expires or their validity period expires.
How are cookies issued?
Cookies are issued through the Set-Cookie response header when the server that received the client’s HTTP request returns a response.
The basic format of the Set-Cookie response header is as follows.
Set-Cookie: Cookie-name=Some-Value;
Additionally, the Set-Cookie header can control how web browsers handle cookies through the following properties:
These are examples of each property and each property.
- Expires : Set the cookie expiration date. The example below is a cookie valid until 05:56:24 on October 7, 2020, and is sent to the server for 1200 seconds based on the cookie issuance time.
Set-Cookie: Cookie-name=Some-value; expires=Wed, 07-Oct-2020 05:56:24 GMT; Max-Age=1200;
- Domain : Determines the domain to which cookies will be sent by the web browser. This property can only be set on the top-level domain of the domain issuing the cookie and its subdomains. If you set this property to bugbountyclub.com as in the example, the cookie will also be sent to requests for all subdomains, such as subdomain.bugbountyclub.com, including bugbountyclub.com. If this attribute is not specified, the domain where the requested resource is located is assumed, excluding subdomains.
Set-Cookie: Cookie-name=Some-value; Domain=bugbountyclub.com;
- Path : Determines the URL path where the cookie will be sent by the web browser. In the example below, the Domain property is not specified, so cookies are sent only when requested to the /bbc path or a subpath of the domain where the requested resource is located, as described above. For example, if the domain of the requested resource is www.bugbountyclub.com, cookies will be sent only when requests are made to www.bugbountyclub.com/bbc or its subpaths.
Set-Cookie: Cookie-name=Some-value; Path=/bbc;
- Secure : Cookies can only be sent if the connection is encrypted via HTTPS, and have no separate value.
Set-Cookie: Cookie-name=Some-value; Secure;
- HttpOnly : Cookies cannot be accessed through JavaScript (document.cookie) on the client side and have no separate value. Used as a mitigation measure against Cross Site Scripting (XSS) attacks.
Set-Cookie: Cookie-name=Some-value; HttpOnly;
- SameSite : Determines whether cookies are included in requests across cross-domains. Possible values include Lax, Strict, and None. Lax allows cookies to be sent for GET requests, even cross-domain. Strict allows cookies to be sent only when the request originates from itself. None allows cookies to be sent on all cross-domain requests. This property is often used as a mitigation against Cross Site Request Forgery (CSRF) attacks.
Set-Cookie: Cookie-name=Some-value; SameSite=Strict;
Of course, you can also list multiple properties and set them together, like this:
Set-Cookie: Cookie-name=Some-value; expires=Wed, 07-Oct-2020 05:56:24 GMT; Max-Age=1200; Domain=bugbountyclub.com; Path=/bbc; Secure; HttpOnly; SameSite=Lax;
The cookie issued by the server through the Set-Cookie response header seen above is stored on the client side (where it is stored on the client side depends on how the server issues the cookie), and the cookie value stored each time the client makes a request thereafter. It is automatically transmitted to the server by the web browser. The server identifies the user or checks the user’s status through the cookie value sent from the client.
Now, let’s take a look at the process by which cookies are issued and used.
A user with an account named foo visits an online shopping mall called https://www.shoppingmall.com and sends the POST request below to the server to log in.
POST /login HTTP/1.1 Host: www.shoppingmall.com ...skip... username=foo&password=bar
The server that received the request processes user authentication and sends the cookie value to the client in the Set-Cookie response header.
HTTP/1.1 200 OK Set-Cookie: username=foo; ...skip... Welcome, foo!
The cookie shown in the example above was issued without an Expires or Max-Age attribute, so it is a session cookie that is only valid for the current session. Upon receiving this response, user foo’s web browser stores the value of the Set-Cookie response header in memory.
Now user foo sends the below GET request to the server to check his shopping cart list. At this time, the web browser transmits the stored cookie value to the server in the Cookie request header. This process is performed automatically by the web browser without user intervention.
GET /cart HTTP/1.1 Host: www.shoppingmall.com Cookie: username=foo; ...skip...
The server determines that the request received through the value of the Cookie request header is from user foo, and sends the shopping cart list of user foo as a response.
HTTP/1.1 200 OK ...skip... foo's Cart List
If there is no cookie, due to the non-connectivity and statelessness characteristics of HTTP, the connection between foo and the server is not maintained and is terminated, and the server will not be able to know whether the subsequent request from user foo was received from foo. However, the use of cookies allows us to use the website in a continuously authenticated state after logging in. Of course, there is no website that implements user authentication using only cookies, which are stored only on the client side as shown above. In other words, being stored on the client side means that data can be modified by the user as much as desired. In a website implemented as above, anyone can become an administrator simply by changing the cookie value of username=foo to username=admin using an intercepting proxy tool such as Burp suite, and only knowing the account name of another user. If so, you can impersonate another user. Therefore, many websites use various and safe user authentication methods, but in the case of general websites, session-based user authentication is implemented by combining the concepts of cookies and sessions.
The cookies we looked at earlier had a serious security problem in that arbitrary users could manipulate the cookies to pretend to be other users. Sessions are used to avoid problems with these cookies.
What is a session?
A session is a technology that maintains a connection between a user and a web server for a certain period of time. Sessions allow a website to remember state data based on user activity. Sessions are similar to cookies in that they allow for storing and tracking state data, but the main difference is that cookies are stored on the client side, whereas sessions are stored and managed on the server side.
State management of sessions
Technologies that a server can use to maintain state information through a session are as follows.
- Cookie : Most websites use cookies to store session tokens . Using the cookie properties discussed earlier allows relatively safer implementation compared to other methods. The server can maintain session state through a session token that the client sends through the Cookie request header with each request.
- Hidden Form Field : The server dynamically includes the session token in a hidden field in the HTML form that will be sent to the client. When the client submits the form again, it is sent back to the server.
- URL rewrite : Dynamically includes a unique session token in the URL requested from the client. You must include a unique session token in the URL that is included in the href of all a tags or the action attribute of form tags included in your website.
How do sessions work?
Let’s take a look at how session-based user identification is handled using cookies.
A user with an account named foo logs in to an online shopping mall.
POST /login HTTP/1.1 Host: www.shoppingmall.com ...skip... username=foo&password=bar
The server that received the request creates a session token if there is no session token received from the client, and stores the session token for user foo as a1b2c3. This session token is sent to foo in the Set-Cookie response header. A session is established between the user and the web server, and the session created through login authentication is also called an authenticated session. Please note that sometimes anonymous sessions are established with users who are not logged in.
HTTP/1.1 200 OK Set-Cookie: sessionid=a1b2c3; ...skip... Welcome, foo!
To check his shopping cart details, foo sends the GET request below to the server along with the session token issued by the server.
GET /cart HTTP/1.1 Host: www.shoppingmall.com Cookie: sessionid=a1b2c3; ...skip...
The server checks whether the value of the session token included in the request matches foo’s stored session token, and if so, displays foo’s shopping cart list.
HTTP/1.1 200 OK ...skip... foo's Cart List
When foo logs out or a certain period of time set by the server elapses, the session being maintained is automatically terminated.
Are the sessions safe?
Sessions can be said to be relatively secure compared to cookies, which are stored on the client side, because the user’s state data is stored on the server. However, if the session token is not publicly exposed or predictably complex or long, an attacker can use the exposed token as is or use brute force to impersonate the website’s target user or any user currently maintaining a valid session. can.
How can I safely manage sessions?
To prevent session token exposure and prediction, session management must be implemented as follows.
Unpredictable session token
Session tokens issued to users via cookies must consist of a sufficiently long, encrypted random string via a cryptographic hash such as SHA256. The length must be at least 128 bits, and sufficient randomness must be guaranteed. Entropy of at least 64 bits must be provided, and the session token must be unique and not duplicated as it identifies and tracks the user.
Use encrypted HTTPS communication
When using HTTP, you may be vulnerable to cryptographic man-in-the-middle attacks. You must use HTTPS throughout your website.
Setting cookie security properties
- Domain & Path : The domain and path where cookies will be sent should be set as restrictively as possible.
- Secure : Cookies must be sent only for HTTPS connections. Sending cookies over HTTP connections may expose session tokens to attackers listening to network traffic.
- HttpOnly : Cookies should not be accessed through scripts.
- Expires & Max-Age : It is safer to enable session cookies without setting these two properties. However, if you inevitably need to set an expiration date or validity period, you should set it as defensively as possible to avoid it remaining unnecessarily long.
- SameSite : Cross-domain cookie transfer must be disabled.
