Card testing támadás: hogyan zajlik, és mi állítja meg

Röviden: A card testing az a támadás, amikor valaki lopott kártyaszámok listáját próbálja végig a te fizetési űrlapodon, hogy kiderítse, melyik él még. Kis összegekkel dolgozik, gyorsan, automatizáltan. A kár nem a sikeres tranzakcióból származik, hanem abból, ami utána jön: díjak minden elutasított kísérlet után, romló engedélyezési arány, végül visszaterhelések. A védekezés három rétegű: sebességkorlát a szerveren, Radar-szabályok a Stripe-ban, és 3D Secure a kockázatos kéréseken.

Mi az a card testing?

A lopott kártyaadat önmagában keveset ér, mert a listák nagy része már letiltott kártyákat tartalmaz. A támadónak először ki kell derítenie, melyik szám él. Ehhez kell egy fizetési űrlap, ami befogad egy tranzakciót, és megmondja, hogy sikerült-e.

A te fizetési oldalad pontosan ilyen. Nem azért választanak ki, mert nagy vagy, hanem azért, mert a fizetési űrlapod nyilvános, és nincs rajta korlát.

Hogyan néz ki egy támadás?

Egy tipikus hullám így fut le:

Perc	Ami történik	Mi látszik a Stripe-fiókban
0	Az első próbák beérkeznek, néhány másodpercenként	Pár elutasított fizetés, „card_declined"
1–3	Felgyorsul: 5–20 kísérlet percenként, mindegyik más kártyaszám	Sorozatos elutasítás, ugyanaz az összeg
3–10	Megjelenik pár sikeres tranzakció — ezek az „élő" kártyák	1–3 sikeres fizetés, ismeretlen vásárlóktól
10+	A hullám elmúlik, vagy IP-t vált és folytatja	Elutasítási arány beszakad
1–90 nap	A kártyabirtokosok reklamálnak	Visszaterhelések, mindegyik „fraudulent" kóddal

Az egész gépi: nincs böngésző, nincs kosár, nincs végigjátszott vásárlói út. A kérés egyenesen a fizetési végpontra érkezik.

Mibe kerül ez neked?

Nem a néhány sikeres tranzakcióba — az összeg jellemzően pár száz forintnak megfelelő, és azt a végén visszaterhelik.

A valódi kár máshol van:

Minden kísérlet pénzbe kerül. Az elutasított tranzakciók után is felszámolnak díjat, és ha ezerszámra jönnek, az látszik a számlán.
Romlik az engedélyezési arányod. A kártyakibocsátók figyelik, milyen forgalom érkezik a kereskedőtől. A tömeges elutasítás után a valódi vásárlóid fizetései is gyakrabban akadnak el.
Jönnek a visszaterhelések. Ez a legdrágább rész: minden vitatott tranzakció külön díjjal jár, és a visszaterhelési arány romlik.
A fiókod kockázati besorolása romlik. Tartósan magas visszaterhelési arány mellett a fizetési szolgáltató felfüggesztheti a fiókot. Ilyenkor a pénz befagy, és a vásárlóid nem tudnak fizetni.

Miről ismered fel, hogy éppen ez történik?

Hirtelen megugrik az elutasított fizetések száma, jellemzően azonos vagy nagyon hasonló összeggel.
A kísérletek ugyanarról az IP-címről vagy néhány IP-ről jönnek, sűrűn.
Sok különböző kártyaszám, ugyanaz a vásárlói e-mail — vagy fordítva.
Eldobható e-mail-címek (mailinator, yopmail és társai).
Éjszakai óra, semmilyen más forgalom mellett.
A kérés nem a webshopod kosarán megy át, hanem közvetlenül a fizetési végponton.

Mi állítja meg? Három réteg

Egy réteg sosem elég: a szerveroldali korlátot ki lehet kerülni IP-váltással, a Radar-szabályok pedig már a fizetési kérés után lépnek. Együtt viszont drágábbá teszik a próbálkozást, mint amennyit ér.

1. réteg — sebességkorlát a szerveren

A legolcsóbb védelem az, ami el sem jut a fizetési szolgáltatóig. A saját alkalmazásodban:

korlátozd a fizetési végpont hívásait IP-nként (például 5 kísérlet 10 percenként),
ne engedd, hogy a fizetés kosár és munkamenet nélkül induljon,
tegyél láthatatlan bot-ellenőrzést a pénztár elé (Turnstile, hCaptcha),
ne add vissza részletes hibaüzenetben, hogy pontosan miért nem sikerült.

Ez a réteg fogja meg a legdurvább hullámot, és ez az egyetlen, ami nem kerül tranzakciós díjba.

2. réteg — Radar-szabályok

A Stripe beépített gépi tanulása sokat elkap, de a kártyapróbálgatás mintázata annyira specifikus, hogy érdemes kimondott szabályt írni rá. Ezek a szabályok a Radar szabálynyelvén így néznek ki:

`` Block if :card_count_for_ip_address_hourly: > 3 Block if :declined_charges_per_ip_address_hourly: > 3 Block if :blocked_charges_per_ip_address_daily: > 5 Block if :declined_charges_per_card_number_hourly: > 2 Block if :is_anonymous_ip: Block if :is_disposable_email: Block if :cvc_check: = 'fail' Block if :address_zip_check: = 'fail' ``

Amit ezek jelentenek, sorban:

card_count_for_ip_address_hourly — hány különböző kártyát látott ugyanaz az IP az elmúlt órában. Ez a card testing legjellemzőbb ujjlenyomata: egy valódi vásárló nem próbál négy kártyát egy óra alatt.
declined_charges_per_ip_address_hourly — hány elutasított fizetés jött ugyanarról az IP-ről. A támadó szükségszerűen sok elutasítást termel.
blocked_charges_per_ip_address_daily — akit egyszer blokkoltunk, az napon belül ne próbálkozhasson tovább.
declined_charges_per_card_number_hourly — ugyanazt a kártyaszámot ne lehessen újra és újra próbálni.
is_anonymous_ip — ismert proxy vagy Tor kilépőpont. Van, ahol ez túl szigorú (privátszféra-tudatos vásárlók), ezért ezt érdemes előbb Review-ként bevezetni.
is_disposable_email — eldobható levélcím.
cvc_check / address_zip_check — ha a kibocsátó azt mondja, hogy a megadott CVC vagy irányítószám nem stimmel, az fizetésnél komoly jel.

Két fontos részlet, amit érdemes tudni:

Az egyedi szabályokhoz a Radar magasabb csomagja (Radar for Fraud Teams) kell — az alapcsomag csak a gépi tanulást és a beépített szabályokat adja. Ha most nincs ilyen csomagod, a 1. és 3. réteget akkor is meg tudod csinálni.

A számlálók nem tartalmazzák az éppen futó fizetést. Az adott órában az első kísérletnél a számláló még nulla, a másodiknál egy, és így tovább. Ezért nem érdemes > 0-ra szabályt írni: azzal a saját vásárlódat is kizárnád, aki elsőre elgépelte a számot.

3. réteg — 3D Secure a kockázatos kéréseken

A 3D Secure a kibocsátó bankra tolja a hitelesítést: a vásárlónak igazolnia kell magát. Automatizált támadásnál ez véget vet a folyamatnak, mert nincs, aki a bank oldalán jóváhagyja.

Nem érdemes viszont mindenkire ráküldeni, mert minden extra lépés vásárlót veszít. A használható középút, hogy a kockázatos kérésekre kéred:

`` Request 3D Secure if :risk_level: = 'elevated' Request 3D Secure if :card_country: != :ip_country: ``

A risk_level értéke normal, elevated, highest vagy not_assessed lehet. Ha az európai szabályozás (SCA) miatt amúgy is kötelező a hitelesítés a forgalmad nagy részén, ez a réteg jórészt már működik nálad.

Mi az, ami NEM segít?

A blokklista utólagos töltögetése. Amíg egyesével pakolod be a kártyaszámokat, a támadó már a következő ezerrel dolgozik. A listának a mintázatra kell épülnie, nem az egyes elemekre.
A CAPTCHA a bejelentkezésnél. A támadó nem jelentkezik be, egyenesen a fizetéshez megy.
Az összeghatár. A card testing pont kis összeggel dolgozik, hogy ne tűnjön fel.
Az országblokk önmagában. Egy proxy másodpercek alatt más országból hoz forgalmat. (Az EU-ban ráadásul a geoblokkolási rendelet korlátozza, hogy uniós vásárlókat kizárj.)

Mit tegyél most, ha támadás alatt vagy?

Kapcsold be a sebességkorlátot a fizetési végponton. Ez az egyetlen lépés, ami azonnal hat, és nem kerül tranzakciós díjba.
Tedd fel a fenti blokkoló szabályokat, először szigorúan; a finomhangolás ráér, amikor elmúlt a hullám.
Nézd meg a sikeres tranzakciókat a hullám alatt — azokat érdemes felülvizsgálni, mert azok élő lopott kártyák lehetnek. Ha visszatérítesz, azzal a visszaterhelést előzöd meg.
Ne törölj naplót. Az IP-k, időbélyegek és a kérés-fejlécek később az egyetlen bizonyítékok.
Nézd meg a visszaterhelési arányodat — ha közel jár a küszöbhöz, azzal külön kell foglalkozni.

Gyakori kérdések

Honnan tudják egyáltalán a fizetési oldalam címét?

Nem célzottan keresnek: automatizált szkennerek pásztázzák a nyilvános internetet ismert fizetési integrációk nyomai után. A te oldalad ugyanúgy megjelenik a listájukon, mint bárki másé.

Ha blokkolom őket, nem próbálják meg máshonnan?

De igen — IP-t váltanak. Ezért nem elég egyetlen szabály. Az IP-alapú korlát, a kártyaszám-alapú korlát és a kockázati szint együtt viszont a támadás gazdaságosságát rontja el: több munka lesz, mint amennyi haszon.

Mennyi valódi vásárlót veszítek a szigorítással?

Jól beállított szabályokkal elhanyagolhatóan keveset. A leggyakoribb hiba a túl alacsony küszöb (> 0 vagy > 1) és a szigorú pass elvárás a CVC-nél — a digitális tárcák (Apple Pay, Google Pay) ugyanis nem küldenek CVC-t, tehát azokra a fail nem is értelmezhető. Ezért érdemes minden új szabályt előbb Review módban futtatni, és a valós adat alapján váltani blokkolásra.

Van olyan, hogy már késő?

Nincs, de van drágább és olcsóbb pillanat. Ha már felfüggesztették a fiókot, akkor a rendbetétel dokumentálása lesz a feladat, és az hetekbe telhet. Ha most kezded, akkor egy délután munka.

Ha nem akarod magad végigcsinálni, átnézzük a Stripe-fiókod beállításait — a jelentés ingyenes, és akkor is használható, ha a javítást a saját fejlesztőd végzi el.

Frissítve: 2026. augusztus 20.