Furt de date de card din magazinul online: cum funcționează e-skimming-ul și cum îl oprești

Un client te sună nervos: a comandat o pereche de pantofi de la tine, iar a doua zi i-au plecat de pe card două plăți pe care nu le-a făcut, una către un magazin de telefoane din altă țară. Verifici comanda lui. E perfect legitimă, plata a trecut, banii au intrat. Nimic nu pare în neregulă la tine. Și totuși cardul lui a fost copiat exact în momentul în care a tastat numărul pe pagina ta de plată.

Asta este e-skimming. Nu îți sparge baza de date, nu îți schimbă vizibil site-ul, nu îți dă jos magazinul. Fură datele cardului direct din browserul clientului, în timp ce el cumpără de la tine, și pleacă fără să lase urme pe care le-ai vedea cu ochiul liber. În articolul despre securitatea unui magazin online am trecut pe scurt prin toate fronturile. Aici intrăm adânc pe unul singur: cum ajunge codul care fură carduri în pagina ta de checkout și cum îl prinzi.

Ce este e-skimming-ul (formjacking) și de ce nu îl vezi

E-skimming, cunoscut și ca formjacking sau atac Magecart, este echivalentul digital al unui dispozitiv de skimming lipit pe un bancomat. Doar că aici nu există nimic fizic. Atacatorul plantează cod JavaScript în pagina ta de plată, iar codul ascultă câmpurile formularului: numărul cardului, data expirării, codul CVV, numele titularului. Pe măsură ce clientul tastează, codul copiază totul și trimite datele pe un server al atacatorului, în paralel cu plata reală, care merge mai departe normal.

Numele Magecart vine de la „Magento" plus „shopping cart", fiindcă primele campanii loveau magazine Magento. Azi tehnica e independentă de platformă: lovește WooCommerce, PrestaShop, OpenCart, Shopify și magazine construite la comandă. Oriunde există un formular în care un om tastează un card, există o țintă.

Motivul pentru care nu îl vezi e dublu. În primul rând, totul se petrece în browserul clientului, nu pe serverul tău, deci un scan obișnuit al fișierelor de pe server poate să nu găsească nimic. În al doilea rând, codul e construit special ca să se ascundă. E ofuscat, ca să nu se înțeleagă ce face. Se trezește doar pe pagina de checkout, nu pe restul site-ului. Unele variante chiar se dezactivează când detectează că ești logat ca administrator sau că deschizi consola de dezvoltare, ca să pară totul curat exact când te uiți tu.

Cum ajunge codul malițios în pagina ta de plată

Rareori cineva îți sparge serverul direct ca să lipească o linie de cod pe checkout. De cele mai multe ori, codul intră printr-o ușă pe care ai deschis-o chiar tu, fără să știi. Iată căile cele mai frecvente.

Un plugin sau o temă cu vulnerabilitate. Adaugi un plugin de recenzii, un slider, un widget de chat, o temă cumpărată de undeva. Dacă unul dintre ele are o gaură de securitate cunoscută și nu e actualizat, atacatorul o exploatează ca să injecteze codul în paginile tale. Nu te-a spart pe tine, ci ceva ce ai instalat tu. În securitate i se spune atac pe lanțul de aprovizionare (supply chain).

O vulnerabilitate în platforma însăși. Un exemplu concret și recent: în 2024, o vulnerabilitate critică numită CosmicSting (CVE-2024-34102) a lovit Magento și Adobe Commerce. Firma de securitate Sansec a raportat câteva mii de magazine compromise, printre care și branduri mari. Tiparul de atac e edificator: atacatorul fură cheia secretă a magazinului dintr-un fișier de configurare, apoi o folosește ca să modifice blocuri de conținut prin chiar API-ul platformei și să strecoare acolo JavaScript-ul de skimming. Totul legitim din punctul de vedere al sistemului, fiindcă vine cu cheia corectă.

Un serviciu terț de pe care încarci scripturi. Magazinul tău încarcă deseori cod de pe alte domenii: analytics, pixeli de publicitate, chat, teste A/B. Dacă unul dintre furnizorii ăștia e compromis, scriptul „de încredere" pe care îl încarci de la el se schimbă peste noapte și începe să fure carduri, fără ca tu să fi atins ceva. Atacatorii abuzează inclusiv de instrumente legitime de tip tag manager, prin care se pot injecta scripturi pe site fără să umble nimeni în cod.

Observă firul comun: în niciunul dintre cazuri nu trebuie să fie compromis serverul tău în mod evident. Codul ajunge în pagină pe căi care arată normal, iar de acolo nu are decât să aștepte primul client care plătește.

Semne că magazinul tău pierde carduri fără să știi

Fiind un atac tăcut, e-skimming-ul nu îți trimite o alertă. Dar lasă urme indirecte, dacă știi unde să te uiți. Niciunul dintre semnele de mai jos nu e dovadă singur, însă oricare merită investigat imediat.

• Clienții reclamă plăți neautorizate la scurt timp după ce au cumpărat de la tine, iar numitorul comun e clar: toți au trecut prin checkout-ul tău.
• Banca sau procesatorul te contactează fiindcă magazinul tău apare ca „punct comun de compromitere" pentru mai multe carduri fraudate (în engleză, common point of purchase).
• În codul paginii de plată apar scripturi care se încarcă de pe domenii pe care nu le recunoști, sau cereri de rețea către adrese ciudate exact când se completează formularul.
• Pe checkout vezi cod nou sau modificat, cu nume care imită serviciile reale, ca „gtm-analytics" sau similar.
• Fișiere de pe server cu dată de modificare recentă pe care nu le-a atins nimeni din echipa ta.

Problema acestor semne e că ajung la tine târziu. Până când clienții reclamă fraude, scurgerea durează deja de ceva vreme. De aceea apărarea bună nu se bazează pe a observa tu manual, ci pe ceva care urmărește pagina în locul tău, non-stop. Revenim imediat la asta. Dacă vrei și lista generală de semne că un site a fost compromis, am detaliat-o în articolul despre recuperarea unui site spart.

De ce un antivirus pe server nu te protejează aici

Reacția firească e: „am antivirus pe server și hosting cu protecție, deci sunt acoperit". Din păcate, exact împotriva e-skimming-ului instrumentele astea sunt aproape oarbe, și merită să înțelegi de ce.

Un antivirus de server caută fișiere malițioase pe disc. Dar codul de skimming nu trăiește neapărat ca un fișier suspect pe serverul tău. Poate fi o singură linie strecurată într-un template legitim, sau, și mai rău, un script încărcat de pe un domeniu extern, care nu atinge niciodată discul tău. Pentru antivirus, pagina ta arată curată.

La fel, un certificat SSL nu te ajută cu nimic aici. SSL criptează drumul dintre browser și serverul tău, ca nimeni să nu asculte pe traseu. Dar e-skimming-ul nu ascultă pe traseu: rulează chiar în interiorul paginii, unde datele sunt deja în clar, înainte de a fi trimise. Lacătul verde din bara de adrese e real și totuși cardul pleacă spre atacator.

Iar dacă plătești printr-un procesator serios, datele cardului nu mai ajung în baza ta, ceea ce e bine, dar nu rezolvă problema asta. Skimming-ul fură datele cu un pas mai devreme, din formular, în browser, înainte ca ele să plece spre procesator. Stripe, Netopia sau PayU nu pot apăra o pagină pe care nu o controlează ele.

Cum blochezi: CSP, Subresource Integrity și monitorizarea scripturilor

Vestea bună e că împotriva e-skimming-ului există apărări concrete, iar ele nu sunt teorie de laborator: stau chiar la baza noilor cerințe din standardul de securitate a plăților cu cardul (PCI DSS 4.0), care le cere comercianților să țină o evidență a scripturilor de pe paginile de plată, să le verifice integritatea și să detecteze modificările neautorizate. Iată cele trei straturi care contează cel mai mult.

Cele trei lucrează împreună. CSP și SRI sunt garduri pe care le pui în față, ca să oprești execuția codului nepermis chiar în browserul clientului. Monitorizarea e ochiul care te anunță când ceva s-a schimbat, ca să reacționezi în ore, nu în luni. CSP corect configurat e cel mai puternic strat, fiindcă taie exact pasul final al atacului: scoaterea datelor în afară. Fără un loc unde să trimită cardul, skimmerul devine inutil.

Ce faci dacă ai fost deja compromis

Dacă bănuiești că ți s-au scurs carduri, contează ordinea pașilor. Iată ce faci, și ce nu ai voie să amâni.

• Oprește scurgerea. Pune checkout-ul în mentenanță, identifică și scoate codul injectat, restaurează dintr-un backup curat și schimbă toate cheile, parolele și acreditările de admin, hosting și API. Dacă rămâne o singură ușă deschisă, reinfectarea vine în câteva zile.
• Anunță procesatorul și banca acceptantă. Au proceduri pentru exact situația asta și te pot ajuta să limitezi pagubele și să eviți blocarea contului de comerciant. Nu aștepta să te sune ei.
• Notifică autoritatea în 72 de ore. Dacă s-au scurs date personale sau de card, ai obligația legală să notifici ANSPDCP în maximum 72 de ore de când afli de breșă, conform GDPR. În plus, poți raporta incidentul la DNSC, la numărul 1911, apelabil din orice rețea la tarif normal.
• Informează clienții afectați. Când riscul pentru ei e ridicat, și datele de card intră clar aici, trebuie să le spui ce s-a întâmplat, ca să își poată bloca și reemite cardurile. E neplăcut, dar tăcerea costă mai mult, legal și reputațional.

Reține un lucru incomod, dar important: în fața legii, tu ești operatorul datelor. Nu poți muta vina pe pluginul terț sau pe furnizorul de hosting. Dacă scurgerea s-a produs fiindcă n-ai ținut sistemul la zi și n-ai avut măsuri rezonabile, răspunderea, inclusiv o eventuală amendă, rămâne la tine.

Cum te ajută un WAF gestionat să previi reinfectarea

Curățarea o singură dată nu e suficientă. Magazinele compromise prin skimming sunt lovite des din nou, fiindcă atacatorii care au găsit o cale o reîncearcă, automat. Aici intervine un Web Application Firewall gestionat, și nu doar el, ci tot stratul de protecție din fața magazinului.

Un WAF stă în fața site-ului tău și filtrează cererile malițioase înainte să ajungă la platformă. Blochează tentativele de exploatare a vulnerabilităților prin care s-ar reinjecta codul, oprește tiparele de atac cunoscute și taie boții care testează carduri furate pe formularul tău de plată. Dacă vrei să înțelegi în detaliu piesa asta, am explicat-o separat în articolul despre ce este un WAF.

Partea de „gestionat" e cea care schimbă tot calculul împotriva e-skimming-ului. Vulnerabilitățile noi apar săptămânal, iar campaniile de skimming își schimbă constant domeniile și tehnicile. O configurare lăsată să îmbătrânească nu te mai apără peste câteva luni. Un serviciu gestionat înseamnă reguli actualizate continuu, monitorizarea integrității paginii de plată și pe cineva care reacționează când apare o schimbare suspectă, nu un panou pe care nu îl mai deschide nimeni.

Dacă vrei să afli dacă pagina ta de plată e expusă chiar acum, îți facem o evaluare gratuită și îți arătăm ce scripturi rulează pe checkout-ul tău și de unde. Punem apoi scutul UpTrust, cu WAF și monitorizare, în 24-48 de ore, fără să atingem codul magazinului tău, ca tu să te ocupi de vânzări, nu de skimmere. Magazinul tău muncește pentru tine non-stop. Pagina de plată merită să fie păzită la fel.