Jelszót sem kell szerezni: session-lopás

Egy weboldal adminisztrációs felületére nem csak a jelszó megszerzésével lehet bejutni. Session-lopás: ha egy támadó ellopja egy már bejelentkezett felhasználó érvényes munkamenetét (session) bizonyos esetekben a belépési folyamat megismétlése nélkül használhatja az oldalt az áldozat nevében.

Ez azért különösen veszélyes, mert a támadónak ilyenkor nem feltétlenül kell ismernie a felhasználó jelszavát, és a már sikeresen teljesített kétfaktoros hitelesítést sem kell újra végrehajtania. A kiszolgáló érvényes munkamenetet lát, ezért a kéréseket mindaddig a valódi felhasználóhoz kapcsolhatja, amíg a munkamenet le nem jár vagy érvénytelenítik.

A session-lopás nem WordPress- vagy Joomla-specifikus jelenség. Minden olyan webalkalmazást érinthet, amely munkamenettel tartja nyilván a bejelentkezett felhasználókat.

Mi az a session, vagyis munkamenet?

Belépéskor a weboldal ellenőrzi a felhasználónevet, a jelszót, és – ha be van kapcsolva – a második hitelesítési tényezőt (2FA). Sikeres azonosítás után nem kéri be ezeket minden egyes oldalbetöltésnél. Ehelyett létrehoz egy időben korlátozott, egyedi munkamenetet.

A böngésző rendszerint egy sütiben tárolja a munkamenethez tartozó azonosítót vagy hitelesítési tokent, majd a további kéréseknél automatikusan elküldi azt a weboldalnak. Ez olyan, mint egy ideiglenes belépőkártya: igazolja, hogy a bejelentkezés korábban már megtörtént.

A WordPress hivatalos dokumentációja szerint a rendszer több hitelesítési sütit használ. Ezek közé tartozik a wordpress_sec_[hash] és a wordpress_logged_in_[hash]. A WordPress ellenőrzi többek között a süti lejáratát és hitelesítő kódját, majd érvényes süti esetén azonosítja a felhasználót. A Joomla szintén sütire és szerveroldali munkamenet-adatokra támaszkodik annak megállapításakor, hogy ki van bejelentkezve és milyen jogosultságokkal rendelkezik.

Mi történik session-lopáskor?

Session-lopáskor a támadó megszerzi vagy átveszi egy érvényes munkamenet használatát. Ezt nevezik munkamenet-eltérítésnek, angolul session hijackingnek.

Az OWASP meghatározása szerint az érvényes munkamenetsüti birtokában a támadó megszemélyesítheti a felhasználót. A lehetséges kár ezért nem a süti tartalmától, hanem az érintett felhasználó fiók jogosultságától függ.

Érintett fiók	Lehetséges következmény
Látogató vagy előfizető	Személyes adatok, rendelési adatok vagy csak bejelentkezve elérhető tartalmak megtekintése
Webáruházi vásárló	Profil-, cím- és rendelési adatok elérése, a fiók beállításainak módosítása
Szerző vagy szerkesztő	Tartalmak módosítása, törlése vagy kártékony linkek elhelyezése
WordPress-adminisztrátor vagy Joomla Super User	Új felhasználó létrehozása, bővítmény vagy kiterjesztés telepítése, kódmódosítás, átirányítás, adatlopás, tartós hátsó kapu létrehozása

Adminisztrátori munkamenet megszerzése tehát teljes weboldal-kompromittálódáshoz is vezethet. A legkisebb jogosultság elve ezért itt is alapvető: aki csak tartalmat szerkeszt, annak ne legyen rendszergazdai hozzáférése.

Jelszólopás, session-lopás és CSRF: nem ugyanazok

Támadás	Mit szerez vagy használ a támadó?	Új bejelentkezés szükséges?
Jelszólopás	Felhasználónév és jelszó	Igen; a 2FA ezt még megállíthatja
Session-lopás	Már hitelesített munkamenet vagy süti	Általában nem, amíg a munkamenet érvényes
CSRF	Az áldozat böngészőjével hajtat végre egy kérést	Nem veszi át feltétlenül a munkamenetet; a böngésző küldi el a sütit
XSS	Kártékony kód fut az érintett weboldal környezetében	A kód adatot lophat vagy műveleteket végezhet a bejelentkezett felhasználó nevében

A CSRF tehát nem feltétlenül lopja el a sessiont, hanem kihasználja, hogy a böngésző a weboldalnak küldött kérésekhez automatikusan hozzáadja a sütiket. Az XSS pedig akkor is végrehajthat jogosult műveleteket az áldozat böngészőjében, ha a HttpOnly beállítás miatt magát a sütit nem tudja JavaScriptből kiolvasni. Az OWASP CSRF-útmutatója ezért a keretrendszer saját védelme, a szerveroldalon ellenőrzött CSRF-tokenek és további védelmi rétegek használatát javasolja.

Hogyan kerülhet a munkamenet a támadóhoz?

1. XSS-sebezhetőség a CMS-ben vagy egy kiegészítőben

Egy hibás sablon, WordPress-bővítmény vagy Joomla-kiterjesztés lehetővé teheti idegen JavaScript futtatását a weboldalon. A kód megpróbálhat érzékeny adatot továbbítani, módosíthatja az adminfelületet, vagy az aktív felhasználó nevében indíthat kéréseket.

A HttpOnly attribútum megakadályozza, hogy a böngészőben futó JavaScript közvetlenül kiolvassa az adott sütit, de nem teszi ártalmatlanná az XSS-t. A biztonságos kimeneti kódolás, a bevitel megfelelő tisztítása, a naprakész komponensek és egy jól kialakított Content Security Policy együtt csökkentik a kockázatot. Az OWASP XSS-megelőzési útmutatója is több, egymást kiegészítő védelmi réteget ír le.

2. Kártékony program az adminisztrátor számítógépén

Egy információlopó kártevő, fertőzött böngésző vagy rosszindulatú böngészőbővítmény hozzáférhet böngészési adatokhoz, hitelesítő adatokhoz vagy munkamenetekhez. Ebben az esetben hiába megfelelően védett maga a CMS: a támadás a felhasználó eszközén történik.

Ezért a weboldal biztonsága nem ér véget a szervernél. Az adminisztrációra használt gép frissítése, kártevővédelme és a felesleges böngészőbővítmények eltávolítása ugyanúgy része a védelemnek.

3. Nem biztonságos vagy hibásan beállított HTTPS

Titkosítatlan HTTP-kapcsolaton a hálózati forgalom lehallgatható vagy módosítható. A Secure attribútummal ellátott süti csak HTTPS-kapcsolaton küldhető el. Az OWASP munkamenet-kezelési ajánlása szerint az egész webhelyen következetesen HTTPS-t kell használni, a munkamenetsütiket pedig megfelelő Secure, HttpOnly és SameSite attribútumokkal kell beállítani.

A HTTPS nagyon fontos, de önmagában nem véd a böngészőn futó kártékony kódtól, egy fertőzött számítógéptől vagy a szerveren kihasznált sérülékenységtől.

4. Adathalászat közbeékelődő proxyval

Fejlettebb adathalász támadásnál a hamis oldal közvetítőként továbbítja a felhasználó kéréseit a valódi szolgáltatás felé. Az áldozat megadhatja a jelszavát és a második faktort is, miközben a támadó megszerzi a létrejött hitelesített munkamenetet.

Ez az úgynevezett adversary-in-the-middle módszer jól mutatja a session-lopás lényegét: a 2FA a belépést védi, a később használt munkamenetet külön is védeni kell. A Microsoft egy dokumentált támadássorozatában a közbeékelődő adathalász rendszer a jelszó mellett a már hitelesített session sütijét is megszerezte, így a támadók a 2FA használata ellenére átvehették a munkamenetet.

5. Feltört szerver, kiszivárgott mentés vagy hibás naplózás

Ha a támadó hozzáfér a tárhelyhez, az adatbázishoz, a sessiontárolóhoz vagy egy nem megfelelően védett biztonsági mentéshez, munkamenet-adatok is veszélybe kerülhetnek. Szintén kockázatos, ha érzékeny token URL-be, hibakeresési naplóba vagy külső analitikai rendszerbe kerül.

Munkamenet-azonosítót ezért nem szabad URL-ben továbbítani vagy naplózni.

6. Session fixation

Munkamenet-rögzítéskor a támadó nem feltétlenül ellopja az áldozat által kapott azonosítót, hanem ráveszi, hogy egy előre ismert sessionnel jelentkezzen be. Ha a rendszer belépéskor vagy jogosultságváltozáskor nem hoz létre új azonosítót, a támadó később felhasználhatja a korábban ismert értéket. Ezért az azonosítót hitelesítéskor és jogosultságváltozáskor meg kell újítani; ezt egy hibás fejlesztésű bővítmény vagy külső azonosítási megoldás is elmulaszthatja.

Mennyire gyakori WordPress és Joomla oldalakon?

A session-lopás technikailag mindkét CMS-nél (Tartalommenedzsment Rendszer) lehetséges, ahogyan Drupal, Magento, egyedi PHP-rendszer vagy más bejelentkezést használó webalkalmazás esetén is. Nem a CMS márkája dönti el a kockázatot, hanem többek között az alábbiak:

• van-e kihasználható XSS- vagy más sérülékenység a magban, sablonban vagy kiegészítőben;
• naprakész-e a CMS és minden hozzá tartozó komponens;
• megfelelően működik-e a HTTPS és a sütik védelme;
• mennyire biztonságosak az adminisztrációra használt eszközök;
• meddig érvényesek a munkamenetek, és visszavonhatók-e;
• milyen jogosultsággal rendelkezik az érintett felhasználó;
• van-e használható biztonsági és felhasználói műveleti napló.

A lopott sessionnel érkező kérés a kiszolgáló számára érvényesen hitelesített forgalomnak tűnhet, így az esetet nem mindig lehet pusztán a hozzáférési naplóból elkülöníteni egy szabályos belépéstől. A naplóban látható szokatlan IP-cím vagy böngésző fontos jel, de önmagában nem bizonyíték: mobilhálózat, VPN vagy szolgáltatói címfordítás miatt legitim munkamenetnél is változhat.

Megvéd a kétfaktoros hitelesítés?

A 2FA (kétfaktoros hitelesítés) továbbra is az egyik legfontosabb védelem a gyenge, újrahasznált vagy ellopott jelszavakra épülő támadásokkal szemben. Az OWASP többtényezős hitelesítési útmutatója különösen a brute-force, a credential stuffing és a password spraying elleni szerepét emeli ki. Be kell kapcsolni minden WordPress-adminisztrátornál és Joomla Super Usernél.

Ugyanakkor a 2FA nem helyettesíti a session védelmét. Ha a támadó a sikeres belépés után létrejött munkamenetet szerzi meg, a kiszolgáló nem feltétlenül kér újabb hitelesítést. Ez nem a 2FA hibája: a támadó a már jóváhagyott állapotot használja fel. Érzékeny műveleteknél ezért indokolt lehet az újbóli hitelesítés, gyanús session esetén pedig annak azonnali érvénytelenítése.

Milyen jelek utalhatnak munkamenet-visszaélésre?

• Tartalom, felhasználó vagy beállítás módosult, de nem látható hozzá új, sikeres belépés.
• Egy aktív munkamenet közben hirtelen megváltozik az IP-cím, a böngésző vagy a User-Agent.
• Rövid időn belül egymástól távoli helyekről történnek azonos felhasználóhoz kapcsolható műveletek.
• A felhasználót váratlanul kijelentkezteti a rendszer, vagy ismételten újra kell azonosítania magát.

Fontos: egyetlen ilyen jel önmagában nem bizonyít session-lopást. A webszerver-, alkalmazás-, biztonsági és tárhelynaplókat együtt, időrendben kell vizsgálni. A normál access log általában nem tartalmazhatja a sütik értékét, ezért abból egy ellopott session használata sokszor nem azonosítható egyértelműen.

Hogyan csökkenthető a kockázat?

1. Frissítsük a teljes rendszert

Nem elég csak a WordPress- vagy Joomla-magot frissíteni. A sablonok, bővítmények, kiterjesztések, PHP-verzió és a kiszolgáló komponensei is részei a támadási felületnek. A nem használt elemeket ne csak kapcsoljuk ki, hanem távolítsuk el.

2. Használjunk mindenhol HTTPS-t

A teljes weboldal és az adminfelület kizárólag HTTPS-en működjön. A HTTP-kérések egyetlen, közvetlen átirányítással érkezzenek a kanonikus HTTPS-címre.

3. Ellenőrizzük a munkamenetsütik beállításait

A hitelesítési sütiknél a Secure, HttpOnly és az adott működéshez illő SameSite attribútum szükséges. A Domain és Path hatókör ne legyen indokolatlanul tág. Ezeket nem érdemes találomra, .htaccess-ből vagy általános kódrészlettel felülírni: a tényleges Set-Cookie válaszfejlécet kell ellenőrizni, és a CMS, a PHP, a proxy, a gyorsítótár és az esetleges CDN működését együtt kell figyelembe venni.

4. Csökkentsük a munkamenetek élettartamát

Minél tovább érvényes egy session, annál tovább használható egy ellopott token is. Adminisztrátori fióknál csak indokolt esetben használjuk az „Emlékezz rám” lehetőséget, és állítsunk észszerű inaktivitási időkorlátot. Az OWASP szerint a rövidebb élettartam csökkenti a munkamenet-eltérítés időablakát.

5. Kapcsoljuk be a 2FA-t, de ne tekintsük teljes megoldásnak

A 2FA erősen csökkenti a jelszóalapú fiókátvétel esélyét, de a sessiont, a böngészőt és az adminisztrátori eszközt külön is védeni kell.

6. Előzzük meg az XSS-t

Saját fejlesztésnél a kimenetet a megfelelő környezet szerint kell escape-elni, a beérkező HTML-t engedélyezési lista alapján tisztítani, az URL-eket és attribútumokat validálni. A CSP hasznos második védelmi réteg, de nem helyettesíti a hibás kód kijavítását.

7. Védjük az adminisztrációra használt eszközt

• Az operációs rendszer, böngésző és vírusvédelem legyen naprakész.
• Csak szükséges, megbízható böngészőbővítmény maradjon telepítve.
• Adminisztrációhoz célszerű külön böngészőprofilt használni.
• Ismeretlen vagy közös számítógépről ne lépjünk be az adminfelületre.
• Megosztott eszközön ne mentsük el a jelszót, és ne használjuk az „Emlékezz rám” lehetőséget.

8. Korlátozzuk a jogosultságokat és a támadási felületet

Ne használjunk Super User vagy adminisztrátori fiókot egyszerű tartalomszerkesztésre. Kapcsoljuk ki a nem használt távoli belépési és API-funkciókat, de csak azokat, amelyekre valóban nincs szükség. Az adminfelület IP-korlátozása erős kiegészítő védelem lehet állandó címeknél, de mobil vagy változó IP esetén könnyen kizárhatja a jogos felhasználót is.

9. Legyen naplózás és rendszeres ellenőrzés

A hozzáférési napló mellett szükség van alkalmazásszintű műveleti naplóra is: ki, mikor, melyik felhasználóval, milyen adminisztrációs változtatást végzett. A naplókat célszerű a weboldaltól elkülönítve is megőrizni, mert egy adminisztrátori hozzáférést szerző támadó a helyben tárolt nyomokat módosíthatja vagy törölheti.

Külön ellenőrzőlista WordPresshez

1. A WordPress, minden bővítmény és sablon legyen támogatott, naprakész verzión.
2. Ellenőrizzük, hogy a home és siteurl egyaránt HTTPS-cím, és az adminisztráció nem érhető el titkosítatlan HTTP-n.
3. Minden adminisztrátornál legyen 2FA; a felesleges adminfiókokat töröljük vagy fokozzuk le.
4. A Felhasználók → Profil oldalon használjuk a más munkamenetek kijelentkeztetésére szolgáló lehetőséget, ha ismeretlen vagy szükségtelen bejelentkezés gyanúja merül fel.
5. WP-CLI hozzáférésnél egy felhasználó munkamenetei listázhatók és visszavonhatók: wp user session list FELHASZNALO wp user session destroy FELHASZNALO --all A parancsok működését a WordPress hivatalos WP-CLI dokumentációja ismerteti.
6. Incidens esetén az egyedi hitelesítési kulcsok és SALT-ok cseréje érvényteleníti a meglévő WordPress-sütiket, ezért mindenkit kijelentkeztet. Előtte készüljön mentés, és ellenőrizni kell, hogy valamelyik bővítmény nem használja-e ugyanezeket a kulcsokat saját titkosított adatainak kezelésére.
7. A wp-login.php, wp-admin és a bejelentkezett felhasználóknak adott válaszok ne kerüljenek nyilvános oldalgyorsítótárba.
8. Az adminból történő fájlszerkesztést célszerű tiltani, ha nincs rá üzleti szükség, de ez önmagában nem akadályoz meg egy feltöltési vagy szerveroldali kódfuttatási sérülékenységet.

Külön ellenőrzőlista Joomlához

1. A Joomla-mag, a sablonok és az összes kiterjesztés legyen támogatott, naprakész verzión.
2. A Globális konfigurációban a HTTPS kényszerítése az egész webhelyre vonatkozzon, ha a tárhely és a tanúsítvány megfelelően működik.
3. A Munkamenet élettartama ne legyen indokolatlanul magas. A Joomla dokumentációja is arra figyelmeztet, hogy ezt az értéket nem célszerű túl magasra állítani.
4. A megosztott front-end/back-end session csak akkor legyen bekapcsolva, ha valóban szükséges; kikapcsolt állapotban a két felület nem használ közös munkamenetet.
5. Minden Super Usernél legyen többtényezős hitelesítés, és napi tartalomszerkesztéshez alacsonyabb jogosultságú fiókot használjunk.
6. Engedélyezzük és rendszeresen ellenőrizzük a felhasználói műveletek naplózását, különösen az adminisztrátori változtatásokat, kiterjesztéstelepítést és felhasználókezelést.
7. Gyanú esetén ne csak a böngészőből jelentkezzünk ki: az érintett felhasználó aktív szerveroldali munkameneteit is érvényteleníteni kell. Ennek pontos módja a Joomla-verziótól és a beállított session handlertől függ, ezért a munkamenettábla vaktában történő SQL-törlése helyett verzióhoz illő adminisztrációs vagy szakértői eljárást használjunk.
8. A Joomla configuration.php, a mentések és a naplókönyvtár ne legyen nyilvánosan elérhető, a fájljogosultságokat pedig a tárhely működéséhez szükséges legszűkebb értékre állítsuk.

Mit tegyünk, ha session-lopásra gyanakszunk?

1. Tiszta eszközről kezdjük a beavatkozást. Ha az adminisztrátori gép fertőzött, az új jelszó és az új session is azonnal kiszivároghat.
2. Őrizzük meg a naplókat és az időpontokat. Mentsük a webszerver-, PHP-, biztonsági, tárhely- és felhasználói műveleti naplókat. A bizonyítékmentés ne késleltesse az aktív támadás megszakítását.
3. Érvénytelenítsük az aktív munkameneteket. Elsőként a magas jogosultságú fiókokét, ismeretlen hatókör esetén pedig valamennyi felhasználóét.
4. Cseréljük le a jelszavakat és a hozzáféréseket. CMS, tárhely, FTP/SFTP/SSH, adatbázis, e-mail és kapcsolódó külső szolgáltatások. A cserét tiszta eszközről végezzük.
5. Állítsuk helyre a 2FA-t. Ellenőrizzük a regisztrált hitelesítő eszközöket, tartalékkódokat és helyreállítási címeket.
6. Szüntessük meg a kiváltó okot. Frissítsük vagy távolítsuk el a sérülékeny komponenst, javítsuk az XSS-t vagy a hibás sessionkezelést, és vizsgáljuk át az adminisztrátori eszközt.
7. Keressünk tartós hozzáférést (backdoor). Új adminfiók, webshell, módosított rendszerfájl, ismeretlen cronfeladat, kártékony bővítmény, átirányítás vagy külső JavaScript maradhatott a rendszerben.
8. Vizsgáljuk meg a kárt és az adatvédelmi kötelezettségeket. Ellenőrizzük, milyen adatokhoz és funkciókhoz fért hozzá az érintett fiók, és szükséges-e értesítés vagy hatósági bejelentés.
9. Figyeljük tovább a rendszert. Egy sikeres kijelentkeztetés még nem bizonyítja, hogy a támadó minden hozzáférési útját (backdoor) megszüntettük.

Az OWASP cookie-lopás elleni útmutatója szerint gyanús munkamenetnél a megbízható ellenőrzés az újbóli hitelesítés: a régi sessiont érvényteleníteni kell, majd új sütit kell kiadni a felhasználónak.

Gyakori kérdések

A jelszó megváltoztatása elég?

Nem minden rendszerben és nem minden incidensnél szabad erre hagyatkozni. A biztonságos eljárás a jelszó cseréje mellett az érintett munkamenetek kifejezett visszavonása. Ha a támadó a szerveren vagy az adminisztrátori gépen is megmaradt, az új hozzáférési adatok ismét kiszivároghatnak.

A kijelentkezés megszünteti a támadó sessionjét is?

A szokásos kijelentkezés rendszerint az aktuális böngésző munkamenetét zárja le. Más eszközök vagy párhuzamos sessionök megszüntetéséhez a „kijelentkezés mindenhol”, a szerveroldali session-visszavonás vagy az adott CMS megfelelő adminisztrációs eszköze szükséges.

A HttpOnly teljesen megvéd az XSS-től?

Nem. Megakadályozhatja, hogy a JavaScript közvetlenül kiolvassa a sütit, de a weboldalon futó kártékony kód ettől még indíthat kéréseket az áldozat nevében vagy más adatokat lophat.

A biztonsági bővítmény kivédi a session-lopást?

Egy jól beállított biztonsági bővítmény vagy Joomla-kiterjesztés segíthet a naplózásban, a gyanús viselkedés felismerésében, a 2FA-ban és egyes támadások blokkolásában. De nem helyettesíti a frissítést, a biztonságos kódot, a HTTPS-t, a megfelelő cookie-beállításokat és a tiszta adminisztrátori eszközt.

A naplókból biztosan megállapítható a session-lopás?

Nem mindig. Egy ellopott, de érvényes süti használata hasonlíthat szabályos hitelesített forgalomra. A naplóelemzés megmutathat időbeli, IP-, böngésző- és műveleti eltéréseket, de az eredményt a CMS állapotával, a fájlmódosításokkal és az érintett eszköz vizsgálatával együtt kell értékelni.

Összegzés

A session-lopás lényege, hogy a támadó nem feltétlenül töri fel a jelszót: egy már hitelesített állapotot vesz át. Emiatt a jelszóvédelem és a 2FA mellett a munkamenetek biztonságos kezelése, rövid élettartama, visszavonhatósága, a teljes HTTPS, az XSS elleni védelem, a naprakész CMS és a tiszta adminisztrátori eszköz egyaránt szükséges.

Ahogy a webbiztonság más területein, itt sincs egyetlen kapcsoló, amely minden támadást kizár. Biztonsági szintek és egymást erősítő védelmi rétegek vannak. A weboldal tulajdonosa, fejlesztője és üzemeltetője közösen felel azért, hogy egy ellopott munkamenet esélye és következménye a lehető legkisebb legyen.

A Tisztább magyar webért! kezdeményezés célja, hogy minél több hazai weboldal kapjon időben segítséget a fertőzések és sérülékenységek felismeréséhez. Ha WordPress- vagy Joomla-oldaladon jogosulatlan módosítást, ismeretlen adminisztrátort vagy más fertőzésgyanús jelet lát, kérjen biztonsági átvizsgálást és helyreállítást.