Adatlopás és adathalászat: a látogató kitölti az űrlapot, megkapja a visszaigazolást, és folytatja a böngészést. A működés látszólag rendben van. A biztonsági vizsgálat kérdése azonban az is, hogy az adat valóban csak a jóváhagyott helyekre került-e, és kizárólag az arra jogosultak férhettek-e hozzá.
Az adatlopásnak nem feltétele a feltűnő elváltozás. A MITRE például olyan kompromittált belépési felületet ismertet, amely a megadott hitelesítési adatokat a rendes beléptetés előtt rögzíti. A felhasználó így működő szolgáltatást láthat, miközben az adatai veszélybe kerülnek. [1]
Cikksorozatunk ötödik részében az adatlopó kódokat és a webes adathalászatot mutatjuk be. Külön tárgyaljuk a böngészőben futó szkripteket, a szerveroldali adatkezelést, a fizetési felületeket és a kivizsgálás bizonyítási kérdéseit. WordPress- és Joomla-kitekintés is segíti az eligazodást.
Adathalászat és adatlopó kód: mi a különbség?
Az adathalászat, angolul phishing, megtévesztéssel próbál érzékeny információt megszerezni. A támadó például megbízható szereplőnek adja ki magát, és arra veszi rá a felhasználót, hogy adatokat adjon meg. A NIST meghatározásai között hamis weboldalakon keresztüli adatgyűjtés is szerepel. [2]
Az adatlopó kód a technikai működést írja le: a program jogosulatlanul rögzít, olvas ki vagy továbbít adatot. Működhet egy megtévesztő felület részeként, de egy valódi szolgáltatásba beillesztve is. [1]
| Helyzet | A visszaélés lényege |
|---|---|
| Hamis belépési oldal | A látogató megtévesztő felületen ad meg adatot. |
| Módosított valódi űrlap | A megadott adatot a jóváhagyott működés mellett jogosulatlanul is kezelik. |
| Adatbázis jogosulatlan kiolvasása | A korábban tárolt adatokhoz szereznek hozzáférést. |
| Munkamenet megszerzése | A bejelentkezett állapothoz tartozó azonosító kerül veszélybe. |
A táblázat vizsgálati helyzeteket különít el. Egy konkrét incidens több sort is érinthet.
Kitalált példa: egy valódi honlaphoz banki belépésnek látszó aloldalt adnak hozzá. Másik esetben a honlap eredeti ajánlatkérője marad a helyén, de egy beillesztett szkript másolatot készít az adatokról. Az első példában a megtévesztő felület, a másodikban a módosított adatkezelés a központi elem.
Egy feltört honlap más szolgáltatás nevében is gyűjthet adatot
A Google biztonsági útmutatója szerint támadók egy ártalmatlan weboldal felett megszerzett irányítással megtévesztő tartalmat helyezhetnek el, vagy új oldalakat hozhatnak létre személyes adatok megszerzésére. Az ilyen működés beágyazott külső tartalomból is származhat. [3]
Az adathalász felület tehát nem feltétlenül a megtámadott weboldal saját szolgáltatását utánozza. A kivizsgálásnak azt kell feltárnia, milyen adatot kér, kinek adja ki magát, és mi történik a megadott információval.
A Search Console Biztonsági problémák jelentése tartalmazhat ilyen jelzést. A megadott példacímek azonban nem teljes leltárt jelentenek, ezért a javítást az összes érintett működésre ki kell terjeszteni. [4]
Böngészőoldali adatlopás: amikor az űrlapot figyeli a szkript
Az oldalban futó JavaScript hozzáférhet az adott környezetben elérhető tartalomhoz. Az OWASP a külső JavaScript-függőségek egyik kockázataként az érzékeny információk harmadik félhez kerülését is tárgyalja. [5]
Kitalált példa: egy kapcsolatfelvételi oldal jogosulatlan szkriptje a név, e-mail-cím és üzenet tartalmát külön hálózati kérésben elküldi. A rendes beküldés közben változatlanul működik. Ebben a példában a sikeres visszaigazolás nem ad választ a párhuzamos adatküldésre.
A vizsgálatban ezért az oldal saját kódját és a külső forrásból betöltött programokat is azonosítani kell. A saját tárhely változatlan fájljai önmagukban nem írják le a külső szkript aktuális tartalmát. [5]
Az XSS, vagyis cross-site scripting az egyik módja annak, hogy nem megbízható adat végrehajtható kódként kerüljön a böngészőbe. A megfelelő védelem a megjelenítés környezetétől is függ. [6]
Technikai magyarázat: A kód tárolási helye és futásának helye külön kérdés. Kitalált példa: a szkriptet egy adatbázisban tárolt HTML-blokk tartalmazza, de a látogató böngészőjében hajtódik végre. A böngészőoldali tünet miatt az adatbázist sem lehet automatikusan kizárni a vizsgálatból.
E-skimming: fizetési adatok megszerzése a webes felületen
Az e-skimming a webes fizetési folyamat során történő adatlopás megnevezése. A PCI Security Standards Council útmutatója külön foglalkozik a fizetési oldalakon futó szkriptek engedélyezésével, integritásuk ellenőrzésével és a jogosulatlan változások észlelésével. [7]
Az érintettséghez pontosan ismerni kell a fizetés megvalósítását. Más vizsgálatot igényel a saját oldalon megjelenő adatmező, a külső szolgáltató beágyazott felülete és a külön fizetési oldalra átirányító folyamat.
Technikai magyarázat: A böngésző same-origin policy szabálya korlátozza a különböző eredetű dokumentumok közötti hozzáférést. A szülőoldal szkriptje általában nem olvashatja közvetlenül egy másik eredetű iframe belső mezőit. Ezért nem pontos az az általános állítás, hogy egy oldalon futó bármely szkript minden beágyazott fizetési adatot lát. A tényleges integrációt kell ellenőrizni. [8]
Kitalált példa: a rendes fizetési integráció elé egy megtévesztő adatbekérő réteg kerül. Ilyenkor a támadó nem feltétlenül a szolgáltató iframe-jét olvassa: a felhasználót másik felületen veszi rá az adatbevitelre.
Szerveroldali adatlopás és korábban tárolt adatok
A böngésző hálózati forgalma nem mutat meg minden szerveroldali műveletet. Kitalált példa: a szerverre érkező űrlapadatot egy módosított feldolgozóprogram a rendes mentés mellett jogosulatlan helyre is továbbítja. A látogató böngészője ebben a példában csak a saját webhelyre küldött bekérést látja.
A tárolt adatok veszélyeztetésének egyik lehetséges módja az SQL-injection. Az OWASP az ilyen hibák ellen többek között a paraméterezett lekérdezéseket és a szükségesre korlátozott adatbázis-jogosultságokat tárgyalja. [9]
Ettől külön probléma a hiányos jogosultság-ellenőrzés. Egy alkalmazásnak minden érintett kérésnél ellenőriznie kell, hogy a felhasználó hozzáférhet-e az adott adathoz vagy művelethez. A bejelentkezés ténye önmagában nem határozza meg az összes engedélyt. [10]
Az adatlopási vizsgálat ezért az aktív űrlapok mellett a tárolt adatokhoz vezető hozzáférési utakat is érintheti.
Jelszóhash, munkamenet és HTTPS: három külön védelmi pont
A hash-elt jelszó és a belépéskor megadott jelszó külön állapot
Az OWASP a jelszavak tárolásához megfelelő, adaptív hash-elési eljárásokat javasol. A hash nem az eredeti jelszó visszafejthető tárolása, de a megszerzett hash-ek ellen jelszójelöltek kipróbálásával támadás végezhető. [11]
Ez más kérdés, mint a belépés pillanatában történő adatgyűjtés. A MITRE által ismertetett webes hitelesítőadat-rögzítés a felhasználó által éppen megadott adatokra irányulhat. [1]
Kitalált példa: a jelszó szabályosan hash-elve kerülne az adatbázisba, de a módosított belépési folyamat előbb jogosulatlanul rögzíti a beérkező értéket. A helyes tárolás ebben a példában nem kezeli a korábbi rögzítést.
A munkamenet-azonosító is érzékeny
A munkamenet-kezelés a bejelentkezett állapotot azonosító adatokra támaszkodik. Az OWASP szerint a HttpOnly attribútum megakadályozza, hogy a JavaScript a document.cookie segítségével hozzáférjen az adott sütihez. Ez nem szünteti meg az XSS összes következményét: a böngésző a megfelelő kérésekhez továbbra is csatolhatja a sütit. [12]
Technikai magyarázat: A jelszó, a munkamenet-azonosító és az API-hozzáférés külön hitelesítési elem lehet. Helyreállításkor az érintett elemeket egyenként kell azonosítani, és a használható hozzáféréseket a rendszer lehetőségei szerint visszavonni vagy lecserélni.
A HTTPS a kapcsolatot védi
A TLS a hálózaton továbbított adatok védelmét szolgálja. Nem ellenőrzi, hogy a kapcsolat másik végén működő alkalmazás jóváhagyott módon kezeli-e az adatot. [13]
Ezért egy HTTPS-en betöltött hamis űrlap is kérhet érzékeny információt, és egy kompromittált alkalmazás titkosított kapcsolaton is fogadhat adatot. A kapcsolat titkosítása és a szolgáltatás megbízhatósága külön ellenőrzési kérdés.
Miből állapítható meg, mi történt?
Egy gyanús kód megtalálása fontos nyom, de a hatás értékeléséhez a működését, az időszakot és az érintett adatkört is fel kell tárni. A következő táblázat szerkesztett bizonyítási keret.
| Megállapítás | Milyen bizonyítékot keresünk hozzá? |
|---|---|
| A kód adatot tudott gyűjteni | Kódelemzés, elérhető mezők és adatforrások |
| A működés ténylegesen lefutott | Végrehajtási nyomok, megfigyelt események, naplók |
| Jogosulatlan adatküldés történt | A küldés tartalma, célja és eredménye a rendelkezésre álló adatok alapján |
| Konkrét felhasználók érintettek | Az időszak, az adatkör és a felhasználói események összekapcsolása |
Az OWASP naplózási útmutatója az alkalmazásesemények és hozzáférések rögzítése mellett azt is tárgyalja, milyen érzékeny adatokat nem szabad közvetlenül naplózni. A kivizsgálás nem indokolja, hogy éles jelszavak vagy teljes fizetési adatok kerüljenek általános hibakeresési naplóba. [14]
A hiányos bizonyítékot bizonytalanságként kell kezelni. A „nem találtunk kimenő adatküldést” és az „igazoltuk, hogy nem történt jogosulatlan hozzáférés” eltérő erősségű megállapítás.
Hogyan vizsgálható az adatút?
Fejlesztői vizsgálatnál a Chrome DevTools Network panelje megmutathatja a böngésző kéréseit, a beküldött adatokat és a kapcsolódó kezdeményezőt. A Preserve log a navigációk közötti megőrzésben segít. [15]
Ellenőrzött tesztkörnyezetben, mesterséges tesztadatokkal például összehasonlítható a jóváhagyott és a tényleges folyamat. Az összehasonlítás kérdései:
- Melyik felületen történik adatbevitel?
- Mely szkriptek férhetnek hozzá az adott környezethez?
- Milyen böngészőkérések indulnak?
- Melyik szerveroldali program dolgozza fel az adatot?
- Hová kerül a mentés vagy továbbítás?
Ez vizsgálati munkamenet, nem egy konkrét webhelyre vonatkozó diagnózis. A HAR-fájl megosztása előtt a tartalmát ellenőrizni kell, mert érzékeny hálózati információt is tartalmazhat. [15]
WordPress: a fiókok és integrációk is a vizsgálat részei
A WordPress hivatalos biztonsági útmutatója a fájlok, jogosultságok, adatbázis és üzemeltetői környezet védelmét is tárgyalja. Adatlopás gyanújánál ezért a bővítmények és sablonok mellett a kapcsolódó hozzáférések áttekintése is szükséges lehet. [16]
A WordPress REST API hitelesítésében alkalmazásjelszavak is szerepet kaphatnak. Ezek dokumentált integrációs eszközök; egy érintett fiók vizsgálatánál azt is fel kell tárni, milyen ilyen hozzáférései vannak, és mire jogosult. [17]
Kitalált példa: egy űrlap jóváhagyott továbbítási beállításához jogosulatlan címzettet adnak hozzá. Ebben a példában a vizsgálatnak a programfájlok mellett az adatbázisban tárolt beállítást és a módosításhoz használt hozzáférést is értékelnie kell.
A látható adatküldést mindig az adott űrlap és integráció dokumentált céljához kell viszonyítani. Nem minden külső adatkapcsolat jogosulatlan.
Joomla: a megjelenítő és a feldolgozó külön szerepet kaphat
A Joomla biztonsági dokumentációja XSS- és SQL-injection-hibákat is ismertet. Az előbbi a böngészőben végrehajtható tartalomhoz, az utóbbi adatbázis-lekérdezések manipulálásához kapcsolódhat. [18]
Kitalált példa: egy modul megjeleníti az űrlapot, egy komponens feldolgozza a beküldést, majd egy integráció továbbítja az adatokat. A vizsgálatnak ezt a teljes utat kell követnie, és minden ponton összehasonlítani a tényleges működést a jóváhagyott céllal.
Ha a megjelenítő tartalmat javítják, attól a feldolgozó program vagy a továbbítási beállítás még külön ellenőrzést igényelhet. A konkrét felépítést az érintett összetevők és verziók alapján kell azonosítani.
Mit érdemes tenni adatlopás gyanújánál?
A NIST incidenskezelési ajánlása az észlelés, reagálás és helyreállítás feladatait összekapcsolja a kockázatkezeléssel. [19] Az alábbi sorrend ennek alapján szerkesztett, weboldalas kiindulópont; a sürgős intézkedéseket az aktuális károkozáshoz kell igazítani.
- Rögzítsd az ismert tényeket. Érintett címek, programok, észlelési időpontok, riasztások és bizonyítékok.
- Korlátozd a jogosulatlan adatkezelést. Az érintett felület, szkript, továbbítás vagy hozzáférés kezelése az üzemeltetővel összehangolt feladat lehet.
- Tárd fel az érintettséget. Mely adatokhoz, milyen időszakban és milyen módon férhettek hozzá? Mi bizonyított, és mi maradt nyitott?
- Állítsd helyre a megbízható működést. A kód, beállítások, hozzáférések és bejutási pont kezelése külön is ellenőrizendő.
- Rendezd az érintett hitelesítési elemeket. A jelszavak, munkamenetek és integrációs hozzáférések körét a feltárt helyzet alapján határozd meg.
- Dokumentáld és kövesd az eredményt. Az ellenőrzés hatóköre és a megmaradt bizonytalanság is szerepeljen a feljegyzésben.
A személyes adatok érintettségét külön értékelni kell
Az EDPB útmutatója szerint személyesadat-incidens lehet a jogosulatlan hozzáférés vagy közlés is; nem minden biztonsági esemény érint személyes adatot. Az adatkezelőnek az ilyen incidenseket dokumentálnia kell. [20]
Ha a hatósági bejelentés feltételei fennállnak, azt a tudomásszerzést követően indokolatlan késedelem nélkül, lehetőség szerint 72 órán belül kell megtenni; kivétel, ha az incidens valószínűsíthetően nem jár kockázattal az érintettek jogaira és szabadságaira. Valószínűsíthető magas kockázatnál az érintettek tájékoztatása is felmerül. A konkrét kötelezettséget az incidens körülményei alapján kell értékelni. [20]
Hogyan csökkenthető az adatlopás kockázata?
A technikai védelem az adatút több pontjára terjed ki. Az OWASP az alkalmazás jogosultságainak minden kérésnél történő ellenőrzését és a szükségesre korlátozott hozzáféréseket is javasolja. [10]
A többtényezős hitelesítés további ellenőrzést adhat a bejelentkezéshez. A módszer megválasztása számít: az OWASP külön tárgyalja az egyes megoldások erősségeit és korlátait. A fiókvédelem mellett az alkalmazáskód és a munkamenet-kezelés vizsgálata is feladat marad. [21]
Technikai magyarázat: A Content Security Policy korlátozhatja a szkriptforrásokat és egyes adatkapcsolatokat, de kiegészítő védelmi réteg. A Subresource Integrity, röviden SRI, támogatott erőforrásoknál ellenőrzőösszeggel vizsgálhatja a betöltött tartalom egyezését. Mindkettőt a tényleges alkalmazáshoz és függőségekhez kell megtervezni; egyik sem helyettesíti a már kompromittált rendszer helyreállítását. [22][23]
Tulajdonosként hasznos kiindulópont, ha ismert, mely űrlap milyen adatot kér, hol tárolja, és mely szolgáltatásokhoz továbbítja. Ez az összehasonlítási alap egy későbbi változás vagy riasztás értékelésében is segítséget ad.
A következő rész: spamküldésre és más támadásokra használt weboldalak
A következő részben azt vizsgáljuk meg, hogyan használhatják fel a megszerzett weboldalt levélszemét küldésére vagy további támadói műveletekre, és hogyan különíthető el az ilyen működés a szabályos levelezéstől és szerverforgalomtól.
Források
Forrásellenőrzés: 2026. október 30. A példák kitalált szemléltető esetek. A táblázatok és a vizsgálati munkamenet szerkesztett javaslatok. A konkrét érintettség és kötelezettségek megállapításához az adott incidens tényállását kell értékelni.
- MITRE ATT&CK: Web Portal Capture – T1056.003.
- NIST: Phishing.
- Google Search Central: Social engineering – phishing and deceptive sites.
- Search Console Help: Security issues report.
- OWASP: Third Party JavaScript Management.
- OWASP: Cross Site Scripting Prevention.
- PCI Security Standards Council: Payment Page Security and Preventing E-Skimming – guidance announcement. A fizetési felületek védelmének magyarázatához; a konkrét megfelelési követelmények nem e cikk tárgya.
- MDN: Same-origin policy.
- OWASP: SQL Injection Prevention.
- OWASP: Authorization.
- OWASP: Password Storage.
- OWASP: Session Management.
- OWASP: Transport Layer Security.
- OWASP: Logging.
- Chrome DevTools: Network features reference.
- WordPress: Hardening WordPress.
- WordPress REST API: Authentication.
- Joomla: Common Vulnerabilities.
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management.
- EDPB: Data breaches – guide for small business.
- OWASP: Multifactor Authentication.
- OWASP: Content Security Policy.
- MDN: Subresource Integrity.
Ha gyanús, hogy weboldalad vírusos vagy feltört, segítünk a helyreállításban !