CSC105 Backend: Cookie
Cookie
To learn more on what's cookie, just googling "what's web cookie". Next, let's see the cookie in action.
What cookie a website stored
- Try to open any website in the browser. For example, https://sqlworkshop.bsthun.com/.
-
Open DevTools windows (by pressing F12 or Control + Shift + I (Windows) or Option + Command + I (macOS)) and choose Application tab.
- Choosing the website origin in the cookie tab, and then you will see what cookie data are stored for that website.
- Let's signin and navigate to the website's user-only zone (for example, enrollment page https://sqlworkshop.bsthun.com/enrollment) try delete the user cookie cookie (by click at the user cookie, then press delete on the keyboard) and refresh the website.
You'll see the error prompt to you that there's some error, and you will not able to get to your account again until re-signin again. It shows that the user cookie stores the logged in session and when you delete it. The system will not able to proof that's you anymore.
- Try signin to the website again, the user cookie should show up again. This is the action from the authentication process what after the credential has verified, it will store a cookie for storing the login session on your browser.
Cookie security
As we're currently known that Cookie is used for storing information at the client side. And the see the example that how SQLWorkshop website user information. If we look more deeper on the payload that SQLWorkshop website stores, we'll see that the information stored is not a plain text. It's the token of eyJhbGciOiJIUzI1NiIsInR5c...
instead. So why we need to store the information like this and what information stored inside this token?
Hacking client-side cookie
https://sqlworkshop-unsecure.bsthun.com/
We have created an unsecure proof-of-concept website for you to see the how security issue is concerned if we just store user token in a plain text.
Inspecting cookie
Let's go to the website and login normally. Then inspect the cookie using DevTools and see that cookie stored in the browser.
You'll see that after logged in, the cookie is stored with key "user" and value of the logged in user id (5, in my case). Not secured as a token like in real production website (sqlworkshop.bsthun.com).
Modifying cookie
As we known that cookie is manipulatable by client. Let assuming you're attacker and want to hack into other one's account. You can just inspect the cookie and then change it other value (6, in my case) and the server will understand that you're signing in from user id 6 which is user that actually not belongs to you.
As cookie is manipulatable by client. Storing logged in user session as plain text might compromised security issue that attacker could change cookie value directly without authenticating with the real user session.