Securitatea plăților: PCI și frauda

Modulul 6: Administrare și securitate · Timp de citire: 11 minute

Obiectiv de învățare: După această lecție veți putea explica de ce un magazin nu procesează niciodată singur datele de card, ce înseamnă PCI DSS și SAQ A pentru un magazin mic, cum protejați pagina de finalizare a comenzii și cum recunoașteți și limitați frauda și card testing.

Noțiuni cheie: PCI DSS, date de card, furnizor de plăți, redirecționare către pagina de plată, formular de plată încorporat (iframe), SAQ A, scripturi pe pagina de finalizare a comenzii, e-skimming, https, HSTS, card testing, rate limiting, captcha, 3-D Secure, rambursare forțată (chargeback), risc de fraudă

Datele de card nu au ce căuta în magazinul dumneavoastră

Un număr de card de credit, data de expirare și codul de securitate valorează aur pentru infractori. Cine le stochează sau le transmite intră sub incidența PCI DSS (Payment Card Industry Data Security Standard), standardul de securitate al companiilor de carduri. Versiunea actuală este v4.0.1. Pentru o firmă care procesează singură datele de card, acesta înseamnă un pachet consistent de cerințe: separarea rețelelor, jurnale, scanări, teste efectuate de o entitate acreditată.

Un magazin mic nu vrea să ajungă acolo și nici nu este nevoie. Regula fixă: datele de card nu ajung niciodată în magazinul dumneavoastră. Clientul le introduce la furnizorul de plăți (Mollie, Stripe, PayPal, WooPayments sau altul, lecția 4.4). Magazinul află apoi doar: plătit sau nu, împreună cu un identificator. Niciun număr de card, niciun cod. Asta înseamnă și:

• nu creați niciodată un câmp propriu de formular pentru numere de card, nici măcar „doar pentru o comandă telefonică”;
• nu primiți niciodată date de card prin e-mail, chat sau telefon și nu le treceți într-o notă la comandă;
• nu folosiți niciun plugin care păstrează datele de card în propria bază de date.

Redirecționare sau formular încorporat: SAQ A

Magazinele mici demonstrează cu un SAQ (Self-Assessment Questionnaire, un chestionar de autoevaluare) că respectă PCI DSS. Furnizorul de plăți vi-l cere uneori. Cel mai simplu este SAQ A, pentru magazinele care externalizează complet plata. Există două moduri în care funcționează acest lucru într-un magazin:

1. Redirecționare. După „comandă”, clientul ajunge pe pagina de plată a furnizorului și apoi revine. Magazinul nu vede niciodată datele de card și nici pagina pe care sunt introduse.
2. Formular încorporat. Câmpul de plată se află în pagina dumneavoastră de finalizare a comenzii, dar este un iframe (o bucată de pagină) al furnizorului. Datele de card merg din browser direct la furnizor.

Din 31 martie 2025 se aplică o nouă versiune a SAQ A. Aceasta conține o condiție care privește mai ales a doua variantă: cine folosește un formular încorporat trebuie să confirme că site-ul său nu este vulnerabil la atacuri cu scripturi care pot afecta sistemul de plată. Contextul este e-skimming: un script rău intenționat pe pagina de finalizare a comenzii care citește ce introduce clientul sau care suprapune un câmp de plată fals peste cel real. Cine redirecționează către pagina furnizorului nu intră sub această condiție. Întrebați-vă furnizorul de plăți ce SAQ se aplică integrării dumneavoastră; el știe exact.

Ce faceți în orice caz:

• Păstrați pagina de finalizare a comenzii cât mai simplă. Orice script de pe acea pagină poate, în principiu, să citească datele: widgeturi de chat, tag managere, pixeli de publicitate, instrumente de testare A/B. Încărcați pe pagina de finalizare a comenzii doar ce este necesar pentru plată. Un tag manager pe această pagină este o poartă prin care oricine are acces la acel cont poate adăuga scripturi.
• Puține pluginuri, și actualizate (lecția 6.2). Cele mai multe cazuri de e-skimming pe WordPress pătrund printr-o vulnerabilitate a unui plugin sau printr-o parolă de administrator furată.
• O Content-Security-Policy (un antet care spune de pe ce domenii pot proveni scripturile) limitează paguba dacă totuși pătrunde ceva. Aceasta este o sarcină pentru cineva care o poate testa; o CSP greșită vă strică butonul de plată.

https și HSTS pe pagina de finalizare a comenzii

Faptul că tot magazinul funcționează prin https este de la sine înțeles (cursul WordPress, lecția 3.1). Pentru pagina de finalizare a comenzii se adaugă două lucruri:

• http trebuie să redirecționeze imediat către https, cu o redirecționare permanentă (301 sau 308). Un client care introduce vreodată http://shop.example.com/afrekenen/ nu trebuie să primească o pagină necriptată.
• HSTS (HTTP Strict Transport Security) este un antet prin care cereți browserului să deschidă site-ul dumneavoastră o perioadă doar prin https. Astfel împiedicați ca cineva dintr-o rețea wifi deschisă să intercepteze prima cerere necriptată. Un max-age de cel puțin 180 de zile este un minim uzual. Activați HSTS doar când totul, inclusiv subdomeniile pe care le includeți, funcționează prin https: un browser care a văzut HSTS refuză apoi http. KB 6752 explică cum îl configurați.

Conținutul mixt (un script sau o foaie de stil prin http pe o pagină https) pe pagina de finalizare a comenzii este deosebit de periculos: tocmai un astfel de fișier poate fi înlocuit pe drum.

Card testing

La card testing, infractorii folosesc magazinul dumneavoastră pentru a încerca numere de card furate. Plasează automat sute de comenzi mici. Fiecare plată reușită le spune că un card funcționează. Dumneavoastră rămâneți cu un teanc de comenzi eșuate, costuri per tranzacție, rambursări forțate și, în cel mai rău caz, cu un furnizor de plăți care vă blochează contul.

Cum îl recunoașteți: multe comenzi într-un timp scurt, adesea pentru același produs mic, cu nume diferite dar cu aceleași adrese sau cu adrese ciudate, și multe cu statusul Eșuată.

Cum îl limitați:

• Rate limiting (o limită a numărului de cereri pe unitate de timp). Store API din WooCommerce, folosit de blocurile pentru coș și finalizarea comenzii, are rate limiting integrat, dar acesta este dezactivat implicit. La WooCommerce > Setări > Avansate > Funcționalități puteți activa „Rate limiting Checkout block and Store API” pentru plasarea comenzilor. Cu cod (un filtru) puteți stabili singur limita; valoarea implicită este de 25 de cereri la 10 secunde și se numără doar comenzile și alte acțiuni de scriere. Dacă magazinul dumneavoastră se află în spatele unui proxy sau CDN, trebuie activat suportul pentru proxy, altfel toți vizitatorii sunt numărați ca unul singur.
• Un captcha sau o barieră similară la finalizarea comenzii. WooCommerce însuși spune că rate limiting și captcha funcționează cel mai bine împreună: atacatorii își schimbă des adresa IP.
• Setările furnizorului dumneavoastră de plăți. Furnizorii au propriile filtre antifraudă și limite. Activați-le și urmăriți ce semnalează.
• 3-D Secure (confirmarea suplimentară în aplicația băncii, parte a autentificării stricte a clienților în UE) îngreunează munca infractorilor și, în caz de litigiu, mută adesea răspunderea către banca deținătorului cardului.

Alte tipuri de fraudă

Nu orice fraudă este automatizată. Semnale care, puse laolaltă, justifică o mică așteptare înainte de expediere:

• adresa de facturare și cea de livrare în țări diferite, sau o adresă de livrare la un serviciu de redirecționare a coletelor;
• o primă comandă doar cu produse scumpe, ușor de revândut, cu livrare urgentă;
• mai multe încercări cu carduri diferite;
• un client care, după plată, cere trimiterea la o altă adresă.

O rambursare forțată (chargeback) este anularea unei plăți cu cardul de către banca clientului. Pierdeți suma, adesea cu costuri suplimentare, iar produsul este plecat. Păstrați de aceea dovezi ale expedierii și livrării. O plată iDEAL nu putea fi anulată până acum în acest mod; cum se procedează la Wero aflați de la furnizorul dumneavoastră de plăți (lecția 4.4). În România, metode de plată obișnuite sunt cardul, plata la livrare (ramburs) și transferul bancar.

Rezumat

• Datele de card nu ajung niciodată în magazinul dumneavoastră: nici în formulare, nici în note, nici în e-mailuri. Furnizorul de plăți le procesează.
• Redirecționarea către pagina de plată sau un câmp încorporat al furnizorului vă menține la cel mai simplu chestionar PCI (SAQ A); la un câmp încorporat, pagina de finalizare a comenzii trebuie protejată împotriva atacurilor cu scripturi.
• Păstrați pagina de finalizare a comenzii simplă, prin https, cu un 301 de la http și cu HSTS de cel puțin 180 de zile.
• Limitați card testing cu rate limiting (dezactivat implicit), un captcha și filtrele furnizorului dumneavoastră.
• Fiți atenți la semnalele de fraudă și păstrați dovezi ale livrării împotriva rambursărilor forțate.

Test (quiz)

Exercițiu

Exercițiul A6.3: Este sigură pagina dumneavoastră de finalizare a comenzii? Introduceți adresa magazinului și adresa paginii de finalizare a comenzii. Programul verifică certificatul, solicită pagina de finalizare a comenzii prin http (fără a urma redirecționarea) și prin https (cu coșul gol, nu se comandă nimic). Verde dacă certificatul este valid, http redirecționează cu 301 sau 308 către https, antetul Strict-Transport-Security are un max-age de cel puțin 180 de zile, nu există conținut mixt și cel mult cinci alte domenii încarcă scripturi pe pagină (programul le afișează). Portocaliu dacă HSTS lipsește sau este prea scurt, dacă există o redirecționare temporară (302 sau 307), mai mult de cinci domenii de scripturi sau un tag manager, ori un câmp pentru numărul de card în propriul HTML în loc să fie la furnizor. Roșu dacă https sau certificatul nu sunt în regulă, dacă http nu redirecționează sau dacă scripturi ori foi de stil se încarcă prin http. Nu stocați niciodată singur date de card. Această verificare vede doar ce se află pe pagină fără coș de cumpărături.

Întrebare pentru dumneavoastră (nu se verifică): pluginul dumneavoastră de plată redirecționează către furnizor sau câmpul de plată se află în pagina dumneavoastră? Ce SAQ vă spune furnizorul că se aplică?

O bifă verde înseamnă că această verificare este acum în regulă, nu că magazinul dumneavoastră este sigur.

Lecturi suplimentare

Pașii dintr-un panou se aplică pentru WebOké; la alți furnizori funcționează similar.

• Curs gratuit WordPress 3.1: Https și certificatul
• HSTS și headere de securitate pentru site-ul dumneavoastră web
• Redirecționarea obligatorie a vizitatorilor către https
• Manual DirectAdmin 6.4: Vizitatorii întotdeauna direcționați către https
• Curs gratuit Siguranță online pentru antreprenori 4.2: Site-ul dumneavoastră web: https, HSTS și antete de securitate
• Actualizări pentru SAQ A (PCI Security Standards Council, în engleză): https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a
• Rate limiting pentru Store API (developer.woocommerce.com, în engleză): https://developer.woocommerce.com/docs/apis/store-api/rate-limiting/
• Card testing attacks and the Store API (developer.woocommerce.com, în engleză): https://developer.woocommerce.com/2024/12/18/card-testing-attacks-and-the-store-api/