Hello. In our last lesson, we made a static login form interactive with JavaScript. You saw how a script can access user input and even prevent the form from submitting. We briefly touched on document.cookie as a way for JavaScript to access data stored by the browser, noting it as a potential security risk. Today, we'll dive deep into that topic.
This lesson explores cookies and session management, the fundamental mechanisms that allow web applications to remember who you are. We'll examine why they are necessary, how they work, and, most importantly for your bug bounty goals, how they can be misconfigured or attacked. Understanding how a web application maintains state is crucial for finding some of the most impactful vulnerabilities, such as session hijacking and authentication bypasses.
The Stateless Problem
The Hypertext Transfer Protocol (HTTP), which underpins the web, is stateless. This means that every request a browser sends to a server is treated as an independent event. The server has no built-in memory of previous requests. Imagine having to show your ID card every time you walk into a different room in an office building—that's what a stateless web feels like. For anything beyond a simple, static page, like logging in or using a shopping cart, this is a major problem.
This is where sessions and cookies come in. They are the web's solution for creating a "stateful" experience over a stateless protocol.
Difference between cookies, session and tokens (re-upload, no music)
To start, let's look at a high-level overview of this process using a familiar example: logging into a bank. This video, "Difference between cookies, session and tokens", provides a clear, simple explanation.
Watch the beginning of the video to see how a successful login results in the server creating a "session" and giving your browser a "session ID" inside a cookie. Think of this as exchanging your credentials for a temporary access pass. To solidify this idea, the video uses an excellent gym membership card analogy. This helps distinguish the role of the cookie (the card) from the session (the membership data at the gym).
How Cookies and Sessions Work Together
As you just saw, the process involves two key components: the session on the server and the cookie on the client.
-
Session: When you log in, the server creates a unique session for you. This is a data structure on the server that stores information about your current state (e.g., your user ID, your login time, items in your shopping cart). This session is assigned a long, random, and unique Session ID.
-
Cookie: The server sends this Session ID back to your browser as part of a cookie. A cookie is just a small piece of text that the browser stores. The server does this using a response header called
Set-Cookie. -
Maintaining State: For every subsequent request you make to that same website, your browser automatically attaches the cookie. The server reads the Session ID from the cookie, looks up the corresponding session in its database, and instantly knows who you are and what your status is.
Web App Pentesting - HTTP Cookies & Sessions
The HackerSploit video "Web App Pentesting - HTTP Cookies & Sessions" offers a more technical breakdown from a security perspective.
Watch this segment on stateless protocols. It reinforces the problem and explains how the client (your browser) becomes responsible for storing the session information inside cookies for future requests.
The Anatomy of a Cookie
A cookie isn't just a simple key=value pair. It has several attributes that control its behavior, and these attributes have significant security implications.
Web App Pentesting - HTTP Cookies & Sessions
Let's continue with the HackerSploit video to explore the critical attributes of a cookie. Understanding these is essential for a bug bounty hunter.
Pay close attention as this segment breaks down the key attributes. Make a mental note of each one: Name/Value: The actual data, like session-id=.... Expiry/Max-Age: Determines if it's a "session cookie" (deleted when the browser closes) or a "persistent cookie" (lasts until a specific date). Domain/Path: Scopes the cookie to specific domains and URL paths. Secure: A flag that tells the browser to only send the cookie over an encrypted HTTPS connection. If this is missing, the cookie can be stolen over an open Wi-Fi network. HttpOnly: A crucial security flag. When set, it prevents client-side scripts (like JavaScript) from accessing the cookie.
The HttpOnly attribute directly relates to what we discussed in the last lesson. We saw that innerHTML could be used to inject a script. If an attacker can inject a script and the HttpOnly flag is not set on the session cookie, they can use document.cookie to steal it and hijack the user's session.
The Security of Session IDs
The entire security of this model rests on the assumption that an attacker cannot guess or steal a user's session ID.
Web App Pentesting - HTTP Cookies & Sessions
The session ID itself must be strong. The HackerSploit video outlines the security guidelines for creating them.
Watch this short clip on session ID guidelines. The key principles are that session IDs must be random, unique, lengthy, and securely transmitted.
Attacking Cookies and Sessions: A Practical View
Now, let's see how these concepts translate into real vulnerabilities.
Cookie Theft via Cross-Site Scripting (XSS)
This is the classic attack we've been building towards. If HttpOnly is not set, an XSS vulnerability becomes much more severe.
Web App Pentesting - HTTP Cookies & Sessions
The HackerSploit video provides a fantastic demonstration using the Damn Vulnerable Web Application (DVWA). It shows exactly how the HttpOnly flag protects against session hijacking.
This is a critical section for your bug bounty goals. Watch from this part of the video. First, you'll see how document.cookie in the browser console can read the cookie when HttpOnly is disabled. Then, you'll see the flag enabled, and the same command returning an empty string, effectively blocking the script. Finally, the video shows a stored XSS payload that pops an alert with the user's cookie. This demonstrates how an attacker could steal the session ID and send it to their own server. The video then shows that simply enabling the HttpOnly flag completely neutralizes this specific attack vector.
Predictable Session IDs
What if a session ID isn't random? For example, what if a web application assigns user IDs sequentially (1, 2, 3, ...)? An attacker logged in as user 100 could try to tamper with their own cookie, change the session ID to 99, and see if they gain access to another user's account. This is a session hijacking vulnerability. Professional tools like Burp Suite have features specifically to test for this.
Web App Pentesting - HTTP Cookies & Sessions
For a bug bounty hunter, it's not enough to know this exists; you need to know how to test for it. Burp Suite's "Sequencer" is a tool for exactly this purpose. It analyzes a large sample of tokens (like session IDs) to measure their randomness (entropy).
Watch this advanced demonstration from this part of the video. Don't worry about replicating every step right now. The goal is to see the methodology: Capture requests that generate session IDs. Send these requests to Burp Sequencer. Let the tool gather hundreds or thousands of samples. Analyze the results. The video shows a transition from a "weak" session ID (sequentially numbered) with "extremely poor" randomness to a "high" security setting where the randomness is "excellent". Finding weak session tokens can be a valid and valuable bug report.
Try It Yourself
Open a website you frequently use, like a social media or shopping site. Open your browser's Developer Tools (F12 or Ctrl+Shift+I) and find the cookie storage.
- In Chrome/Edge, it's under
Application->Storage->Cookies. - In Firefox, it's under
Storage->Cookies.
Click on the site's URL. You will see a list of all the cookies the site has set. Examine them. Can you identify the session cookie? Look at its attributes. Is the HttpOnly flag set? Is the Secure flag set? Does the value look like a long, random string? This is the kind of initial analysis you will perform on every target.
Difference between cookies, session and tokens (re-upload, no music)
To bring it all together, let's watch one final, concise recap.
This short segment from the first video perfectly summarizes the division of labor: the session is generated and stored on the server, while the cookie is just the transport medium for the session ID on the client side.
Conclusion
You've now demystified one of the most fundamental aspects of web application functionality and security. Maintaining state is essential for modern web apps, and doing so securely is a major challenge.
Key Takeaways:
- HTTP is stateless; cookies and sessions are used to add state.
- A session is server-side data, identified by a unique session ID.
- A cookie is client-side data, used to store the session ID and send it back to the server with each request.
- The
HttpOnlyattribute is a critical defense against session hijacking via XSS. - The
Secureattribute ensures cookies are only sent over encrypted HTTPS. - Session IDs must be long, random, and unpredictable to prevent guessing and impersonation.
With this lesson, we conclude our first module on foundational web concepts. You now have a solid understanding of the client-server model, HTML, basic JavaScript, and how applications maintain state.
In our next lesson, we will begin a new module, "Networking and HTTP for Hackers." We'll move down the technology stack to see how your browser finds a server in the first place, starting with the Domain Name System (DNS) and its role in reconnaissance.