Web Application Security: Hands-On Practice (Chapter 7 from The Web Application Hacker’s Handbook)

Note: This write-up reflects my learning and hands-on practice based on the book The Web Application Hacker’s Handbook: Discovering and Exploiting Security Flaws by Dafydd Stuttard and Marcus Pinto.

Attacking Session Management:

Session management is how a website keeps track of who a user is after they log in, allowing the site to recognize them across multiple requests. If this system is weak, attackers can hijack or fake sessions and act as other users without knowing their passwords. This can lead to full control of the application, especially if an admin account is compromised. Even strong authentication methods are useless if session management is insecure.

The Need for State:

Web applications need sessions because HTTP does not remember users between requests. Sessions use unique tokens (usually stored in cookies) to link multiple requests to the same user, whether logged in or not. If session tokens are weak or poorly handled, attackers can hijack sessions and impersonate users. Identifying and protecting session tokens is therefore critical for application security.

Practical Exploration of Session Management Flaws in a Deliberately Insecure Web Application:

Step1: Visit the http://127.0.0.1:5000

Step2: Click on the “Login” link

Enter the credentials: alice/password123

After clicking submit button:

Step3: Finding the real session token. Open browser dev tools → Application → Cookies.

Notice session_user=alice. That cookie is the session token

Step4: Cookie vs URL token confusion. Try this without logging in: http://127.0.0.1:5000/?user=admin

We are now “logged in” as admin. This shows multiple session sources (URL + cookie)

Step5: Removing tokens one by one. I just removed all the cookies, and refreshed the page, but it still allowed me to stay as admin.

Alternatives to Sessions:

Some web applications don’t use sessions to track users. Instead, they either rely on HTTP authentication (where the browser sends login details with every request) or store all user state on the client in encrypted or signed data like cookies or hidden fields. When these sessionless methods are used, traditional session-based attacks usually won’t work, so testers should look for other vulnerabilities instead.

Trying to manipulate the sessions on a local app:

App.py:

Step1: Log in as a normal user

This will Cookie set: role=user

Step2: Try accessing admin page

Correct behaviour so far.

Step3: Modify the cookie (the attack)

Using browser dev tools, change the role from role=user to role=admin.

Refresh the page:

What just happened?

· The app trusted client-side data

· No session ID was used

· No cryptographic protection

· You changed your privileges yourself

This is a classic broken sessionless state vulnerability.

Weaknesses in Session Token Generation:

· Meaningful Tokens

· Predictable Tokens

o Concealed Sequences

o Time Dependency

o Weak Random Number Generation

Meaningful Tokens:

If session tokens are predictable or contain real user data, attackers can guess them, steal sessions, and log in as other users.

A secure session token should be:

· Completely random

· Impossible to predict

· Meaningless if decoded

If a token contains patterns, user data, or predictable structure, it’s a serious security flaw.

Testing on local website where tokens be not secured:

Step1: Log in as a normal user

Output:

Step2: Look at the cookie. Open browser dev tools → Cookies → session

Step3: Decode the value “dXNlcj1hbGljZTtyb2xlPXVzZXI7ZGF0ZT0yMDI2LTAxLTI2”.

Clearly, we can see user=alice;role=user;date=2026–01–26. That’s the problem — the token literally tells you everything.

Step4: Modify the token, change the user = alice to user = admin and then encode it, like this:

Re-encode to Base64, replace the cookie value, refresh the page.

We are now “admin”. No password. No crypto. No randomness. Why this is insecure? The server trusts user-controlled, predictable, meaningful session data instead of generating a random, unguessable token.

Predictable Tokens:

Why this is dangerous?

Even if a token doesn’t directly contain your username or data, it can still be unsafe if:

· Tokens are issued in a sequence (like counting up)

· Tokens are based on time

· Tokens use weak randomness

If an attacker gets a few real tokens, they can guess other valid ones and take over other users’ sessions. Even guessing 1 valid token out of 1,000 tries is enough when a computer is doing the guessing automatically.

Concealed Sequences:

· Some session tokens appear random but contain hidden sequences.

· The pattern is concealed using encoding (e.g., Base64).

· Encoding makes tokens look complex but does not add security.

· When tokens are decoded/unpacked, numeric patterns may appear.

· Tokens may be generated by:

· Adding a fixed value to the previous token

· Truncating to a fixed size (e.g., 32-bit)

· Encoding the result for HTTP transport

· Attackers can:

o Decode tokens (Base64, hex, etc.)

o Analyse numeric differences

o Predict past and future tokens

· This allows session hijacking without authentication.

· Secure session tokens must use cryptographically strong randomness, not sequences.

Time Dependency:

Time dependency occurs when session tokens are generated using the time of creation as part of their value. If the application does not include enough randomness, the tokens become predictable even though they may appear random at first. Often, such tokens contain a sequential counter combined with a timestamp (for example, milliseconds since a fixed point in time).

By collecting multiple tokens and comparing them over time, an attacker can identify skipped sequence numbers issued to other users and estimate the time range in which those tokens were created. Because this time window is usually small, the attacker can brute-force possible values and successfully guess valid session tokens, leading to session hijacking. Therefore, secure session management must avoid relying on timestamps and instead use cryptographically strong random values.

Weak Random Number Generation:

Weak random number generation occurs when session tokens are created using predictable pseudo-random algorithms instead of true cryptographic randomness. Computers cannot generate true randomness, so they rely on algorithms that only appear random but actually produce numbers in a fixed sequence. If an attacker obtains a small sample of values from such a generator, they may be able to calculate past and future values with complete accuracy.

For example, Jetty’s session management once used Java’s java.util.Random, which is based on a linear congruential generator that derives each new value from the previous one using fixed constants. Because the algorithm is known, an attacker who captures a single session token can predict other users’ tokens and hijack sessions. Simply combining multiple outputs from the same weak generator does not solve the problem and can even make attacks easier by revealing the generator’s internal state.

Weaknesses in Session Token Handling:

· Disclosure of Tokens on the Network

· Disclosure of Tokens in Logs

· Vulnerable Mapping of Tokens to Sessions

· Vulnerable Session Termination

· Client Exposure to Token Hijacking

· Liberal Cookie Scope

· Cookie Domain Restrictions

· Cookie Path Restrictions

Disclosure of Tokens on the Network:

If your session token is sent without encryption, anyone watching the network can steal it.

Observing Disclosure of Tokens on the Network for a local website:

Create this folder structure:

Server.js:

Package.json:

dashboard.html:

Help.html:

Index.html:

login.html:

Start the server:

Browser:

Step1: Open the burp, and visit the page.

Make the intercept on:

See the request intercept: clearly, HTTP. Also, Cookie visible in cleartext.

Session cookie transmitted over unencrypted HTTP, allowing network interception.

Step2: Now Authenticated session over HTTP. Show logged-in session still uses HTTP. Visit the login page.

Browser: http://localhost:3000/login

Enter anything:

See the captured in burp:

Session cookie sent over HTTP after login. Application continues using HTTP after authentication, exposing session tokens.

Step3: Prove session ID does not change after login. For this, visit the login page and then, see the session id in the dev tools:

Now, login and again check:

Clearly, Same token reused. Session fixation vulnerability due to missing token regeneration after authentication.

Step4: Show token leaks when visiting public HTTP page.

1. Login

2. On dashboard, click:

Help

3. Burp intercepts:

GET /help

Authenticated session token disclosed when accessing non-secure page.

Disclosure of Tokens in Logs

Most people think tokens only get stolen by hackers spying on the network — but a very common and more dangerous problem is that tokens end up being written into logs (records that systems keep).

Logs are often:

· Viewed by many people (admins, helpdesk staff, support teams)

· Stored for a long time

Get Aditya Kumar’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

· Poorly protected

If a session token shows up in a log, anyone who can see that log can steal the session — even if they aren’t hacking the network.

Session tokens are secret keys that keep users logged in, but they can be stolen if they appear in system logs. This often happens when admin tools expose tokens or when applications put tokens in URLs, which get recorded in browser, server, and proxy logs. Many people may access these logs, making the risk more serious than network eavesdropping. Even with HTTPS, leaked tokens can let attackers hijack user sessions and take over accounts.

Disclosure of Tokens in Logs for the local vulnerable website:

App.py:

Terminal:

Browser:

When clicked on the login link, following page will appear:

Step1: we will be checking if the tokens are visible or not. For this we will enter the credentials ( alice / password1) and notice the URL.

Clearly, we can see the token as token=token-alice.

Step2: Copy the URL http://127.0.0.1:5000/?token=token-alice and paste it in new tab.

Clearly, we are logged in as Alice.

Step3: Open the message board

In the appeared message box, paste the following <a href=”http://127.0.0.1:5000/steal">Click me</a>

What just happened?

Because the app is insecure:

· It does not escape HTML

· It prints user input directly into the page

So instead of showing text, it renders a real clickable link.

Step4: Login via bob:password2 credentials, and click on the “Click me”, which was created by the alice in step3.

Browser:

Terminal:

We as attacker captured Bob’s session token successfully.

Step5: Performing session hijacking. Just copy paste the token we received earlier. We managed to use it.

Vulnerable Mapping of Tokens to Sessions:

This section explains that session security problems happen when websites poorly link session tokens to users. Allowing multiple active sessions, reusing the same token every login, or trusting user-controlled data in tokens all make account hijacking easier. These flaws let attackers stay logged in unnoticed or impersonate other users. The core issue is failing to tightly bind a session token to one verified user and one active session.

Vulnerable Mapping of Tokens to Sessions on a local vulnerable webpage:

App.py:

terminal:

Browser:

Step1: (Goal: to check if Concurrent sessions are allowed or not). Log in as alice in two different browsers (or incognito).

Chrome:

MS edge:

Both stay logged in → concurrent sessions allowed

Step2: (Goal: Check for Static session token). Log in → log out → log in again. Open browser dev tools → Cookies.

Cookies at first login:

Cookies at second login:

We can see the same token every time. This indicates that tokens are constant.

Why this is vulnerable (in simple terms)

· The server trusts whatever username is inside the cookie

· Tokens never expire or change

· No server-side session tracking

· User identity is controlled by the attacker

Remedies:

· Use server-side session management: Store session data on the server and use the token only as a random session ID, not as a container for user information.

· Generate a new session token on every login: Always issue a fresh, unpredictable token when a user logs in and invalidate any old ones.

· Prevent concurrent sessions (or monitor them): Either allow only one active session per user or actively detect and alert on multiple simultaneous logins.

· Never trust user-controlled data to identify users: Do not embed usernames, roles, or permissions inside tokens unless they are cryptographically protected and verified.

· Expire and invalidate sessions properly: Enforce session timeouts and ensure tokens are destroyed on logout or after inactivity.

Vulnerable Session Termination:

Proper session termination is critical for security because it limits how long a session token can be abused and allows users to safely end their sessions. Many applications fail to do this by allowing sessions to last too long or by implementing weak logout mechanisms that do not invalidate the session on the server. As a result, attackers who obtain session tokens can continue using them even after a user logs out, leading to session hijacking and unauthorized access.

Observing Vulnerable Session Termination on a local website:

App.py:

Browser:

Step1: (Goal: To prove Session never expires.) Just login, and see the session cookie value. Observe it again after hours, we can see that session value never expired.

Step2: (Goal: To prove Logout doesn’t invalidate session.) Logout (Visit /logout).

Manually set the old cookie again, and refresh it again.

The server never destroys the session, so deleting cookies is meaningless.

Client Exposure to Token Hijacking:

If an attacker can steal, predict, or force the use of a session token, they can take over a user’s session — without knowing the password.

Testing concept of Client Exposure to Token Hijacking on a local website:

App.py:

Terminal:

Browser:

Step1: (Goal: Session Fixation testing.) Visit the page, login using the credentials alice:password1.

Following page will occur:

Look for the session id:

Open the same login page in any other browser, and login for the same user, then observe the credentials. We can see that it doesn’t change:

This is a vulnerability.

Step2: (Goal: Checking for the Stored XSS.) Post this as a message: <script>alert(‘XSS’)</script>

Following page will occur:

Now open /messages.

Step3: (Goal: Checking for CSRF.) While logged in, just opening: /transfer?amount=100&to=attacker

· That means the browser automatically sent your session cookie

· The server trusted it without checking where the request came from

· This is exactly the CSRF vulnerability

Liberal Cookie Scope:

Cookies aren’t just “sent back to the same server.” They’re only sent back when the domain and path rules match.

Cookie Domain Restrictions:

Cookies should be shared with as few domains as possible — widening their scope makes it much easier for attackers to steal session data.

· By default, a cookie is sent only to the domain that created it and its subdomains.

· A server can widen this by setting a domain attribute, causing the cookie to be sent to multiple subdomains.

· Browsers restrict this to prevent abuse (cookies can’t be set for unrelated or top-level domains).

· Making cookie domains too broad is dangerous because cookies (like session IDs) may be sent to less trusted or user-controlled subdomains.

· This can allow attackers to steal session cookies using vulnerabilities like cross-site scripting (XSS).

· The safest approach is to scope cookies as narrowly as possible, especially for sensitive applications, often using a fully qualified domain (e.g., www.example.com).

Cookie Path Restrictions:

If a cookie is shared with too many URL paths, a weak app on the same site can steal or abuse it — even if the main app is secure.

A cookie’s path decides which parts of a website receive it, usually limiting it to one folder and its subfolders for safety. If the path is set too broadly (like /apps/ or /), the cookie gets shared with many apps on the same site. This is risky because a weak or test app can access sensitive cookies from a secure app. Path limits help, but they’re not perfect and shouldn’t be the only security protection.

Observing Cookie Path Restrictions Vulnerability:

Package.json:

Terminal:

Server.js:

Terminal:

Browser:

Step1: (Goal: to see if it handles the session id carefully or not). Click Login to Secure App. Open DevTools → Application → Cookies

Notice: sessionId = SECURE-SESSION-12345

Now, click on “Go to test app“, following screen will appear:

Again, see the cookie: sessionId=SECURE-SESSION-12345

Clearly, the test app stole the secure session.

Securing Session Management:

Web applications use session tokens to identify users after login, making them a common target for attackers. Security issues mainly arise from how tokens are created and how they are protected over time. Tokens must be random and unpredictable, and also kept safe from theft, leakage, or reuse throughout their lifetime. In short, apps need to create strong session tokens and protect them from start to finish.

Generate Strong tokens:

· Don’t put meaning inside them

· Make tokens long and random

· Use cryptographically secure randomness

· Mix in request data and a server-only secret

Protect Tokens throughout Their Lifecycle:

Web apps must protect session tokens at every stage of their lifecycle, because any leak lets attackers hijack user sessions. Tokens should only be sent over HTTPS, never placed in URLs, and must be properly destroyed on logout or inactivity, with old sessions invalidated on new logins.

Strong defenses include limiting cookie scope, locking down admin tools, rejecting unknown tokens, regenerating sessions after login, and preventing XSS, CSRF, and session fixation attacks. For sensitive actions, apps should require re-authentication or extra confirmation and avoid exposing or reflecting sensitive data at any point.

Per page tokens:

Per-page tokens are constantly changing mini-tokens that add tight control over every request, quickly stopping hijacking, fixation, and out-of-sequence attacks — even if a session token is stolen.

Per-page tokens are short-lived security codes that change every time you load a page. Each request must include the latest code, or the session is ended. This makes stolen sessions and fake requests much harder to use, but can break back buttons and multiple tabs.

Log, Monitor, and Alert:

A secure web app doesn’t just block attacks; it watches for them and reacts. It logs invalid or fake tokens (many failures = likely attack), keeps an eye on brute-force attempts, and may temporarily block abusive traffic. Even when attacks can’t be stopped right away, logs and alerts let security teams investigate and respond.

Users should also be warned about suspicious activity so they can act fast.

Reactive Session Termination:

Ending a session immediately when suspicious activity occurs is a strong defensive tactic that slows attackers, but it doesn’t replace proper fixes and must be test-friendly.

Contact Me
📧 Email: adii.utsav@gmail.com
🔗 LinkedIn: https://www.linkedin.com/in/aditya-kumar-3241b6286/
💻 GitHub: https://github.com/Rememberful