Fizetési biztonság: PCI és csalás

Modul 6: Üzemeltetés és biztonság · Olvasási idő: 11 perc

Tanulási cél: A lecke után el tudja magyarázni, miért nem kezel egy webáruház soha saját maga kártyaadatokat, mit jelent a PCI DSS és a SAQ A egy kis webáruház számára, hogyan védheti meg a pénztár oldalt, és hogyan ismerheti fel és korlátozhatja a csalást és a card testinget.

Kulcsfogalmak: PCI DSS, kártyaadatok, fizetési szolgáltató, átirányítás a fizetési oldalra, beágyazott fizetési űrlap (iframe), SAQ A, szkriptek a pénztár oldalon, e-skimming, https, HSTS, card testing, rate limiting, captcha, 3-D Secure, visszaterhelés (chargeback), csalási kockázat

A kártyaadatok nem valók a webáruházba

Egy bankkártyaszám, a lejárati dátum és a biztonsági kód a bűnözők számára aranyat ér. Aki ezeket tárolja vagy továbbítja, a PCI DSS (Payment Card Industry Data Security Standard), vagyis a kártyatársaságok biztonsági szabványa alá tartozik. A jelenlegi változat a v4.0.1. Egy olyan vállalkozás számára, amely maga kezeli a kártyaadatokat, ez komoly követelménycsomag: hálózati elkülönítés, naplók, vizsgálatok, tesztelés egy elismert szervezet által.

Egy kis webáruház ebbe nem akar belekerülni, és nem is kell. Az alapszabály: a kártyaadatok soha nem kerülnek az Ön webáruházába. Az ügyfél a fizetési szolgáltatónál adja meg őket (Mollie, Stripe, PayPal, WooPayments vagy más, 4.4. lecke). A webáruház ezután csak annyit tud meg: sikeres volt-e a fizetés, egy azonosítóval együtt. Se kártyaszámot, se kódot. Ez azt is jelenti:

• soha ne hozzon létre saját űrlapmezőt kártyaszámok számára, akkor sem, ha "csak egy telefonos rendeléshez" kellene;
• soha ne fogadjon el kártyaadatokat e-mailben, chaten vagy telefonon, és ne írja be őket a rendeléshez tartozó megjegyzésbe;
• ne használjon olyan bővítményt, amely a kártyaadatokat a saját adatbázisában tárolja.

Átirányítás vagy beágyazás: SAQ A

A kis webáruházak egy SAQ (Self-Assessment Questionnaire, önértékelési kérdőív) segítségével igazolják, hogy megfelelnek a PCI DSS-nek. A fizetési szolgáltató ezt néha kéri. A legegyszerűbb a SAQ A, azoknak a webáruházaknak, amelyek a fizetést teljesen kiszervezik. Ez kétféleképpen működhet egy webáruházban:

1. Átirányítás. A "megrendelés" után az ügyfél a szolgáltató fizetési oldalára kerül, majd onnan vissza. A webáruház soha nem látja a kártyaadatokat, és azt az oldalt sem, amelyen beírják őket.
2. Beágyazott űrlap. A fizetési mező az Ön pénztár oldalán jelenik meg, de valójában a szolgáltató iframe-je (egy beágyazott oldalrészlet). A kártyaadatok a böngészőből közvetlenül a szolgáltatóhoz jutnak.

2025. március 31. óta a SAQ A új változata érvényes. Ebben szerepel egy feltétel, amely főleg a második módot érinti: aki beágyazott űrlapot használ, annak meg kell erősítenie, hogy a webhelye nem sebezhető olyan szkriptes támadásokkal szemben, amelyek a fizetési rendszert érinthetik. A háttérben az e-skimming áll: egy rosszindulatú szkript a pénztár oldalon, amely olvassa, amit az ügyfél beír, vagy egy hamis fizetési mezőt helyez a valódi fölé. Aki a szolgáltató oldalára irányít át, arra ez a feltétel nem vonatkozik. Kérdezze meg a fizetési szolgáltatóját, melyik SAQ érvényes az Ön integrációjára; ő pontosan tudja.

Amit mindenképpen érdemes megtenni:

• Tartsa egyszerűen a pénztár oldalt. Az oldalon futó minden szkript elvben olvashatja a beírt adatokat: chatwidgetek, tagmanagerek, hirdetési pixelek, A/B-tesztelő eszközök. A pénztár oldalon csak azt töltse be, ami a fizetéshez szükséges. Egy tagmanager a pénztár oldalon olyan kapu, amelyen keresztül bárki szkripteket adhat hozzá, akinek hozzáférése van az adott fiókhoz.
• Kevés bővítmény, mindig frissítve (6.2. lecke). A WordPressen az e-skimming legtöbbször egy bővítmény biztonsági résén vagy egy ellopott adminisztrátori jelszón keresztül jut be.
• Egy Content-Security-Policy (egy fejléc, amely megadja, mely domainekről érkezhetnek szkriptek) korlátozza a kárt, ha mégis bejut valami. Ez olyan szakembernek való feladat, aki tesztelni is tudja; egy rosszul beállított CSP tönkreteszi a fizetési gombot.

https és HSTS a pénztár oldalon

Magától értetődő, hogy az egész webáruház https-en keresztül fut (WordPress-tanfolyam, 3.1. lecke). A pénztár oldalnál két dolog jön még hozzá:

• A http-nek azonnal https-re kell átirányítania, állandó átirányítással (301 vagy 308). Az az ügyfél, aki valaha beírja a http://shop.example.com/afrekenen/ címet, nem kaphat titkosítatlan oldalt.
• A HSTS (HTTP Strict Transport Security) egy fejléc, amellyel arra utasítja a böngészőt, hogy egy ideig csak https-en keresztül nyissa meg a webhelyét. Így megakadályozza, hogy valaki egy nyílt wifihálózaton elfogja az első titkosítatlan kérést. Egy legalább 180 napos max-age elfogadott minimum. A HSTS-t csak akkor kapcsolja be, ha minden, a vele együtt érintett aldomainek is, https-en keresztül működik: az a böngésző, amely már látta a HSTS-t, ezután elutasítja a http-t. A KB 6752 elmagyarázza, hogyan állíthatja be.

A vegyes tartalom (egy https-oldalon http-n keresztül betöltött szkript vagy stíluslap) a pénztár oldalon különösen veszélyes: pontosan egy ilyen fájlt lehet útközben kicserélni.

Card testing

Card testing esetén a bűnözők az Ön webáruházát használják ellopott kártyaszámok kipróbálására. Automatikusan több száz kis értékű rendelést adnak le. Minden sikeres fizetés elárulja nekik, hogy egy kártya működik. Önnél pedig felhalmozódnak a sikertelen rendelések, a tranzakciónkénti költségek, a visszaterhelések, és a legrosszabb esetben a fizetési szolgáltató letiltja a fiókját.

Felismerés: sok rendelés rövid idő alatt, gyakran ugyanarra a kis értékű termékre, különböző nevekkel, de azonos vagy furcsa címekkel, és sok Sikertelen állapottal.

Korlátozás:

• Rate limiting (a kérések számának időegységenkénti korlátozása). A WooCommerce Store API-ja, amelyet a kosár és a pénztár blokkjai használnak, beépített rate limitinggel rendelkezik, de ez alapértelmezetten ki van kapcsolva. A WooCommerce > Beállítások > Haladó > Funkciók alatt bekapcsolhatja a "Rate limiting Checkout block and Store API" lehetőséget a rendelések leadására. Kóddal (egy filterrel) saját maga is beállíthatja a korlátot; az alapérték 10 másodpercenként 25 kérés, és csak a rendelés leadása és más író műveletek számítanak bele. Ha a webáruháza proxy vagy CDN mögött van, a proxytámogatást be kell kapcsolni, különben minden látogató egynek számít.
• Egy captcha vagy hasonló akadály a pénztárnál. Maga a WooCommerce is azt mondja, hogy a rate limiting és a captcha együtt működik a legjobban: a támadók gyakran váltanak IP címet.
• A fizetési szolgáltató beállításai. A szolgáltatóknak saját csalásszűrőik és limitjeik vannak. Kapcsolja be őket, és figyelje, mit jeleznek.
• A 3-D Secure (a banki alkalmazásban történő további megerősítés, az EU-ban az erős ügyfél-hitelesítés része) megnehezíti a bűnözők dolgát, és vita esetén a felelősséget gyakran a kártyabirtokos bankjára hárítja.

Egyéb csalások

Nem minden csalás automatizált. Olyan jelek, amelyek együttesen okot adnak arra, hogy egy kicsit várjon a szállítással:

• a számlázási és a szállítási cím különböző országokban van, vagy a szállítási cím egy csomagtovábbító szolgáltatásé;
• egy első rendelés, amely csak drága, könnyen továbbértékesíthető termékeket tartalmaz, expressz szállítással;
• több próbálkozás különböző kártyákkal;
• egy ügyfél, aki fizetés után azt kéri, hogy egy másik címre küldje a csomagot.

A visszaterhelés (chargeback) egy kártyás fizetés visszafordítása az ügyfél bankja által. Elveszíti az összeget, gyakran költségekkel együtt, és a termék is odavan. Ezért őrizze meg a feladás és a kézbesítés bizonyítékát. Egy iDEAL-fizetést (Hollandia) eddig nem lehetett így visszafordítani; hogy ez a Wero esetében hogyan működik, azt a fizetési szolgáltatójától tudhatja meg (4.4. lecke). Magyarországon elterjedt fizetési mód a bankkártya, az utánvét és az átutalás.

Összefoglalás

• A kártyaadatok soha nem kerülnek az Ön webáruházába: sem űrlapokba, sem megjegyzésekbe, sem e-mailekbe. A fizetési szolgáltató kezeli őket.
• Az átirányítás a fizetési oldalra vagy a szolgáltató beágyazott mezője a legegyszerűbb PCI-kérdőívben (SAQ A) tartja Önt; beágyazott mező esetén a pénztár oldalnak védettnek kell lennie a szkriptes támadásokkal szemben.
• Tartsa egyszerűen a pénztár oldalt, https-en keresztül, http-ről 301-es átirányítással és legalább 180 napos HSTS-sel.
• A card testinget rate limitinggel (alapértelmezetten kikapcsolva), captchával és a szolgáltató szűrőivel korlátozhatja.
• Figyeljen a csalásra utaló jelekre, és őrizze meg a kézbesítés bizonyítékát a visszaterhelések ellen. Magyarországon a bankkártya, az utánvét és az átutalás is elterjedt fizetési mód.

Kvíz

Feladat

Feladat A6.3: Biztonságos a pénztár oldala? Adja meg a webáruháza címét és a pénztár oldal címét. A program ellenőrzi a tanúsítványt, lekéri a pénztár oldalt http-n keresztül (átirányítás követése nélkül) és https-en keresztül (üres kosárral, semmit nem rendel meg). Zöld, ha a tanúsítvány érvényes, a http 301-gyel vagy 308-cal https-re irányít át, a Strict-Transport-Security fejléc max-age értéke legalább 180 nap, nincs vegyes tartalom, és legfeljebb öt másik domain tölt be szkripteket az oldalon (a program megmutatja őket). Narancs, ha nincs HSTS vagy túl rövid, ha az átirányítás ideiglenes (302 vagy 307), ha ötnél több szkriptdomain vagy egy tagmanager van, vagy ha kártyaszámmező szerepel a saját HTML-ben a szolgáltatóé helyett. Piros, ha a https vagy a tanúsítvány nem megfelelő, ha a http nem irányít át, vagy ha szkriptek vagy stíluslapok http-n keresztül töltődnek be. A kártyaadatokat soha ne tárolja saját maga. Ez az ellenőrzés csak azt látja, ami kosár nélkül az oldalon van.

Kérdés önmagának (nem ellenőrizzük): a fizetési bővítménye átirányít a szolgáltatóhoz, vagy a fizetési mező az Ön oldalán van? Melyik SAQ érvényes a szolgáltatója szerint?

Egy zöld pipa azt jelenti, hogy ez az ellenőrzés most rendben van, nem azt, hogy a webáruháza biztonságos.

Bővebben olvasva

A vezérlőpulton leírt lépések a WebOké-ra vonatkoznak; más szolgáltatóknál hasonlóan működik.

• Ingyenes WordPress-tanfolyam 3.1: A https és a tanúsítvány
• HSTS és biztonsági fejlécek az Ön weboldalához
• Látogatók kötelező átirányítása https-re
• DirectAdmin útmutató 6.4: Látogatók átirányítása https-re
• Ingyenes tanfolyam: Biztonságos online jelenlét vállalkozóknak 4.2: Az Ön weboldala: https, HSTS és biztonsági fejlécek
• A SAQ A frissítései (PCI Security Standards Council, angol nyelven): https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a
• Rate limiting a Store API-hoz (developer.woocommerce.com, angol nyelven): https://developer.woocommerce.com/docs/apis/store-api/rate-limiting/
• Card testing attacks and the Store API (developer.woocommerce.com, angol nyelven): https://developer.woocommerce.com/2024/12/18/card-testing-attacks-and-the-store-api/