Sklep, checkout i API zamówień.
Od kuponu do cudzej faktury.
Zbiorczy scenariusz testu e-commerce pokazujący, jak błędy logiki promocji, BOLA w API dokumentów i niewłaściwe zaufanie do statusu płatności wpływają na pieniądze oraz dane klientów.
Bezpieczeństwo checkoutu to więcej niż bramka płatnicza
W skrócie: w kompozytowym scenariuszu opartym na autoryzowanych testach sklepów internetowych ręczna analiza procesu zamówienia ujawniła trzy niezależne błędy: wielokrotne zastosowanie korzyści promocyjnej, odczyt syntetycznej faktury innego konta przez BOLA oraz możliwość wywołania funkcji realizacyjnej przed wiarygodnym potwierdzeniem płatności. Każdy dowód wykonaliśmy na produktach i kontach testowych.
- Ryzyko finansowe: nieuprawniony rabat lub realizacja niezapłaconego zamówienia.
- Ryzyko danych: dostęp do dokumentu zawierającego dane innego klienta.
- Rezultat: serwerowy state machine, idempotencja, autoryzacja dokumentów i weryfikacja podpisanych webhooków.
Autor: Michał Błaszczak · · BSTA sp. z o.o.
biznesowe
CVSS
business flow
transakcji
Produkty, ceny i integracje są syntetyczne
Materiał nie opisuje jednego sklepu. Nazwy sprzedawcy, operatora płatności, endpointów, dokumentów i reguł promocji zostały zmienione. Nie publikujemy danych klientów, tokenów ani szczegółów integracji. Wartości transakcji są przykładowe.
Przegląd kodu HTTP nie wystarczył
Automatyczny skaner nie rozumie, że stan „opłacone” powinien poprzedzać realizację albo że rabat ma być jednorazowy w określonej relacji klient–koszyk–kampania. Te zależności weryfikowaliśmy ręcznie.
Wpływ na poufność i integralność transakcji
Backend nie w każdym kanale weryfikował wiarygodne, końcowe potwierdzenie płatności przed wykonaniem operacji realizacyjnej.
Identyfikator dokumentu nie był wystarczająco powiązany z zalogowanym klientem i jego zamówieniem.
Równoległe lub wielokrotne wywołania mogły ominąć ograniczenie użycia korzyści promocyjnej.
Backend musi być źródłem prawdy o zamówieniu
- Jawny state machine i transakcje atomowe dla koszyka, płatności i realizacji.
- Podpis, świeżość, allowlista zdarzeń i idempotencja webhooków.
- Autoryzacja dokumentów przez relację użytkownik–zamówienie–dokument.
- Serwerowe limity promocji odporne na równoległość i ponowne użycie.
- Alerty dla nietypowych zmian stanu, serii odmów i dostępu do wielu dokumentów.
Co obejmował pentest sklepu internetowego i API płatności
Test potraktował ścieżkę zakupową jako jeden system: od rejestracji i konta klienta, przez katalog, koszyk, kupony, checkout oraz integrację płatniczą, aż po zamówienie, fakturę, zwrot i panel obsługi. Takie podejście pozwala wykryć podatności, które powstają pomiędzy modułami, nawet jeśli każdy komponent osobno przechodzi automatyczne skanowanie.
Zakres obejmował aplikację webową, mobilne wywołania API, endpointy integracyjne, webhooki operatora płatności, zadania asynchroniczne, mechanizmy antyfraudowe i panel administracyjny. Sprawdziliśmy OWASP Top 10, OWASP API Security Top 10 oraz nadużycia logiki biznesowej charakterystyczne dla e-commerce.
- konto klienta: rejestracja, logowanie, MFA, reset hasła, sesje i historia zakupów;
- koszyk i cena: ilości, waluty, kupony, rabaty, program lojalnościowy i równoległość żądań;
- płatność: przekierowania, statusy, webhooki, podpisy, idempotencja i ponowienia;
- dokumenty: zamówienia, faktury, przesyłki, zwroty, reklamacje i kontrola dostępu;
- backoffice: role konsultantów, eksporty, zmiany stanu i operacje masowe.
Testy logiki biznesowej, BOLA/IDOR i race condition w e-commerce
Najważniejsze scenariusze wykonywaliśmy ręcznie na kilku kontach testowych. Dla każdego obiektu — koszyka, zamówienia, faktury, płatności i zwrotu — sprawdzaliśmy właściciela, rolę, stan procesu oraz kanał wywołania. Ten sam warunek musiał być egzekwowany w interfejsie WWW, aplikacji mobilnej, API i zadaniu w tle.
Testy race condition polegały na kontrolowanym wysyłaniu równoległych żądań dotyczących tej samej korzyści. Celem nie było uzyskanie realnego rabatu, ale sprawdzenie, czy backend stosuje blokady, operacje atomowe i klucze idempotencji. Testy webhooków prowadzone były w sandboxie operatora płatności lub na uzgodnionych zdarzeniach kontrolnych.
Nadużycie może wynikać z niewłaściwej kolejności stanów, niespójności pomiędzy ceną w kliencie i backendzie, wielokrotnego użycia kuponu, błędnej autoryzacji faktury lub zaakceptowania starego webhooka. Pentest analizuje cały proces, a nie tylko formularz karty.
Od błędu promocji do danych klienta i integralności zamówienia
Pierwsze znalezisko dotyczyło korzyści promocyjnej. Ograniczenie było widoczne w interfejsie, jednak kilka równoległych operacji przechodziło przez niezależne instancje usługi, zanim centralny stan został zaktualizowany. Potwierdziliśmy mechanizm na produkcie testowym bez realizowania prawdziwej transakcji.
Drugi problem był klasycznym BOLA/IDOR: ważna sesja klienta i poprawny identyfikator dokumentu wystarczały do pobrania faktury, ale API nie zawsze sprawdzało relację dokumentu z właścicielem konta. Dowodem była wyłącznie syntetyczna faktura przygotowana pomiędzy dwoma kontami badawczymi.
Trzecia ścieżka dotyczyła stanu płatności. Jedna funkcja realizacyjna ufała pośredniemu statusowi z procesu zamówienia zamiast zweryfikowanemu, końcowemu zdarzeniu z backendu płatności. Łącznie błędy wpływały na poufność danych, integralność rozliczeń i możliwość fraudu.
Jak przełożyliśmy podatności na ryzyko dla sklepu
Raport nie kończył się na kodach HTTP. Dla każdej podatności wskazaliśmy możliwy wpływ: stratę marży, koszt chargebacków, błędną realizację, ujawnienie danych klienta, wzrost obciążenia obsługi oraz konieczność analizy incydentu. Priorytet uwzględniał skalowalność ataku i to, czy problem można zautomatyzować.
Właściciele procesu otrzymali mapę zależności pomiędzy sklepem, ERP, operatorem płatności, WMS, systemem fakturowym i platformą marketingową. Dzięki temu zalecenia mogły zostać przypisane do konkretnych zespołów, a nie do ogólnego właściciela „IT”.
Najpierw zablokowano możliwość realizacji bez końcowego statusu oraz zawężono dostęp do dokumentów. Następnie wdrożono idempotencję, transakcje atomowe, centralny model stanów, monitoring anomalii i testy regresyjne scenariuszy zakupowych.
Pentest e-commerce przed sezonem, migracją i zmianą płatności
Audyt bezpieczeństwa sklepu internetowego warto wykonać przed Black Friday lub innym okresem szczytowym, po wdrożeniu nowego checkoutu, po zmianie operatora płatności, przed wejściem na nowy rynek, po integracji marketplace oraz po dużej zmianie ERP lub WMS. Test jest również istotny po przejęciu sklepu albo połączeniu kilku kanałów sprzedaży.
Do wyceny przydają się domeny i aplikacje, liczba ról, lista API i integracji, opis płatności, zwrotów i promocji oraz dostępność sandboxu. Możemy podpisać NDA i wykonać badanie na produktach, kontach i dokumentach testowych. Jedno podejście retestowe jest zazwyczaj w cenie, o ile oferta nie stanowi inaczej.
Powiązane usługi: testy penetracyjne sklepu i aplikacji webowej, pentest API od 1 999 zł, testy phishingowe i cennik pentestów.
Najczęstsze pytania o testy penetracyjne sklepu internetowego
Czy pentest obejmuje integrację z operatorem płatności?
Tak, w uzgodnionym zakresie badamy przekierowania, webhooki, podpisy, powtórzenia zdarzeń, idempotencję i sposób wiązania płatności z zamówieniem. Nie testujemy systemu operatora bez jego zgody.
Czy testujecie BOLA i IDOR w zamówieniach oraz fakturach?
Tak. Sprawdzamy, czy klient może odczytać lub zmienić cudze zamówienie, dokument, adres, zwrot albo reklamację przez zmianę identyfikatora, parametru lub kontekstu organizacji.
Czy można przetestować promocje i kupony bez strat finansowych?
Tak. Używamy kont, produktów, cen i kodów testowych albo uzgodnionego środowiska. Scenariusz kończymy przed realną realizacją lub rozliczeniem, chyba że właściciel wyraźnie zatwierdzi inny sposób.
Czy skan podatności wystarczy dla sklepu?
Nie. Automatyzacja pomaga wykryć część błędów technicznych, ale nie rozumie reguł rabatów, kolejności płatności, uprawnień konsultanta ani relacji klient–zamówienie–dokument. Te elementy wymagają testów ręcznych.
Czy pentest sklepu jest tym samym co audyt PCI DSS?
Nie. Pentest może być elementem wymagań PCI DSS w odpowiednim zakresie, ale nie zastępuje całej oceny zgodności. Zakres CDE i obowiązki należy ustalić na podstawie architektury płatności.
Ile trwa pentest e-commerce?
Realizacja testu zajmuje od 5 dni roboczych. Czas zależy od liczby kanałów sprzedaży, ról, integracji, metod płatności i procesów posprzedażowych, a ostateczny termin potwierdza oferta.
Co zawiera raport?
Raport zawiera podsumowanie dla kierownictwa, zakres, metodykę, ścieżki nadużyć, CVSS, STRIDE, bezpieczny PoC, wpływ finansowy i na dane, zalecenia oraz plan priorytetów. Wyniki możemy zaprezentować zespołowi technicznemu i biznesowemu.
Czy wykonujecie retest?
Tak. Jedno podejście retestowe jest zazwyczaj w cenie, o ile oferta nie stanowi inaczej. Sprawdzamy poprawkę i scenariusze zbliżone, aby ograniczyć ryzyko obejścia.
Pentest może być wymaganiem PCI DSS, ale zakres zależy od architektury płatności
PCI DSS dotyczy organizacji przechowujących, przetwarzających lub przesyłających dane kartowe oraz systemów mogących wpływać na bezpieczeństwo CDE. Requirement 11.4 przewiduje testy penetracyjne dla środowisk, do których wymaganie ma zastosowanie. Przekierowanie płatności do operatora może ograniczyć zakres, ale nie usuwa automatycznie ryzyka logiki checkoutu, API zamówień i webhooków.
Źródła: PCI Security Standards Council — PCI DSS, OWASP API Security i OWASP Web Security Testing Guide.
Chcesz sprawdzić cały proces zakupowy, nie tylko formularze?
Testujemy koszyk, promocje, zamówienia, płatności, webhooki, zwroty, faktury, API i panel administracyjny.
Zapytaj o pentest sklepu →