Képzeld el a következő forgatókönyvet: sikeres volt a karácsonyi szezon, a webáruházad forgalma rekordokat döntött. Hátradőlsz, bontasz egy pezsgőt, és elégedetten nézed a statisztikákat. Aztán január közepén megcsörren a telefon. Először csak egy dühös vásárló hív, hogy mióta nálad vásárolt, gyanús terhelések jelentek meg a bankkártyáján. Aztán jön a második hívás. Aztán a rendőrség vagy a bank keres meg.
A weboldalad látszólag tökéletesen működik. Nincs hibaüzenet, nem omlott össze, az admin felületen minden rendben. Mégis, a háttérben hetek óta egy „láthatatlan zsebtolvaj” ül a pénztárnál, és minden egyes beírt bankkártyaadatot lemásol.
Ez a digitális skimming (más néven e-skimming vagy Magecart-támadás), ami 2025-re a webshopok egyik legfélelmetesebb ellenségévé vált. Ebben a cikkben megnézzük, hogyan történik ez, és miért tehetetlenek ellene a hagyományos vírusirtók.
De hát én biztonságos banki fizetést használok!
Ez az első és legfontosabb tévhit, amit el kell oszlatnunk. A legtöbb webshop tulajdonos joggal gondolja: „Én Stripe-ot / Bariont / OTP SimplePay-t használok, a kártyaadatok nem is nálam vannak, hanem a bank biztonságos oldalán.”
Ez igaz is. Csakhogy a skimmerek (az adatlopó kódok) 2025-ben már nem a szerveredről próbálnak adatot lopni. Ehelyett a vásárlód böngészőjébe épülnek be.
Amikor a vásárló a pénztár oldalon (Checkout) van, a böngészője rengeteg mindent tölt be: a te weboldalad kódját, a betűtípusokat, a statisztikai modulokat, a chat ablakot, a marketing pixeleket. Ha a támadónak sikerül elhelyeznie egy apró, rosszindulatú JavaScript kódot bárhol ebben a láncolatban, az a kód képes „olvasni” azt, amit a vásárló a billentyűzeten beír. Még azelőtt, hogy megnyomná a „Fizetés” gombot, és az adatok titkosítva elindulnának a bank felé.
A „Supply Chain” támadás: amikor nem téged törnek fel
A 2025-ös év nagy változása, hogy a hackerek rájöttek: nehéz feltörni egy jól védett WooCommerce webshopot. Sokkal egyszerűbb feltörni egy kevésbé védett bővítményt vagy egy harmadik féltől származó szolgáltatást, amit a webshop használ.
Például: Használsz egy „Kívánságlista” bővítményt vagy egy „Mai árfolyam” kijelzőt? Ha ennek a bővítménynek a fejlesztőjét feltörik, és módosítják a kódot egy frissítésben, akkor a te webshopod teljesen tisztán, legálisan letölti ezt a frissítést. És vele együtt a trójai falovat is.
A te szervereden nincs vírus. A te jelszavadat nem lopták el. Mégis, a pénztár oldaladon ott fut a kód, ami minden billentyűleütést elküld egy orosz vagy kínai szerverre.
Technikai részletek: Hogyan működik a JavaScript Injection?
(Ez a rész a fejlesztőknek és IT biztonság iránt érdeklődőknek szól)
A modern skimmerek technikai működése rendkívül kifinomult lett 2025-re:
-
DOM-alapú figyelés: A rosszindulatú JavaScript kód
event listener-eket (eseményfigyelőket) csatol ainputmezőkhöz (pl. bankkártyaszám, CVC kód). Amint a felhasználó leüt egy billentyűt (keydownvagychangeesemény), a script rögzíti az értéket. -
Obfuszkáció (Kód ködösítés): A kód nem úgy néz ki, mint egy vírus. Gyakran teljesen ártalmatlannak tűnő névvel rejtik el, például
google-analytics-tag.jsvagyjquery-min.js, és a belseje olvashatatlan karakterhalmazzá van alakítva, amit emberi szemmel lehetetlen értelmezni. -
Exfiltráció (Adatkijuttatás): A lopott adatokat nem emailben küldik el. A script gyakran egy ártalmatlan képfájlnak álcázott kérésként (pl.
favicon.png?id=LopottAdatB64Kodolva) küldi ki a támadó szerverére, így a tűzfalak átengedik, mert azt hiszik, csak egy ikon töltődik be. -
Overlay támadások: Ha a webshop iframe-es fizetést használ (ahol a banki felület egy ablakban nyílik meg), a skimmer képes egy láthatatlan vagy hamis réteget (overlay) húzni az eredeti mező fölé, így a felhasználó valójában a hacker űrlapját tölti ki, nem a bankét.
-
Miért nem veszi észre a vírusirtó?
Ez a legijesztőbb része. A legtöbb szerveroldali vírusirtó (malware scanner) fájlokat vizsgál a merevlemezen. De a skimming kódok gyakran:
-
Dinamikusak: Adatbázisban bújnak meg (pl. egy
wp_optionstáblában lévő beállítás részeként), amit a fájlkeresők nem látnak. -
Külső forrásból jönnek: A kód fizikailag nincs is a te szervereden, hanem egy külső URL-ről töltődik be a látogató böngészőjébe. A te szervered „tiszta”, a látogató böngészője a „fertőzött”.
A megoldás: Védelem a böngészőben (CSP) és a változások figyelése
2025-ben egy webshop biztonsága elképzelhetetlen Content Security Policy (CSP) nélkül. Ez egyfajta házirend, amit a szervered küld a böngészőnek.
Képzeld el úgy, mint egy biztonsági őrt az ajtóban, akinek van egy listája a meghívott vendégekről. A CSP megmondja a böngészőnek: „Erről a weboldalról csak a Google Analytics, a Facebook Pixel és a Barion szervereire lehet adatot küldeni. Ha bármi más (pl. egy ismeretlen szerver) próbál kapcsolódni, azt TILTSD LE azonnal!”
Ha van jól beállított CSP-d, akkor hiába épül be a hacker kódja a webshopodba, nem fogja tudni kijuttatni a lopott adatokat, mert a böngésző blokkolni fogja a kapcsolatot.
A másik kulcs a fájlváltozások figyelése. Egy profi biztonsági rendszer azonnal riaszt, ha a webshopod bármelyik JavaScript fájlja megváltozik – még akkor is, ha csak egyetlen sor került bele.
-
