Ravindra BagaleCourses & study guides मराठी Track your progress

41. Session Hijacking – Tokens, Cookies and Defence

41.1 What Is a Session – Why Hijacking Matters

By Last updated:

Quick answer: the short, self-contained version of this lesson is the guide Zero Trust Security Explained Simply.

HTTP = request/response, server does not remember you by default. After login, server creates a session and gives the browser a session ID (often in a cookie like PHPSESSID / JSESSIONID, sometimes a token). Next requests carry that ID → server looks up "this is Rani, role = owner".

Session hijacking = attacker uses a valid session ID that belongs to someone else, without knowing the password. Password safe rahila – pan identity compromise zali. Interview madhe clear bola: hijack ≠ always cracking the password hash.

Thodkyaat: session token = temporary gate pass. Stolen pass = thief walks in as staff. Samjla ka?

Red team (attacker) does Blue team (defender) detects / stops
Steals / guesses / fixes victim session ID HttpOnly+Secure cookies; regenerate ID on login; short TTL
Replays cookie from another browser / IP Concurrent-session alerts; bind soft signals (UA/IP) carefully
Targets apps that trust cookie alone forever MFA for sensitive actions; logout server-side invalidate

Ravindra Bagale's Tip

Students say "we added HTTPS, so the session is safe forever". HTTPS protects data in transit – but XSS, fixation, weak logout and long-lived tokens can still break you. Use layered session hygiene. Remember this.

Lab

Notes madhe 6-row table: session | session ID | cookie | token | hijacking | fixation – ek-ek line def + one Blue control. Fictional Sahyadri Traders (Nashik) staff portal – Amir login zala, Salman same cookie paste karun dashboard baghto. Kontya CIA property break? 5 sentences.

Extended teaching notes

Why this lesson matters

Web flaws stay in the OWASP Top 10 because real apps still ship them. Your job is not to collect tool screenshots. It is to prevent and fix the class of bug on systems you own.

Apply the fix across stacks

Same class of bug, same idea in every language.

Java / Spring Boot

Parameterise queries, encode output, CSRF tokens, limited Actuator, dependency scanning.

ASP.NET Core

EF Core / parameterised SQL, Razor encoding, HTTPS, Data Protection.

Node.js / Express

helmet, parameterised SQL, npm audit, avoid eval and shell concat.

Python / Django / Flask / FastAPI

ORM, autoescape, pip-audit, Bandit; never shell=True with user input.

PHP / Laravel

PDO/Eloquent, Blade escaping, composer audit.

Go / Ruby

database/sql placeholders / ActiveRecord; html/template / ERB escaping; govulncheck / Brakeman.

nginx / Apache / Tomcat

Hide versions, TLS, security headers, least-open ports.

MySQL / PostgreSQL / MongoDB / Redis

Private networks, auth on, least-privilege users, no 0.0.0.0/0.

AWS / Azure / GCP

Roles not long-lived keys, private data stores, cloud audit logs on.

Real examples

Global: injection and XSS still appear in breach reports and bug bounties every year. Indian company (sample): a Bengaluru SaaS team maps each OWASP item to a CI check or a code-review question so new code cannot silently reintroduce it.

Mini case study

Suppose we are on a purple-team exercise for an Indian mid-size company (sample data). Red notes a technique from this lesson against a lab clone. Blue must show the control that stops it, the log that would have fired, and the ticket that hardens production. That is the standard this course trains you for.

Defender's worksheet (do this today)

  1. Write the lesson title, date and the exact lab target you are allowed to use.
  2. List three owned systems (VMs, apps, or cloud accounts) where this lesson applies.
  3. Run one safe check from the lesson on a lab system only. Paste the command and output.
  4. Write a two-sentence fix you would give a teammate.
  5. Name one related public advisory (CERT-In, CISA, NVD, or a vendor bulletin) with its date.

Indian workplace (sample data)

Suppose we are a junior analyst at Infosys, TCS, Wipro or a fintech SOC in Bengaluru/Pune. Turn this lesson into one checklist item with an owner, a due date and a place to store evidence (ticket + screenshot).

Global practice

Compare your notes with OWASP, CIS Benchmarks, NIST CSF/IR guidance or a cloud Well-Architected security question. Write five lines on what overlaps.

Everyday analogy

Explain the risk and the fix to a family member without jargon. If they can repeat the warning, you understand it well enough to teach juniors.

Key terms

  • Control: a safeguard (patch, config, process, detection).
  • Finding: a weakness backed by evidence.
  • Remediation: the fix plus how you verified it.
  • Scope: systems you have written permission to touch.
  • Least privilege: only the access the task needs.
  • Defence in depth: several layers so one failure does not end the story.

Common mistakes

  • Skipping written permission "just for a quick scan".
  • Practising on hostel, office or public targets without authorisation.
  • Collecting tool output without writing the fix.
  • Copying attack steps onto production to "verify". Defenders verify with versions, configs and patches.
  • Publishing screenshots that contain secrets, cookies or internal hostnames.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.
  • Fix > spectacle.

Real incident: DreamHost – a hacked web File Manager leaked FTP passwords and webmail sessions for about two months (Nov 2026)

1. What happened

In this lesson you learnt that a session is a temporary gate pass. After you log in, the website gives your browser a session token, so you do not type the password again on every page. If someone steals that token, they can walk in as you without knowing your password. This real case shows a thief collecting both passwords and session data from a web host for months.

  • DreamHost is a large US web hosting company and domain registrar. It says it has about 400,000 paying customers.
  • DreamHost gives customers a web-based File Manager (at files.dreamhost.com) to upload and edit their website files from a browser.
  • In late October 2026, DreamHost had an outage that lasted several days. It asked customers to reset their email and FTP/SFTP passwords.
  • On 4 November 2026, BleepingComputer and TechCrunch reported DreamHost's official data breach notice. It says an attacker used a weakness in the File Manager software to get into the server that runs it.
  • The attack ran from about August 2026 to 23 October 2026, the day DreamHost found it. In that time the attacker could get the FTP/SFTP usernames and passwords of people who logged in to the File Manager.
  • The attacker may also have reached DreamHost's webmail systems and taken session information for a small number of users. TechCrunch reports that this included session tokens, which let someone act as a logged-in user.
  • DreamHost says it found no sign that control panel logins or billing and payment details were taken. It says "well under 10%" of customers were affected, and that this was not linked to the recent PHP bugs.
  • DreamHost blocked the attacker, fixed the weakness, ended active sessions for possibly affected users and made their old passwords stop working.

2. How the hack happened (public reporting only – high-level)

  1. The attacker found a weakness in the File Manager web software. DreamHost has not said what it was.
  2. Using it, the attacker got into the server that runs the File Manager, from around August 2026.
  3. Every time a customer logged in to the File Manager, their FTP/SFTP username and password passed through that server, so the attacker could collect them.
  4. The attacker also reached webmail systems and took session details for some users. With a live session, you are already "logged in", so a password reset alone does not throw the thief out.
  5. Nobody noticed for about two months. DreamHost found it on 23 October 2026, then reset passwords and ended sessions.

3. How to stop it / defend (this lesson: sessions)

Why: a stolen password and a stolen session both let a stranger act as you. A password reset fixes only the first one. The server must also end every old session, or the thief stays inside.

What you can do:

  1. End all sessions after any breach. Change the password and also press "sign out of all devices" or ask the provider to end sessions. A good server ends old sessions by itself when the password changes.
  2. Keep sessions short and protected. On your own sites, give session cookies the Secure and HttpOnly flags and a short lifetime (Example 1).
  3. Use SFTP with keys, not plain FTP passwords, and do not reuse your hosting password anywhere else.
  4. Turn on two-step login (MFA) for webmail and the hosting panel where it is offered.
  5. Look for changed website files that you did not change (Example 2).
  6. Check webmail forwarding rules and filters, because a thief can quietly copy your mail to their own address (Example 3).
  7. For hosting companies: patch and watch every login tool you put on the internet, and alert on strange logins, so a break-in is found in days, not months.

Example 1: check how your own site sets its session cookie.

  1. Pick a website that you own, with a login page.
  2. Run curl -sI https://your-own-site.example/login | grep -i set-cookie
  3. Output: one line, like set-cookie: PHPSESSID=8f3a…; path=/; secure; HttpOnly; SameSite=Lax
  4. What it means: secure means the cookie only travels over HTTPS. HttpOnly means page scripts cannot read it. If either word is missing, add it in your app settings.

Example 2: list website files changed in the last 14 days.

  1. Log in to your hosting account with SFTP or SSH.
  2. Run find ~/public_html -type f -mtime -14 -printf '%TY-%Tm-%Td %p\n' | sort | tail -5
  3. Output: the newest changed files, like 2026-10-21 /home/you/public_html/wp-content/uploads/cache.php
  4. What it means: check every file you did not change yourself. A .php file inside an uploads folder is a strong warning sign. Then run a free check on your site from the link below.

Example 3: check webmail forwarding rules.

  1. Log in to your webmail.
  2. Open Settings, then Filters (or Rules), then Forwarding.
  3. Output: a list of rules. Normally you see only rules you made yourself, or an empty list.
  4. What it means: a rule that forwards mail to an address you do not know means someone is copying your mail. Delete it, change the password, and sign out of all sessions.

4. How to take care so it won't happen again (checklist)

  • [ ] After a provider says "we were breached", I change the password and sign out of all sessions.
  • [ ] My hosting, FTP and email passwords are unique and long.
  • [ ] I use SFTP with keys, and MFA on webmail and the hosting panel.
  • [ ] My own sites use Secure and HttpOnly session cookies with a short lifetime.
  • [ ] My sites end old sessions when the password changes.
  • [ ] I look at recently changed website files every month.
  • [ ] I check my webmail forwarding rules and filters.

Source: BleepingComputer, "DreamHost confirms data breach exposed FTP logins and webmail sessions" (Bill Toulas), 4 November 2026; TechCrunch, "Hackers stole DreamHost customer files and inboxes during months-long attack" (Zack Whittaker), 4 November 2026, citing DreamHost's data breach notice filed with the California Attorney General.

Ravindra Bagale's Tip

When your web host says 'please reset your password', do two things, not one. First change the password. Then sign out of every session, because a stolen session does not care about your new password. And if you still log in to your website with plain FTP and a short password, change that today. Use SFTP with a key.

Check if you're safe: Password Strength Checker · Is My Website Hacked?

Real incident update: Chainalysis – password hashes and live tokens for all users were exposed (Nov 4–5 2026)

1. What happened

In this lesson you learnt that a session (and a live token) is a temporary gate pass. After you log in, the service may keep a live token so you stay signed in. If that token is stolen, someone can act as you without your password. This update shows why an earlier "no credentials / no session tokens" message must be treated carefully until the investigation finishes.

  • Chainalysis is a blockchain analytics company. Its public site says it serves more than 1,500 customers, including finance, crypto, regulators, and law enforcement.
  • On about 30 October 2026 Chainalysis first disclosed a security incident. At that time it said it had found no evidence of unauthorized access to authentication credentials or session tokens (it did report some customer profile fields).
  • On the night of 4 November 2026 (11:00 P.M. EST), Chainalysis updated that same blog. It now says names, usernames, password hashes and live tokens for all Chainalysis users were exposed to a malicious actor.
  • While investigating, it had already taken Reactor and Data Solutions offline. On 4 Nov it also found abnormal activity and took KYT (UI and API), other address-screening products, and the login page offline.
  • The company is directly notifying customers whose KYT accounts appear to have been accessed without authorization.
  • Earlier the same day it said a subset of customers had passwords exposed via an on-path attack that it says was contained and remediated; those customers were told to reset passwords and to go to the login page directly, not via email links.
  • Chainalysis still says it has no evidence that investigation data was accessed or that attribution data was manipulated. All users must reset passwords and rotate API keys.
  • The Record (Alexander Martin, 5 November 2026) reported this update and noted that "live tokens" can let an attacker use an account without the password, while hashes can sometimes be cracked offline.

2. How the hack happened (public reporting only – high-level flow)

  1. Earlier notice (30 Oct): an actor using "offensive agentic techniques" reached internal tools; profile data was accessed; credentials/tokens were said not to be.
  2. Further investigation (update 4 Nov night): the company discovered that password hashes and live tokens for all users were also exposed.
  3. A live token is already a "logged in" pass. Stealing it is like stealing a session: password reset alone may not throw the thief out until tokens are revoked.
  4. Separately, a subset of passwords was exposed via an on-path attack (company says contained). Abnormal activity then led to taking KYT and login offline.
  5. Defence move: force password resets, rotate API keys, notify accounts that look accessed, restore access only with extra checks (for example trusted IP allowlists).

3. How to stop it / defend (this lesson: sessions and live tokens)

Why: a password hash is a stored form of the password; a live token is a working session. You must kill both the old password and every old token, or the attacker can stay inside.

What you can do:

  1. Reset the password on the real login page (type the URL yourself). Do not click links in password-reset emails (Example 2).
  2. Revoke / rotate every API key and sign out of all sessions after any "tokens exposed" notice (Example 1).
  3. Turn on MFA everywhere the vendor offers it, and use a unique password (not reused on other sites).
  4. If you reused that password elsewhere, change it there too.
  5. Watch account activity (strange logins, new API keys, unexpected exports) and tell your security team.
  6. For product teams: store password hashes with a modern slow hash, keep session/API tokens short-lived and revocable, and separate investigation data from login stores.

Example 1: end sessions and rotate API keys after a token leak notice.

  1. Open the vendor security / API settings on a trusted device.
  2. Follow a path like # After a vendor says tokens leaked: Settings → Security → Sign out of all sessions / Revoke API keys
  3. Output: a confirmation like All sessions ended. Create a new API key. Old tokens no longer work.
  4. What it means: old live tokens stop working. Create only the new keys you need, store them in a vault, and delete unused ones.

Example 2: reset the password without trusting email links.

  1. Open your browser and type the vendor login URL yourself (Example shape: # Type the login URL yourself in the browser address bar (do not click email links)).
  2. Use the on-site "Forgot password" / reset flow, then sign in with the new password and MFA.
  3. Output: you land on the real reset form, like https://login.example-of-your-vendor.com → reset password form, not a lookalike page from a mail link.
  4. What it means: phishing emails often arrive during real breaches. Typing the URL yourself avoids fake reset pages.

Example 3: check whether an old API key still works (only on systems you own / are allowed to test).

  1. In a safe test environment, call a harmless API status endpoint with the old key after rotation.
  2. Expected output after a good rotation: HTTP 401 / "invalid API key".
  3. What it means: if the old key still works, rotation failed — revoke it again and alert your admin.

4. How to take care so it won't happen again (checklist)

  • [ ] After any "live tokens exposed" notice, I reset the password and revoke all sessions / API keys.
  • [ ] I open the real login page by typing the URL; I do not click reset links in email.
  • [ ] My Chainalysis (and similar) password is unique and MFA is on.
  • [ ] If I reused that password elsewhere, I changed it there too.
  • [ ] I watch for strange logins and new API keys after a breach notice.
  • [ ] On products I build, sessions and API tokens are short-lived and easy to revoke.

Source: Chainalysis official blog, "Updated Nov 4: Chainalysis Security Incident Information", updated 4 November 2026 11:00 P.M. EST (https://www.chainalysis.com/blog/security-incident-october-30/); The Record (Recorded Future News), "Chainalysis warns all users hit in cyber breach involving 'agentic' techniques" (Alexander Martin), 5 November 2026.

Ravindra Bagale's Tip

When a company first says 'no passwords or session tokens were taken' and later updates that hashes and live tokens were exposed, believe the update. Reset the password on the real login page, revoke every API key and session, and never click reset links in email during a live incident.

Check if you're safe: Password Strength Checker