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

41. Session Hijacking – Tokens, Cookies and Defence

41.8 Defence Hardening Checklist

By Last updated:

SME / lab checklist (print for Rani):

  1. HTTPS everywhere on auth and cookies; HSTS
  2. Cookie flags: Secure, HttpOnly, SameSite=Lax (or Strict where UX allows)
  3. Regenerate session ID on login and privilege elevation
  4. Short idle / absolute TTL; "remember me" = separate hardened design
  5. Logout destroys server-side session, not only browser cookie clear
  6. MFA for admin / payout / email-change
  7. CSRF tokens on state-changing requests
  8. XSS hygiene + CSP on app pages
  9. Avoid SID in URL; avoid tokens in localStorage for high-value sessions when cookie pattern fits
  10. Monitor concurrent sessions; admin "kill sessions" button
  11. WAF rules for common session abuse patterns (support, not sole control)
  12. Framework updates – session libs have CVEs historically
<?php
// OWN lab PHP sketch – after password verified (illustrative)
session_start();
// ... verify password against DB (prepared statements) ...
session_regenerate_id(true);
$_SESSION['user'] = 'rani';
$_SESSION['login_at'] = time();
// php.ini / ini_set ideas for lab:
// session.cookie_httponly = 1
// session.cookie_secure = 1   // needs HTTPS
// session.cookie_samesite = Lax
?>
Red team (attacker) does Blue team (defender) detects / stops
Hopes logout only cleared client cookie Server-side session destroy + new ID
Uses week-old stolen cookie Short TTL + idle timeout + absolute timeout
Targets admin without MFA MFA + regenerate + alert on admin UA/IP change

Ravindra Bagale's Tip

Make the checklist your wallpaper – but prove it with curl before/after in the lab. A paper policy without regenerate = false comfort. Interview: walk through 5 controls without reading your notes.

Practice task

Score Sahyadri Traders current fictional portal 0–12 on the checklist. Pick worst 3 gaps; write owner email in professional English proposing fix order (HTTPS → flags → regenerate → TTL → MFA).

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: Onamae.com Desktop Cloud (Japan) – stolen trading logins used for unauthorized trades; changing the password was not enough (Oct 2026)

1. What happened

In this lesson's checklist you saw two lines: "Logout destroys the server-side session" and "admin kill sessions button". This real case shows why those lines matter. Here, a new password alone did not lock the attacker out.

  • Onamae.com Desktop Cloud is a Windows cloud server (VPS) service from GMO Internet in Japan. Many people used it to run trading tools such as MT4/MT5 all day and night for FX and stock trading.
  • On 20 October 2026, GMO confirmed that a third party had installed malicious programs on some customer servers. A customer question on 19 October started the investigation.
  • From 21 October, GMO shut down the servers of all plans. Up to 26,739 servers may be affected (this is the number that may be affected, not confirmed cases).
  • On 24 October, GMO confirmed that its system had security weaknesses, that customer information was taken out, and that some customers saw trades in their trading accounts that they did not make.
  • The attacker asked GMO for money. It threatened to keep placing bad orders in customer accounts at more than 70 securities and FX companies, and to publish data. GMO refused to pay and gave the evidence to the police.
  • GMO said it will not restart the old system. It will pay every current customer 5,000 yen and pay back realized losses from unauthorized trades.

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

  1. Customers rented a Windows server and saved their trading account logins inside trading tools on that server.
  2. The attacker got into the service's environment through security weaknesses in GMO's system. GMO has not yet published the exact entry route; an outside security firm is still investigating.
  3. The attacker installed malicious programs on customer servers.
  4. It took information stored on the servers, including saved trading logins.
  5. It used that access to place orders in customers' trading accounts.
  6. GMO warned that even after a password change, an already logged-in session could stay active for some time on some brokers' servers. So the attacker might keep trading. GMO asked customers to disconnect all sessions, and asked brokers to force-close all sessions coming from the service.

3. How to stop it / defend (this lesson: the session defence checklist)

Why: a password protects the next login. It does not end a session that is already open. So "change password" and "kill all sessions" must always go together.

If you build a login system (for example, a broker or banking app):

  1. On password change or reset, delete all of that user's sessions on the server, not only the current browser cookie. Example in PHP: keep a number like session_version in the users table, add 1 on password change, and on every request compare it with the number saved in $_SESSION; if they differ, call session_destroy().
  2. Give users a "Log out of all devices" button, and give your support team an admin "kill sessions" button.
  3. Ask for MFA again before money actions (a trade, a withdrawal, a new bank account), even inside a logged-in session.
  4. Use a short idle timeout and an absolute timeout, so old sessions die on their own.
  5. Alert the user when a new device or a new network starts a session, and show a list of active sessions.

If you run servers for other people (a cloud or hosting provider):

  1. Keep your management systems separate from customer servers, so one break-in cannot reach every customer.
  2. Watch for new programs appearing on many customer servers at once, and be ready to shut down fast (GMO started shutting servers within about a day of confirming the malware).

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

  • [ ] After any account scare: change the password from a clean device, then log out of all sessions, then check the history.
  • [ ] Turn on two-step verification on trading, bank and email accounts.
  • [ ] Do not keep passwords as plain text or saved logins on a shared or rented server. Use a password manager and a different password for each service.
  • [ ] Builders: test it yourself – log in on two browsers, change the password in one, and check that the other one is logged out.
  • [ ] Builders: require fresh MFA for every money action.
  • [ ] Never pay a blackmailer. Paying does not guarantee the stolen data is deleted. Report it to the police.
  • [ ] After an incident, expect fake "refund" or "compensation" emails. Never share a password or PIN because of such a message.

Source: GMO Internet, "Notice and Apology Regarding Unauthorized Access to Onamae.com Desktop Cloud" – Third Report (23 October 2026) and Fourth Report (24 October 2026); GMO Internet, "Renewed Request to Customers Using Onamae.com Desktop Cloud" – Fifth Report (24 October 2026); BleepingComputer, "Japan's Onamae Desktop Cloud hacked, up to 27,000 servers affected", 21 October 2026.

Check if you're safe: Password Strength Checker