Fizetésbiztonság az Ön webáruházában: PCI, kártyatesztelés és amit a tárhelyszolgáltatója tesz
Aki online fizetéseket fogad el, annak szembe kell néznie a kártyatársaságok biztonsági szabályaival (PCI DSS), olyan bűnözőkkel, akik kártyaadatokat szeretnének ellopni, valamint a card testing jelenséggel: ellopott kártyák kipróbálásával az Ön webáruházában. Ez a cikk elmagyarázza, mit jelent ez egy kis webáruház számára, mit kell Önnek megtennie, és mit intéz el, illetve mit nem intéz el a tárhelyszolgáltató.
A főszabály: a kártyaadatok soha nem kerülnek be az áruházba
A kártyaszámot, a lejárati dátumot és a biztonsági kódot a vásárló a fizetési szolgáltatónál adja meg, nem az Ön saját webáruházában. Az áruház csak arról kap visszajelzést, hogy megtörtént e a fizetés. Ez azt is jelenti, hogy:
- soha ne legyen saját űrlapmező a kártyaszámokhoz, még telefonos megrendelés esetén sem;
- soha ne fogadjon el kártyaadatokat e mailben, csevegésben vagy telefonon, és ne jegyezze fel azokat egy megrendeléshez tartozó megjegyzésben;
- ne használjon olyan bővítményt, amely kártyaadatokat ment el a saját adatbázisban.
A PCI DSS és az SAQ A egyszerűen elmagyarázva
A PCI DSS (Payment Card Industry Data Security Standard) a kártyatársaságok biztonsági szabványa, a jelenlegi verzió a v4.0.1. Egy vállalat, amely saját maga dolgoz fel kártyaadatokat, ezzel egy jelentős követelménycsomagot kap. Egy kis áruház, amely a fizetést teljes mértékben kiszervezi, egy rövid kérdőívvel igazolja, hogy megfelel a követelményeknek: ez az SAQ A (Self-Assessment Questionnaire A). A fizetési szolgáltató néha ezt kéri.
A kiszervezés két módon történhet:
- Átirányítás: a megrendelés után a vásárló a szolgáltató fizetési oldalára kerül, majd onnan visszatér.
- Beágyazott fizetési mező: a fizetési mező az Ön pénztár oldalán található, de valójában a szolgáltató egy oldalrészlete (iframe).
2025. március 31. óta az SAQ A új verziója van érvényben. Aki beágyazott fizetési mezőt használ, annak ebben meg kell erősítenie, hogy az oldala nem sebezhető olyan szkriptekkel végrehajtott támadásokkal szemben, amelyek befolyásolhatják a fizetést. Aki átirányítást alkalmaz, arra ez a feltétel nem vonatkozik. Kérdezze meg a fizetési szolgáltatótól, hogy az Ön integrációjához melyik kérdőív tartozik.
A pénztár oldal védelme
- Tartsa a pénztár oldalt lecsupaszítva. Minden szkript ezen az oldalon elvben beolvashatja, amit a vásárló beír (e skimming): csevegőablakok, tag kezelők, hirdetési pixelek. Csak azt töltse be itt, ami a fizetéshez szükséges.
- Kevés bővítmény, és mindig naprakészen. A rosszindulatú szkriptek leggyakrabban egy bővítmény sebezhetőségén vagy egy ellopott adminisztrátori jelszón keresztül jutnak be.
- Mindenhol https, http ről https re irányítással és HSTS val. Lásd A látogatók kötelező átirányítása https re és HSTS és biztonsági fejlécek az Ön weboldalához.
A card testing felismerése és korlátozása
Card testing esetén a bűnözők automatikusan sok kis megrendelést adnak le, hogy kiderítsék, mely ellopott kártyák működnek. Ezt sok, rövid időn belül érkező megrendelésről ismerheti fel, gyakran ugyanazon olcsó termékre, váltakozó névvel, és sok megrendeléssel, amelynek státusza Sikertelen. Ez tranzakciós költségekkel és visszaterhelésekkel jár, legrosszabb esetben pedig a fizetési szolgáltató zárolja a fiókját.
- Rate limiting (az időegység alatti kérések számának korlátozása). A WooCommerce ezt beépítve tartalmazza a pénztár blokkokhoz, de alapértelmezetten ki van kapcsolva. Kapcsolja be itt: WooCommerce > Beállítások > Haladó > Funkciók, Rate limiting Checkout block and Store API opció.
- Captcha a pénztárnál. A támadók gyakran váltogatják az IP címüket, a rate limiting és a captcha együtt működik a legjobban.
- A fizetési szolgáltató csalásszűrői. Kapcsolja be ezeket, és nézze meg, mit jeleznek.
- 3 D Secure, a banki alkalmazásban történő extra megerősítés, megnehezíti az ellopott kártyákkal való visszaélést.
Mit intéz el a tárhelyszolgáltató, és mit nem
A WebOké nál rendezve:
- Ingyenes Let's Encrypt tanúsítvány a https hoz
- A legtöbb szerveren a HSTS alapértelmezetten be van kapcsolva
- A Web Alkalmazás Tűzfal alapértelmezetten be van kapcsolva, és megállítja az ismert támadásokat
- Az Imunify360 azonnal ellenőrzi az új fájlokat kártevők szempontjából, és rendszeresen átvizsgálja a csomagját
- Minden éjjel biztonsági mentés készül a teljes csomagjáról, 30 napig megőrizve, egy másik adatközpontban
Önnél (vagy a webfejlesztőjénél) marad:
- A WordPress, a WooCommerce, a téma és a bővítmények frissítése (az Installatron ezt automatikusan elvégezheti, lásd Frissítések és automatikus frissítések)
- Az integráció és a csalás elleni beállítások a fizetési szolgáltatónál
- Hogy milyen szkriptek vannak a pénztár oldalán
- Erős jelszavak és kétlépcsős azonosítás az adminisztrátorok számára
- Rate limiting, captcha, valamint a gyanús megrendelések átnézése
A saját maga által telepített szoftvert, akár Installatronon keresztül is, saját maga kezeli. Ha a webhelyét mégis feltörik, kövesse a lépéseket itt: A weboldalamat feltörték: lépésről lépésre. Ha egy betörés érinti a vásárlók személyes adatait, olvassa el ezt is: Ez adatszivárgás, és be kell e jelentenem?
További olvasnivaló
- Ingyenes Biztonságos online tanfolyam, 4.2. lecke: Az Ön weboldala: https, HSTS és biztonsági fejlécek
- PCI Security Standards Council az SAQ A ról (angol nyelven)
- WooCommerce a card testing ről és rate limiting (angol nyelven)