testowanie kart

Testowanie kart (card testing) to oszustwo, w którym przestępcy sprawdzają w cudzym sklepie, które z posiadanych numerów kart płatniczych są aktywne. OWASP opisuje je jako zautomatyzowane zagrożenie OAT-001 Carding: wiele prób autoryzacji płatności służących weryfikacji hurtowo skradzionych danych kart ^[1]. Stripe podaje inne spotykane nazwy: „carding”, „account testing”, „enumeration” i „card checking” ^[2]. Dla sklepu na WooCommerce skutkiem jest fala nieudanych zamówień, zwroty i ryzyko sporów z posiadaczami kart.

Jak działa

Według OWASP listy pełnych danych kart są testowane w procesie płatności sprzedawcy, by znaleźć karty ważne ^[1]. Jakość skradzionych danych bywa nieznana, a testowanie oddziela dane cenniejsze od bezużytecznych ^[1]. Dane mogą pochodzić z innej aplikacji, z innego kanału płatności albo z rynku przestępczego ^[1]. Źródłem bywa więc cudzy wyciek danych, a sklep, w którym trwa testowanie, nie musi być tym, z którego dane wyciekły. Adyen dodaje, że oszust zwykle robi to przed sprzedażą danych, bo aktywne karty są sprzedawane za znacznie wyższą cenę niż nieprzetestowane ^[7].

Stripe wskazuje dwie drogi testowania. Pierwsza to zapis karty bez obciążenia, preferowany przez oszustów, bo weryfikacje i autoryzacje przy zapisie karty zwykle nie pojawiają się na wyciągu posiadacza ^[2]. Druga to małe płatności, których posiadacze rzadziej zauważają i zgłaszają ^[2]. Aby szybko sprawdzić wiele numerów, oszuści używają skryptów, które testują dużo kart naraz ^[2]. Takie skrypty to złośliwe boty.

RYS. 1Testowanie kart w sklepie

Pokrewne zagrożenia OWASP rozróżnia osobno. Gdy znane są tylko częściowe dane karty, bez daty ważności lub kodu, proces nazywa się OAT-010 Card Cracking; użycie skradzionych kart do zdobycia pieniędzy lub towarów to OAT-012 Cashing Out ^[1].

W WordPressie

W sklepach WooCommerce atak często omija formularz zamówienia i trafia prosto do interfejsu programistycznego. Zespół WooCommerce w grudniu 2024 roku informował o atakach wymierzonych w samo Store API, także w sklepach bez bloku Checkout ^[3]. Store API to publiczne endpointy REST, więc problem łączy się z hasłem niezabezpieczony endpoint REST API: skrypt nie musi ładować strony, by złożyć zamówienie.

WooCommerce wskazał dwa główne narzędzia obrony: rate limiting i CAPTCHA ^[3]. Oba mają ograniczenia.

• Rate limiting. Store API ma wbudowane ograniczanie liczby żądań, ale jest ono domyślnie wyłączone ^[3]. Śledzi żądania według identyfikatora zalogowanego użytkownika albo adresu IP dla żądań anonimowych ^[4]. Po włączeniu w ustawieniach ograniczenie dla składania zamówień wynosi najwyżej 3 żądania na 60 sekund ^[4]. Sklep za serwerem proxy musi włączyć tryb proxy, by nie blokować prawdziwych klientów ^[3].
• CAPTCHA. WooCommerce odkrył, że część popularnych wtyczek CAPTCHA nie chroniła bloku Checkout ani Store API, więc weryfikację dało się ominąć ^[3]. Zespół WooCommerce przygotował poprawki do kilku takich wtyczek, wydane w dniach 13–17 grudnia 2024 roku ^[3].

Zagrożenia i skutki

Stripe wymienia skutki dla sprzedawcy ^[2]:

• spory i ostrzeżenia o oszustwie, bo część płatności przechodzi, a posiadacze kart je zgłaszają;
• wyższy odsetek odmów, który pogarsza reputację sklepu u wydawców kart i może utrzymać się po ataku;
• dodatkowe opłaty, na przykład za autoryzacje i spory;
• obciążenie infrastruktury dużą liczbą żądań;
• zafałszowane dane sprzedażowe, w których fikcyjne transakcje wyglądają jak nowi klienci.

Duża skala sporów może według Stripe skutkować objęciem sklepu programami monitorowania organizacji kartowych ^[2]. WooPayments podkreśla, że zwrot każdej udanej płatności podejrzanej o brak autoryzacji ma najwyższą wagę ^[5].

Jak się bronić

Stripe zaleca przy trwającym ataku cztery kroki: rozpoznać aktywność, zwrócić oszukańcze płatności, wdrożyć środki ograniczające i obserwować, czy działają ^[2]. Najczęstszym objawem jest wyraźny wzrost liczby nieudanych i zablokowanych płatności ^[2].

Visa zaleca, by strony płatności i wszystkie strony weryfikujące dane karty miały mechanizmy wykrywające i blokujące zautomatyzowane skrypty; wymienia zapory sieciowe i CAPTCHA ^[6]. W sklepie internetowym zaporą aplikacyjną jest WAF. Adyen radzi kontrolować odstępy czasowe między zamówieniami, bo boty rejestrują wiele transakcji w krótkim czasie ^[7].

WooPayments pozwala ustawić reguły blokujące podejrzane zamówienia przed obciążeniem klienta ^[5]. Jeśli atak dotyczy tanich produktów, można zablokować zamówienia poniżej 5 dolarów ^[5]. Reguły trzeba obserwować i zmieniać, bo atakujący zmieniają taktykę w trakcie ataku ^[5]. Dokumentacja zaznacza, że odpowiedzialność za zapobieganie oszustwom spoczywa ostatecznie na sprzedawcy ^[5].

Testowanie kart różni się od web skimmingu. Skimming kradnie dane kart ze sklepu, a testowanie wykorzystuje sklep do sprawdzenia danych skradzionych gdzie indziej. Podobną logikę ma credential stuffing, w którym boty sprawdzają wykradzione pary login i hasło.