Zakupy za grosze: wykrycie podatności Price Manipulation w checkout e-commerce

Podczas testów penetracyjnych aplikacji mobilnej i API dużego e-commerce (RTV/AGD) znaleźliśmy podatność typu Price Manipulation w procesie checkoutu. Aplikacja wysyłała wartość koszyka do bramki płatności w JSON i backend jej ufał (bez ponownego przeliczenia po stronie serwera). Zrobiliśmy kontrolowany proof-of-concept, a potem wdrożenie naprawy: serwerowa rekalkulacja koszyka, podpisywanie krytycznych parametrów oraz testy regresji pod fraud. Efekt: zamknięcie wektora, który mógł generować realne straty finansowe i trudne do wykrycia nadużycia.

Kontekst: klient, skala i presja biznesowa

Klient to jedna z największych sieci sprzedaży elektroniki w Polsce, z ruchem liczonym w tysiącach transakcji na godzinę. Sprzedaż szła wielokanałowo: web i aplikacja mobilna, do tego promocje, raty, kody rabatowe, limity magazynowe, integracje z dostawcami i bramkami płatności.

Kiedy organizacja rośnie, pojawia się typowy problem: fraudy nie zawsze wyglądają jak „włamanie”. Czasem to po prostu zamówienia, które „jakimś cudem” finalizują się za zbyt małe kwoty, a później są księgowane i… trudno wskazać moment, w którym system się pomylił.

To był punkt startu: podejrzenie nadużyć w zamówieniach i rozjazdy w księgowości, bez jasnego źródła.

Problem: backend ufał danym z klienta (a nie powinien)

W procesie checkoutu aplikacja mobilna budowała payload do płatności i przekazywała m.in. kwotę zamówienia. To samo w sobie nie jest zbrodnią, bo klient (app) musi coś pokazać użytkownikowi.

Krytyczny błąd polegał na tym, że backend nie traktował kwoty jako danych wyłącznie prezentacyjnych, tylko jako „źródła prawdy”. W efekcie atakujący mógł przechwycić żądanie i zmodyfikować wartość koszyka.

To klasyczny wzorzec: trusting client-side data. I to jest dokładnie ten typ rzeczy, którego automatyczne skanery często nie złapią, bo to nie jest „jedna podatność w jednym polu”, tylko logiczny błąd na styku aplikacji, API i płatności.

Jak pracowaliśmy: podejście Pentestica do fraud w checkout

Zrobiliśmy testy w modelu grey-box, z kontami testowymi i pełną zgodą klienta na symulację scenariuszy fraud (w kontrolowanych warunkach). Skupiliśmy się na:

• całej ścieżce od koszyka, przez promocje i dostawę, aż po inicjację płatności,
• punktach, gdzie system przenosi dane pomiędzy warstwami (aplikacja → API → payment gateway),
• porównaniu „co widzi użytkownik” vs „co liczy backend”.

Rzecz, która w praktyce często robi różnicę: testowaliśmy warianty z rabatami, kuponami, ratami, darmową dostawą i zmianą produktów w koszyku tuż przed płatnością. W takich miejscach najłatwiej o niespójność.

Odkrycie: Price Manipulation w żądaniu inicjującym płatność

W trakcie analizy ruchu sieciowego zauważyliśmy, że aplikacja przesyłała kwotę jako pole w JSON. I co gorsza, backend przyjmował ją bez pełnej weryfikacji.

Żądanie prawidłowe (wartość koszyka zgodna):

POST /api/v1/checkout/init
Authorization: Bearer <token>
Content-Type: application/json

{
  "cartId": "CART-8f21",
  "amount": 4500.00,
  "currency": "PLN",
  "paymentMethod": "card",
  "itemsHash": "a91d...3f"
}

Żądanie zmanipulowane (zmiana kwoty):

POST /api/v1/checkout/init
Authorization: Bearer <token>
Content-Type: application/json

{
  "cartId": "CART-8f21",
  "amount": 1.00,
  "currency": "PLN",
  "paymentMethod": "card",
  "itemsHash": "a91d...3f"
}

W kontrolowanym środowisku testowym, przy spełnieniu konkretnych warunków (wariant ścieżki checkoutu), transakcja przechodziła z obniżoną kwotą. To nie był „magiczny hack”, tylko konsekwencja logiki: jeśli backend nie policzy jeszcze raz koszyka i nie porówna kwoty, to dostaje do podpisania i przekazania dalej wartość, którą ktoś mu podsunie.

Ryzyko biznesowe: dlaczego to jest „pieniądze na ziemi”

W e-commerce skutki są brutalnie proste:

• bezpośrednie straty finansowe (czasem masowe, bo atak łatwo zautomatyzować),
• trudne do wykrycia nadużycia (wygląda jak „prawidłowe zamówienie”, tylko tanie),
• ryzyko chargebacków i konfliktów z operatorem płatności,
• ryzyko reputacyjne, bo w pewnym momencie „promocje życia” zaczynają krążyć po sieci.

Co ważne: tego typu podatności bardzo często wychodzą dopiero przy specyficznych kombinacjach rabatów, integracji i edge-case’ów. Dlatego “mamy dobry payment gateway” nie rozwiązuje problemu. Gateway płaci, backend decyduje za ile.

Remediacja: co wdrożyliśmy, żeby problem nie wrócił

Naprawa była zaprojektowana tak, żeby była odporna na przyszłe zmiany w checkout (a te w e-commerce są nieuniknione).

1) Serwerowa rekalkulacja koszyka przed inicjacją płatności
Backend przelicza koszyk od zera na podstawie źródła prawdy (produkty, ceny, rabaty, dostawa), a amount z klienta traktuje co najwyżej jako informację pomocniczą. Jeśli są rozbieżności, żądanie jest odrzucane.

2) Podpisywanie krytycznych parametrów (HMAC) tam, gdzie to miało sens
Wprowadziliśmy podpis dla kluczowych elementów, które muszą przetrwać pomiędzy krokami (np. id koszyka, wersja koszyka, wybrane opcje). Nie po to, żeby „zastąpić” rekalkulację, tylko żeby utrudnić manipulację na ścieżkach, gdzie dane są przenoszone pomiędzy systemami.

3) Testy regresji nastawione na fraud
Dodaliśmy testy negatywne typu: „zmieniam amount”, „zmieniam ilość”, „dodaję kupon po stronie klienta” i oczekuję odrzucenia albo rekalkulacji. To jest ten element, który ratuje przyszłość, bo checkout będzie modyfikowany.

Po wdrożeniu poprawek wykonaliśmy retesty i potwierdziliśmy, że manipulacja kończy się blokadą, a system zawsze opiera się na serwerowym wyliczeniu.

Efekt: co klient dostał poza “zamkniętą luką”

Po tej akcji klient zyskał nie tylko fix, ale też wzorzec projektowy: co w checkout jest danymi prezentacyjnymi, a co musi być liczone i weryfikowane po stronie serwera. W praktyce to zmniejsza liczbę podobnych błędów przy kolejnych feature’ach, szczególnie przy promocjach i integracjach.

To też jeden z tych przypadków, gdzie bezpieczeństwo bezpośrednio chroni marżę. Bez metafor.

Jak Pentestica może pomóc

Realizujemy testy penetracyjne; pentesty aplikacji mobilnych, web i API, a w e-commerce bardzo często dokładamy warstwę „fraud logic”, bo tam ryzyko nie kończy się na wycieku danych.

Jeśli masz checkout, aplikację mobilną lub integracje z bramkami płatności i chcesz wiedzieć, czy backend na pewno nie ufa temu, czemu nie powinien, zrobimy audyt w modelu, który daje Ci konkret: wektor ataku, priorytet ryzyka, rekomendację naprawy i testy regresji, żeby temat nie wrócił.