Kiberbiztonsági betekintések

Munkamenet-rögzítés (session fixation): rejtett biztonsági kockázat webalkalmazásokban

ápr 8, 2026

Munkamenet-rögzítés: egy alábecsült támadás

A munkamenet-rögzítés – vagy session fixation – ritkán kerül a fókuszba úgy, mint az XSS vagy az SQL injection. Ennek oka egyszerű: kevésbé látványos, nehezebben érthető, és nem klasszikus támadásként jelenik meg.

Pedig a végeredmény üzleti szempontból ugyanaz: jogosulatlan hozzáférés felhasználói fiókokhoz, gyakran teljesen észrevétlenül.

Mi az a munkamenet-rögzítés?

Egy jól működő webalkalmazás minden sikeres bejelentkezés után új munkamenet-azonosítót (session ID) generál. Ez az az érték, amely alapján a rendszer azonosítja a bejelentkezett felhasználót.

Ha ez nem történik meg, és a rendszer egy már létező munkamenetet használ tovább, akkor megnyílik az ajtó a támadás előtt.

A munkamenet-rögzítés lényege, hogy a támadó nem egy meglévő munkamenetet lop el, hanem egy sajátot hoz létre, majd eléri, hogy az áldozat ezt használja. A folyamat egyszerű:

  • a támadó létrehoz egy ismert munkamenet-azonosítót;
  • ezt valamilyen módon eljuttatja az áldozat böngészőjébe;
  • az áldozat belép az alkalmazásba;
  • a rendszer nem generál új session ID-t, hanem a meglévőt használja tovább.

Ettől a ponttól kezdve a támadó és az áldozat ugyanahhoz a munkamenethez tartozik. Az alkalmazás szemében nincs különbség közöttük.

Milyen kockázatot jelent valójában?

A következmények nem különböznek más account takeover jellegű támadásoktól. A támadó hozzáfér az adatokhoz, műveleteket hajthat végre a felhasználó nevében, és – bizonyos esetekben – át is veheti a fiók feletti irányítást.

Ez különösen akkor problémás, ha a rendszer nem kér újrahitelesítést kritikus műveleteknél. Ilyenkor a támadó módosíthatja a jelszót vagy más hitelesítési adatokat, és kizárhatja a felhasználót.

A nehézség a támadás detektálásában van, hiszen a beavatkozás során minden egy legitim munkamenetből történik, érvényes azonosítóval. Vagyis a szerveroldali naplókban sem feltétlenül jelenik meg egyértelmű anomália. Ez a technikai sérülékenységben rejlő legnagyobb üzleti kockázat, hiszen a hozzáférés nemcsak jogosulatlan, hanem utólag nehezen visszakövethető is.

Hogyan válik kihasználhatóvá?

A munkamenet-rögzítés önmagában is működhet, de a gyakorlatban gyakran más sérülékenységekkel együtt jelenik meg. Klasszikus példa az XSS, ugyanakkor az XSS megszüntetése önmagában nem oldja meg a problémát.

A támadás kulcsa minden esetben az, hogy a támadó elérje, hogy az áldozat böngészőjében egy általa meghatározott munkamenet-azonosító legyen beállítva. Ez több módon is megvalósítható.

Megosztott eszközhasználat esetén – például munkahelyi vagy nyilvános gépeken – a támadó fizikai hozzáféréssel közvetlenül beállíthatja a szükséges cookie-t.

XSS-alapú támadásnál a támadó kliensoldali kódot futtat az áldozat böngészőjében. Ha a munkamenet-cookie HttpOnly védelemmel rendelkezik, közvetlenül nem módosítható, ugyanakkor léteznek kerülőutak is. Ilyen a Cookie Jar Overflow technika, amely a böngészők cookie-limitjét használja ki, és végül lehetővé teszi egy új, támadó által kontrollált session ID beállítását.

Hálózati támadások esetén – ha hiányzik például a Secure flag vagy a HSTS – egy man-in-the-middle támadó képes lehet módosítani a szerver válaszát, és saját munkamenet-azonosítót juttatni a klienshez.

Kevésbé egyértelmű, de valós kockázat az aldomain-kompromittáció. Ha az alkalmazás nem host-only cookie-t használ, egy feltört aldomain képes lehet olyan cookie-t beállítani, amely a fő domainen is érvényes.

Fontos látni azt is, hogy a munkamenet-azonosító nem kizárólag cookie-ban létezhet. Előfordulhat HTTP-fejlécben vagy URL-paraméterként is, a sérülékenység pedig ezekben az esetekben is fennáll.

Miért nem találja meg mindig egy sérülékenységvizsgálat?

A munkamenet-rögzítés tipikusan az a kategória, amely megmutatja a különbséget az eszközalapú és a manuális biztonsági tesztelés között. Egy automatizált sérülékenységvizsgálat képes ellenőrizni a cookie-beállításokat, az ismert sérülékenységeket vagy a konfigurációs hibákat. A session fixation azonban nem egy konkrét konfigurációs hiba, hanem egy alkalmazáslogikai probléma.

A kérdés nem az, hogy van-e HttpOnly flag, hanem az, hogy mi történik bejelentkezés után.

Egy manuális teszt során ez egyértelműen vizsgálható, hiszen a tesztelő előre beállít egy munkamenet-azonosítót, majd megnézi, hogy a rendszer lecseréli-e azt a bejelentkezés után. Ha nem, a sérülékenység fennáll. Ez az a pont, ahol a hagyományos, kizárólag eszköz alapú vizsgálat nem ad teljes képet.

Így védekezhetünk hatékonyan

A legfontosabb védekezési lépés egyszerű: minden sikeres bejelentkezés után új munkamenet-azonosítót kell generálni. Ez nem ajánlás, hanem alapkövetelmény.

Ezen túl a munkamenet- és cookie-kezelés finomhangolása jelentősen csökkenti a kockázatot. A legfontosabb beállítások:

  • megfelelő cookie prefixek használata (pl. __Host-);
  • SameSite attribútum alkalmazása (lehetőleg „strict”);
  • HttpOnly flag beállítása;
  • Secure flag használata;
  • host-only cookie alkalmazása.

Érdemes továbbá a munkamenetet a kliens bizonyos jellemzőihez kötni – például IP-címhez vagy user agenthez. Ez nem ad teljes védelmet, de növeli a támadás költségét.

Felhasználói oldalon fontos a kontroll is, hiszen ha a felhasználó látja az aktív munkameneteit, és képes azokat megszüntetni, jelentősen csökkenti a kitettséget.

És egy gyakran figyelmen kívül hagyott alapelv: kijelentkezéskor a munkamenetet valóban meg kell szüntetni, nem csak kliens oldalon, hanem szerver oldalon is.

Miért marad a munkamenet-rögzítés mégis radar alatt?

A munkamenet-rögzítés nem látványos támadási módszer. Nem tör fel rendszereket, nem hagy egyértelmű nyomokat, és gyakran más sérülékenységek árnyékában jelenik meg.

Pont ezért veszélyes, hiszen a támadás legitimnek tűnik, a hozzáférés valós, a következmények pedig közvetlenül a felhasználói bizalmat érintik. Ezért válik egy látszólag technikai részlet valós üzleti kockázattá.

Azok a szervezetek azonban, amelyek ezt időben felismerik, nemcsak sérülékenységet kezelnek, hanem versenyelőnyt is szereznek maguknak.

Ha szeretnéd látni, hogy a saját alkalmazásod hogyan viselkedik valós támadási helyzetben, érdemes nem csak eszközökre hagyatkozni. Ismerd meg lehetőségeidet!

 

Mit csinál egy etikus hacker? | Útmutató cégeknek

Mit csinál egy etikus hacker? | Útmutató cégeknek

Mit csinál egy etikus hacker – és miért üzleti kérdés ez valójában?  Spoiler: az etikus hacker – polgári nevén pentester –  nem fekete hoodie-ban ül egy sötét alagsorban. Akkor sem, ha a hollywoodi hackermítosz ezt a képet égette belénk. De akkor mit csinál valójában?...

tovább...

Security Starts With a Conversation

Skip the sales pitch. Have a high-level conversation about your business
continuity and operational risk.