Bezpieczeństwo płatności: PCI i oszustwa

Moduł 6: Zarządzanie i bezpieczeństwo · Czas czytania: 11 min

Cel lekcji: Po tej lekcji będą Państwo potrafili wyjaśnić, dlaczego sklep nigdy sam nie przetwarza danych kart, co PCI DSS i SAQ A oznaczają dla małego sklepu, jak chronić stronę zamówienia oraz jak rozpoznawać i ograniczać oszustwa i card testing.

Kluczowe pojęcia: PCI DSS, dane kart, operator płatności, przekierowanie na stronę płatności, osadzony formularz płatności (iframe), SAQ A, skrypty na stronie zamówienia, e-skimming, https, HSTS, card testing, rate limiting, captcha, 3-D Secure, obciążenie zwrotne (chargeback), ryzyko oszustwa

Dane kart nie mają miejsca w Państwa sklepie

Numer karty kredytowej, data ważności i kod zabezpieczający są dla przestępców na wagę złota. Kto je przechowuje lub przekazuje, podlega PCI DSS (Payment Card Industry Data Security Standard), standardowi bezpieczeństwa organizacji kartowych. Aktualna wersja to v4.0.1. Dla firmy, która sama przetwarza dane kart, oznacza to pokaźny pakiet wymagań: separację sieci, dzienniki zdarzeń, skany, testy przeprowadzane przez uznany podmiot.

Mały sklep nie chce się w to angażować i nie musi. Stała zasada: dane kart nigdy nie trafiają do Państwa sklepu. Klient wpisuje je u Państwa operatora płatności (Mollie, Stripe, PayPal, WooPayments lub inny, lekcja 4.4). Sklep otrzymuje potem tylko informację: zapłacono lub nie, wraz z identyfikatorem. Bez numeru karty, bez kodu. Oznacza to również:

• nigdy nie tworzyć własnego pola formularza na numery kart, nawet "tylko na chwilę, dla zamówienia telefonicznego";
• nigdy nie przyjmować danych kart przez e-mail, czat lub telefon i nie zapisywać ich w notatce do zamówienia;
• nie używać wtyczki, która przechowuje dane kart we własnej bazie danych.

Przekierowanie lub osadzenie: SAQ A

Małe sklepy wykazują zgodność z PCI DSS za pomocą SAQ (Self-Assessment Questionnaire, kwestionariusz samooceny). Operator płatności czasem o to prosi. Najlżejszy jest SAQ A, przeznaczony dla sklepów, które w całości zlecają obsługę płatności na zewnątrz. W sklepie działa to na dwa sposoby:

1. Przekierowanie. Po kliknięciu "zamów" klient przechodzi na stronę płatności operatora, a potem wraca. Sklep nigdy nie widzi danych kart, nawet strony, na której są wpisywane.
2. Osadzony formularz. Pole płatności znajduje się na Państwa stronie zamówienia, ale jest iframe (fragmentem strony) operatora. Dane kart trafiają z przeglądarki bezpośrednio do operatora.

Od 31 marca 2025 obowiązuje nowa wersja SAQ A. Zawiera ona warunek, który dotyczy przede wszystkim drugiego sposobu: kto używa osadzonego formularza, musi potwierdzić, że jego strona nie jest podatna na ataki za pomocą skryptów, które mogą dotknąć system płatności. Tłem jest e-skimming: złośliwy skrypt na stronie zamówienia, który podgląda to, co wpisuje klient, albo nakłada fałszywe pole płatności na prawdziwe. Kto przekierowuje na stronę operatora, nie podlega temu warunkowi. Prosimy zapytać operatora płatności, który SAQ dotyczy Państwa integracji; on wie to dokładnie.

Co należy zrobić w każdym przypadku:

• Strona zamówienia powinna być możliwie pusta. Każdy skrypt na tej stronie może w zasadzie podglądać dane: widżety czatu, menedżery tagów, piksele reklamowe, narzędzia do testów A/B. Na stronie zamówienia prosimy ładować tylko to, co jest potrzebne do płatności. Menedżer tagów na stronie zamówienia to furtka, przez którą każdy, kto ma dostęp do tego konta, może dodawać skrypty.
• Mało wtyczek i aktualnych (lekcja 6.2). Większość przypadków e-skimmingu w WordPress zaczyna się od luki we wtyczce lub skradzionego hasła administratora.
• Content-Security-Policy (nagłówek, który określa, z jakich domen mogą pochodzić skrypty) ogranicza szkody, jeśli coś jednak się przedostanie. To zadanie dla kogoś, kto potrafi to przetestować; błędna CSP psuje przycisk płatności.

https i HSTS na stronie zamówienia

To, że cały sklep działa przez https, jest oczywiste (kurs WordPress, lekcja 3.1). W przypadku strony zamówienia dochodzą dwie rzeczy:

• http musi od razu przekierowywać na https, przekierowaniem stałym (301 lub 308). Klient, który kiedyś wpisze http://shop.example.com/afrekenen/, nie może otrzymać niezaszyfrowanej strony.
• HSTS (HTTP Strict Transport Security) to nagłówek, którym nakazują Państwo przeglądarce otwierać stronę przez pewien czas wyłącznie przez https. Zapobiega to przechwyceniu pierwszego niezaszyfrowanego żądania w otwartej sieci Wi-Fi. max-age wynoszący co najmniej 180 dni to powszechnie przyjęte minimum. HSTS prosimy włączyć dopiero wtedy, gdy wszystko, łącznie z obejmowanymi subdomenami, działa przez https: przeglądarka, która zobaczyła HSTS, odrzuca potem http. KB 6752 wyjaśnia, jak to skonfigurować.

Treści mieszane (skrypt lub arkusz stylów ładowany przez http na stronie https) na stronie zamówienia są szczególnie niebezpieczne: właśnie taki plik może zostać podmieniony w trakcie przesyłania.

Card testing

Przy card testing przestępcy wykorzystują Państwa sklep do sprawdzania skradzionych numerów kart. Automatycznie składają setki drobnych zamówień. Każda udana płatność mówi im, że karta działa. Państwo otrzymują stos nieudanych zamówień, opłaty za transakcje, obciążenia zwrotne, a w najgorszym przypadku operatora płatności, który blokuje konto.

Jak to rozpoznać: wiele zamówień w krótkim czasie, często tego samego taniego produktu, z różnymi nazwiskami, ale z tymi samymi lub dziwnymi adresami, i wiele zamówień ze statusem Niepowodzenie.

Jak to ograniczyć:

• Rate limiting (limit liczby żądań w danym czasie). Store API WooCommerce, z którego korzystają bloki koszyka i zamówienia, ma wbudowany rate limiting, ale jest on domyślnie wyłączony. W WooCommerce > Ustawienia > Zaawansowane > Funkcje można włączyć "Rate limiting Checkout block and Store API" dla składania zamówień. Za pomocą kodu (filtra) można samodzielnie ustawić limit; domyślnie jest to 25 żądań na 10 sekund i liczą się tylko zamówienia oraz inne operacje zapisu. Jeśli sklep działa za proxy lub CDN, trzeba włączyć obsługę proxy, w przeciwnym razie wszyscy odwiedzający liczą się jako jeden.
• Captcha lub podobna bariera przy składaniu zamówienia. WooCommerce samo podaje, że rate limiting i captcha najlepiej działają razem: atakujący często zmieniają adres IP.
• Ustawienia operatora płatności. Operatorzy mają własne filtry antyfraudowe i limity. Prosimy je włączyć i sprawdzać, co zgłaszają.
• 3-D Secure (dodatkowe potwierdzenie w aplikacji bankowej, element silnego uwierzytelniania klienta w UE) utrudnia działanie przestępcom i w razie sporu często przenosi odpowiedzialność na bank posiadacza karty.

Inne oszustwa

Nie każde oszustwo jest zautomatyzowane. Sygnały, które razem stanowią powód, by wstrzymać się z wysyłką:

• adres rozliczeniowy i adres dostawy w różnych krajach lub adres dostawy w firmie przesyłającej paczki dalej;
• pierwsze zamówienie zawierające wyłącznie drogie, łatwe do odsprzedania produkty, z wysyłką ekspresową;
• kilka prób z różnymi kartami;
• klient, który po zapłacie prosi o wysyłkę na inny adres.

Obciążenie zwrotne (chargeback) to cofnięcie płatności kartą przez bank klienta. Tracą Państwo kwotę, często wraz z opłatami, a produktu już nie ma. Dlatego prosimy przechowywać dowody wysyłki i doręczenia. Płatności iDEAL (Holandia) dotąd nie można było cofnąć w ten sposób; jak wygląda to w przypadku Wero, dowiedzą się Państwo od operatora płatności (lekcja 4.4). W Polsce popularne metody płatności to BLIK, szybkie przelewy (pay-by-link), karty płatnicze i PayPal; o zasadach cofania tych płatności również informuje operator.

Podsumowanie

• Dane kart nigdy nie trafiają do Państwa sklepu: ani do formularzy, ani do notatek, ani do e-maili. Przetwarza je operator płatności.
• Przekierowanie na stronę płatności lub osadzone pole operatora pozwala pozostać przy najlżejszym kwestionariuszu PCI (SAQ A); przy osadzonym polu strona zamówienia musi być chroniona przed atakami za pomocą skryptów.
• Strona zamówienia powinna być możliwie pusta, działać przez https z przekierowaniem 301 z http oraz z HSTS na co najmniej 180 dni.
• Card testing ogranicza się za pomocą rate limiting (domyślnie wyłączonego), captchy i filtrów operatora.
• Prosimy zwracać uwagę na sygnały oszustwa i przechowywać dowody doręczenia na wypadek obciążeń zwrotnych.

Quiz

Zadanie

Zadanie A6.3: Czy Państwa strona zamówienia jest bezpieczna? Prosimy podać adres sklepu i adres strony zamówienia. Program sprawdza certyfikat, pobiera stronę zamówienia przez http (bez podążania za przekierowaniem) i przez https (z pustym koszykiem, nic nie jest zamawiane). Zielony, jeśli certyfikat jest ważny, http przekierowuje kodem 301 lub 308 na https, nagłówek Strict-Transport-Security ma max-age wynoszący co najmniej 180 dni, nie ma treści mieszanych, a skrypty na stronie ładuje najwyżej pięć innych domen (program je wyświetla). Pomarańczowy przy braku lub zbyt krótkim HSTS, przekierowaniu tymczasowym (302 lub 307), więcej niż pięciu domenach skryptów lub menedżerze tagów albo przy polu numeru karty we własnym kodzie HTML zamiast u operatora. Czerwony, jeśli https lub certyfikat są nieprawidłowe, http nie przekierowuje albo skrypty lub arkusze stylów ładują się przez http. Danych kart nigdy nie należy przechowywać samodzielnie. Ta kontrola widzi tylko to, co jest na stronie bez koszyka.

Pytanie dla Państwa (niesprawdzane): czy Państwa wtyczka płatności przekierowuje do operatora, czy pole płatności znajduje się na Państwa stronie? Który SAQ według operatora obowiązuje?

Zielony znacznik oznacza, że ta kontrola jest teraz w porządku, a nie że Państwa sklep jest bezpieczny.

Dalsza lektura

Kroki w panelu dotyczą WebOké; u innych dostawców działa to podobnie.

• Darmowy kurs WordPress 3.1: Https i certyfikat
• Nagłówki HSTS i nagłówki bezpieczeństwa dla Państwa strony internetowej
• Wymuszone przekierowanie odwiedzających na https
• Instrukcja DirectAdmin 6.4: Zawsze przekierowuj odwiedzających na https
• Bezpłatny kurs Bezpieczny internet dla przedsiębiorców 4.2: Państwa strona internetowa: https, HSTS i nagłówki bezpieczeństwa
• Aktualizacje SAQ A (PCI Security Standards Council, po angielsku): https://blog.pcisecuritystandards.org/important-updates-announced-for-merchants-validating-to-self-assessment-questionnaire-a
• Rate limiting dla Store API (developer.woocommerce.com, po angielsku): https://developer.woocommerce.com/docs/apis/store-api/rate-limiting/
• Card testing attacks and the Store API (developer.woocommerce.com, po angielsku): https://developer.woocommerce.com/2024/12/18/card-testing-attacks-and-the-store-api/