# Card testing támadás — hogyan zajlik, és mi állítja meg | RootCore LLC

> Egy kártyapróbálgatós támadás perceken belül több száz lopott kártyát futtat végig a fizetési űrlapodon. Így néz ki, ezek a jelei, és ezek a Stripe Radar-szabályok állítják meg.

Oldal: https://cyber-security.rootcr.com/tudastar/card-testing-tamadas/
Frissítve: 2026-08-20

---

# 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:

1. **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.
2. **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.
3. **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.
4. **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?

1. **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.
2. **Tedd fel a fenti blokkoló szabályokat**, először szigorúan; a finomhangolás ráér, amikor elmúlt a hullám.
3. **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.
4. **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.
5. **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](/stripe-audit/) — a jelentés ingyenes, és akkor is használható, ha a javítást a saját fejlesztőd végzi el.