Skip to main content

CSC105 Backend: Cookie

To learn more on what's cookie, just googling "what's web cookie". Next, let's see the cookie in action.

  1. Try to open any website in the browser. For example, https://sqlworkshop.bsthun.com/.
  2. Open DevTools windows (by pressing F12 or Control + Shift + I (Windows) or Option + Command + I (macOS)) and choose Application tab.

    Screenshot 2023-05-01 at 4.57.39 AM.png

  3. Choosing the website origin in the cookie tab, and then you will see what cookie data are stored for that website.

    Screenshot 2023-05-01 at 5.00.57 AM.png

  4. 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.

    Screenshot 2023-05-01 at 5.05.44 AM.pngYou'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.

  5. 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.

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.

Let's go to the website and login normally. Then inspect the cookie using DevTools and see that cookie stored in the browser.

Screenshot 2023-05-08 at 11.07.18 AM.png

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

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.

Screenshot 2023-05-08 at 11.14.31 AM.png