Mokėjimų saugumas: PCI ir sukčiavimas

6 modulis: Valdymas ir saugumas · Skaitymo laikas: 11 min.

Mokymosi tikslas: Po šios pamokos galėsite paaiškinti, kodėl e. parduotuvė niekada pati neapdoroja kortelių duomenų, ką mažai e. parduotuvei reiškia PCI DSS ir SAQ A, kaip apsaugoti atsiskaitymo puslapį ir kaip atpažinti bei riboti sukčiavimą ir kortelių testavimą (card testing).

Pagrindinės sąvokos: PCI DSS, kortelių duomenys, mokėjimų paslaugų teikėjas, nukreipimas į mokėjimo puslapį, įterpta mokėjimo forma (iframe), SAQ A, scenarijai atsiskaitymo puslapyje, e. skimingas (e-skimming), https, HSTS, kortelių testavimas (card testing), užklausų ribojimas (rate limiting), captcha, 3-D Secure, mokėjimo grąžinimas (chargeback), sukčiavimo rizika

Kortelių duomenims ne vieta Jūsų e. parduotuvėje

Kredito kortelės numeris, galiojimo data ir saugos kodas nusikaltėliams yra aukso vertės. Kas juos saugo ar perduoda, tam taikomas PCI DSS (Payment Card Industry Data Security Standard), kortelių bendrovių saugumo standartas. Dabartinė versija yra v4.0.1. Įmonei, kuri pati apdoroja kortelių duomenis, tai didelis reikalavimų rinkinys: tinklo atskyrimas, žurnalai, skenavimai, pripažintos šalies atliekami testai.

Maža e. parduotuvė to nenori, ir to daryti nereikia. Pagrindinė taisyklė: kortelių duomenys niekada nepatenka į Jūsų e. parduotuvę. Klientas juos įveda pas Jūsų mokėjimų paslaugų teikėją (Mollie, Stripe, PayPal, WooPayments ar kitą, 4.4 pamoka). Po to e. parduotuvė sužino tik tai, ar sumokėta, ir gauna identifikatorių. Jokio kortelės numerio, jokio kodo. Tai taip pat reiškia:

• niekada nekurkite savo formos lauko kortelių numeriams, net ir „tik telefoniniam užsakymui“;
• niekada nepriimkite kortelių duomenų el. paštu, pokalbiu ar telefonu ir neįrašykite jų į užsakymo pastabą;
• nenaudokite įskiepio, kuris kortelių duomenis saugo Jūsų duomenų bazėje.

Nukreipimas ar įterpta forma: SAQ A

Mažos e. parduotuvės SAQ (Self-Assessment Questionnaire, savianalizės klausimynas) parodo, kad atitinka PCI DSS. Mokėjimų paslaugų teikėjas kartais jo paprašo. Lengviausias yra SAQ A, skirtas e. parduotuvėms, kurios mokėjimą visiškai patiki kitiems. E. parduotuvėje tai veikia dviem būdais:

1. Nukreipimas. Paspaudęs „užsakyti“, klientas patenka į teikėjo mokėjimo puslapį, o paskui grįžta atgal. E. parduotuvė niekada nemato kortelių duomenų, net ir puslapio, kuriame jie įvedami.
2. Įterpta forma. Mokėjimo laukas yra Jūsų atsiskaitymo puslapyje, tačiau tai teikėjo iframe (puslapio dalis). Kortelių duomenys iš naršyklės keliauja tiesiai teikėjui.

Nuo 2025 m. kovo 31 d. galioja nauja SAQ A versija. Joje yra sąlyga, kuri ypač liečia antrąjį būdą: kas naudoja įterptą formą, turi patvirtinti, kad jo svetainė nėra pažeidžiama scenarijų atakų, galinčių paveikti mokėjimo sistemą. Priežastis yra e. skimingas: kenkėjiškas scenarijus atsiskaitymo puslapyje, kuris skaito, ką klientas įveda, arba uždeda netikrą mokėjimo lauką ant tikrojo. Kas nukreipia į teikėjo puslapį, tam ši sąlyga netaikoma. Paklauskite savo mokėjimų paslaugų teikėjo, kuris SAQ taikomas Jūsų integracijai; jis tai tiksliai žino.

Ką bet kuriuo atveju verta daryti:

• Atsiskaitymo puslapis turi būti kuo paprastesnis. Kiekvienas scenarijus tame puslapyje iš principo gali skaityti įvedamus duomenis: pokalbių valdikliai, žymų tvarkyklės, reklamos pikseliai, A/B testavimo įrankiai. Atsiskaitymo puslapyje įkelkite tik tai, ko reikia mokėjimui. Žymų tvarkyklė atsiskaitymo puslapyje yra vartai, pro kuriuos kiekvienas, turintis prieigą prie tos paskyros, gali pridėti scenarijų.
• Nedaug įskiepių, ir jie atnaujinti (6.2 pamoka). Dauguma e. skimingo atvejų WordPress svetainėse prasideda per įskiepio spragą arba pavogtą administratoriaus slaptažodį.
• Content-Security-Policy (antraštė, nurodanti, iš kurių domenų gali būti įkeliami scenarijai) apriboja žalą, jei kas nors vis dėlto prasiskverbia. Tai darbas tam, kas moka tai išbandyti; neteisinga CSP sugadina Jūsų mokėjimo mygtuką.

https ir HSTS atsiskaitymo puslapyje

Savaime suprantama, kad visa Jūsų e. parduotuvė veikia per https (WordPress kursas, 3.1 pamoka). Atsiskaitymo puslapiui reikia dar dviejų dalykų:

• http turi iš karto nukreipti į https nuolatiniu nukreipimu (301 arba 308). Klientas, kuris kada nors įveda http://shop.example.com/afrekenen/, neturi gauti nešifruoto puslapio.
• HSTS (HTTP Strict Transport Security) yra antraštė, kuria nurodote naršyklei tam tikrą laiką atidaryti Jūsų svetainę tik per https. Taip neleidžiate niekam atviruose bevieliuose tinkluose perimti pirmosios nešifruotos užklausos. Ne mažesnis nei 180 dienų max-age yra įprastas minimumas. HSTS įjunkite tik tada, kai viskas, taip pat įtraukiami subdomenai, veikia per https: naršyklė, pamačiusi HSTS, vėliau atsisako http. KB 6752 paaiškina, kaip tai nustatyti.

Mišrus turinys (scenarijus ar stilių failas per http https puslapyje) atsiskaitymo puslapyje ypač pavojingas: būtent toks failas gali būti pakeistas pakeliui.

Kortelių testavimas (card testing)

Kortelių testavimo atveju nusikaltėliai naudoja Jūsų e. parduotuvę pavogtiems kortelių numeriams išbandyti. Jie automatiškai pateikia šimtus mažų užsakymų. Kiekvienas sėkmingas mokėjimas jiems parodo, kad kortelė veikia. Jūs gaunate krūvą nepavykusių užsakymų, mokesčius už kiekvieną operaciją, mokėjimų grąžinimus, o blogiausiu atveju mokėjimų paslaugų teikėjas užblokuoja Jūsų paskyrą.

Kaip atpažinti: daug užsakymų per trumpą laiką, dažnai to paties mažo produkto, su skirtingais vardais, bet tais pačiais arba keistais adresais, ir daug užsakymų su būsena Nepavykęs.

Kaip riboti:

• Užklausų ribojimas (rate limiting) (užklausų skaičiaus per laiko vienetą riba). WooCommerce Store API, kurią naudoja krepšelio ir atsiskaitymo blokai, turi įdiegtą užklausų ribojimą, tačiau jis pagal numatymą išjungtas. Skiltyje WooCommerce > Nustatymai > Papildoma > Galimybės galite įjungti „Rate limiting Checkout block and Store API“ užsakymų pateikimui. Kodu (filtru) ribą galite nustatyti patys; numatytoji yra 25 užklausos per 10 sekundžių, ir skaičiuojami tik užsakymai bei kiti rašymo veiksmai. Jei Jūsų e. parduotuvė veikia už tarpinio serverio (proxy) ar CDN, reikia įjungti tarpinio serverio palaikymą, kitaip visi lankytojai bus skaičiuojami kaip vienas.
• Captcha ar panaši kliūtis atsiskaitant. Pati WooCommerce teigia, kad užklausų ribojimas ir captcha geriausiai veikia kartu: užpuolikai dažnai keičia IP adresą.
• Jūsų mokėjimų paslaugų teikėjo nustatymai. Teikėjai turi savo sukčiavimo filtrus ir limitus. Įjunkite juos ir stebėkite, ką jie praneša.
• 3-D Secure (papildomas patvirtinimas banko programėlėje, ES griežto kliento autentiškumo patvirtinimo dalis) apsunkina nusikaltėlių darbą, o ginčo atveju dažnai perkelia atsakomybę kortelės turėtojo bankui.

Kitas sukčiavimas

Ne kiekvienas sukčiavimas yra automatizuotas. Ženklai, kurie kartu sudėjus yra priežastis kiek palaukti su išsiuntimu:

• sąskaitos ir pristatymo adresai skirtingose šalyse arba pristatymo adresas siuntų persiuntimo tarnyboje;
• pirmasis užsakymas tik su brangiais, lengvai perparduodamais produktais ir skubiu pristatymu;
• keli bandymai su skirtingomis kortelėmis;
• klientas, kuris po apmokėjimo prašo siųsti kitu adresu.

Mokėjimo grąžinimas (chargeback) yra kliento banko atliekamas mokėjimo kortele atšaukimas. Jūs prarandate sumą, dažnai su mokesčiais, o produktas jau išsiųstas. Todėl saugokite išsiuntimo ir pristatymo įrodymus. Nyderlanduose iDEAL mokėjimo iki šiol nebuvo galima taip atšaukti; kaip tai veikia su Wero, sužinosite iš savo mokėjimų paslaugų teikėjo (4.4 pamoka). Lietuvoje e. parduotuvės siūlo elektroninės bankininkystės mokėjimus (banko nuorodas) ir mokėjimo korteles; ar ir kaip tokį mokėjimą galima atšaukti, taip pat paklauskite savo mokėjimų paslaugų teikėjo.

Santrauka

• Kortelių duomenys niekada nepatenka į Jūsų e. parduotuvę: nei į formas, nei į pastabas, nei į laiškus. Juos apdoroja mokėjimų paslaugų teikėjas.
• Nukreipimas į mokėjimo puslapį arba teikėjo įterptas laukas leidžia Jums likti prie lengviausio PCI klausimyno (SAQ A); naudojant įterptą lauką, atsiskaitymo puslapis turi būti apsaugotas nuo scenarijų atakų.
• Atsiskaitymo puslapis turi būti kuo paprastesnis, veikti per https su 301 nukreipimu iš http ir su ne trumpesniu nei 180 dienų HSTS.
• Kortelių testavimą ribokite užklausų ribojimu (pagal numatymą išjungtas), captcha ir savo teikėjo filtrais.
• Stebėkite sukčiavimo ženklus ir saugokite pristatymo įrodymus, kad galėtumėte ginčyti mokėjimų grąžinimus.

Testas (quiz)

Užduotis

Užduotis A6.3: Ar Jūsų atsiskaitymo puslapis saugus? Įveskite savo e. parduotuvės adresą ir atsiskaitymo puslapio adresą. Programa patikrina sertifikatą, užklausia atsiskaitymo puslapį per http (be nukreipimo sekimo) ir per https (su tuščiu krepšeliu, nieko neužsakoma). Žalia, jei sertifikatas galioja, http nukreipia į https su 301 arba 308, antraštės Strict-Transport-Security max-age yra ne mažesnis nei 180 dienų, nėra mišraus turinio ir scenarijus puslapyje įkelia ne daugiau kaip penki kiti domenai (programa juos parodo). Oranžinė, jei nėra HSTS arba jis per trumpas, nukreipimas laikinas (302 arba 307), scenarijų domenų daugiau nei penki ar yra žymų tvarkyklė, arba kortelės numerio laukas yra Jūsų pačių HTML, o ne pas teikėją. Raudona, jei https ar sertifikatas netinkami, http nenukreipia arba scenarijai ar stilių failai įkeliami per http. Niekada patys nesaugokite kortelių duomenų. Ši patikra mato tik tai, kas puslapyje yra be krepšelio.

Klausimas sau (netikrinamas): ar Jūsų mokėjimo įskiepis nukreipia pas teikėją, ar mokėjimo laukas yra Jūsų puslapyje? Kurį SAQ, pasak Jūsų teikėjo, reikia taikyti?

Žalia varnelė reiškia, kad ši patikra dabar tvarkoje, o ne kad Jūsų e. parduotuvė yra saugi.

Platesniam skaitymui

Veiksmai valdymo skydelyje aprašyti WebOké; pas kitus teikėjus tai veikia panašiai.

• Nemokamas WordPress kursas 3.1: Https ir sertifikatas
• HSTS ir saugumo antraštės Jūsų svetainei
• Privalomas lankytojų nukreipimas į https
• DirectAdmin vadovas 6.4: Lankytojus visada nukreipti į https
• Nemokamas kursas „Saugus internetas verslininkams“ 4.2: Jūsų svetainė: https, HSTS ir saugumo antraštės
• SAQ A atnaujinimai (PCI Security Standards Council, anglų k.): https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a
• Store API užklausų ribojimas (developer.woocommerce.com, anglų k.): https://developer.woocommerce.com/docs/apis/store-api/rate-limiting/
• Card testing attacks and the Store API (developer.woocommerce.com, anglų k.): https://developer.woocommerce.com/2024/12/18/card-testing-attacks-and-the-store-api/