Sklep internetowy może działać bezbłędnie dla klientów, a jednocześnie pozwalać osobie z najtańszym kontem podejrzeć cudzą fakturę, powtórnie wykorzystać kod rabatowy albo wywołać operację zarezerwowaną dla administratora. Takich problemów nie wykrywa obserwowanie sprzedaży ani standardowy monitoring dostępności. Trzeba spróbować wykorzystać aplikację niezgodnie z jej przeznaczeniem — w kontrolowanych warunkach, z ustalonym zakresem i bez narażania prawdziwych danych.
Test penetracyjny aplikacji webowej odpowiada na pytanie ważniejsze niż „czy mamy zabezpieczenia?”: czy zabezpieczenia rzeczywiście powstrzymają atak. W e-commerce stawką nie jest wyłącznie ciągłość działania witryny. Zagrożone są konta klientów, dane adresowe, historia zamówień, dokumenty sprzedażowe, rabaty, płatności, integracje z ERP i kurierami oraz panel administracyjny.
Najdroższe luki w e-commerce nie zawsze wyglądają jak awaria
Certyfikat TLS, firewall aplikacyjny i regularne aktualizacje są potrzebne, ale nie dowodzą, że sklep jest bezpieczny. HTTPS szyfruje transmisję, lecz nie sprawdza, czy użytkownik ma prawo pobrać wskazaną fakturę ani czy serwer prawidłowo przelicza wartość koszyka.
W praktyce szczególnie niebezpieczne są błędy kontroli dostępu. Przykład: klient otwiera adres zamówienia zakończony numerem 15482, zmienia go na 15483 i otrzymuje dane innego kupującego. Aplikacja odpowiada poprawnie technicznie — kodem 200, bez komunikatu o błędzie — lecz ujawnia informacje osobie bez uprawnień. Automatyczny skaner może tego nie rozpoznać, ponieważ nie rozumie relacji między kontem, zamówieniem i dokumentem.
Pentester sprawdza między innymi:
- przejęcie konta przez błędy logowania, resetowania hasła, sesji lub uwierzytelniania wieloskładnikowego;
- Broken Access Control, w tym dostęp do cudzych zamówień, adresów, faktur, zgłoszeń i danych w API;
- SQL Injection, XSS i SSRF, czyli podatności pozwalające wpływać na bazę danych, przeglądarkę użytkownika albo zasoby wewnętrzne;
- możliwość zmiany ceny, waluty, kosztu dostawy, liczby produktów lub wartości rabatu w żądaniu wysyłanym bezpośrednio do serwera;
- wielokrotne użycie jednorazowego kuponu, pominięcie minimalnej wartości koszyka albo połączenie promocji, których regulamin nie pozwala łączyć;
- obejście etapów płatności, potwierdzenie zamówienia bez poprawnej odpowiedzi operatora lub ponowne przetworzenie tego samego komunikatu;
- upload plików, formularze, wyszukiwarkę, filtry oraz funkcje importu danych;
- tokeny API, klucze techniczne, pliki konfiguracyjne i informacje pozostawione w kodzie frontendu;
- panel administratora, konta pracowników, role magazynowe, księgowe i obsługi klienta.
W e-commerce błąd logiki biznesowej bywa droższy niż klasyczna luka techniczna. Sklep może poprawnie odrzucać znaki używane w SQL Injection, a jednocześnie pozwalać wysłać żądanie z ceną produktu równą 1 groszowi. Interfejs użytkownika pokazuje właściwą kwotę, lecz zabezpieczenie po stronie przeglądarki nie ma znaczenia, jeśli serwer ufa parametrom przesłanym przez klienta.
Podobny problem dotyczy kolejności operacji. System zakłada, że kupujący najpierw wybierze produkt, później zapłaci, a na końcu otrzyma potwierdzenie. Atakujący sprawdza, co stanie się po pominięciu drugiego kroku, cofnięciu procesu, powtórzeniu żądania albo równoczesnym wysłaniu kilkudziesięciu operacji. Skuteczny pentest nie testuje tylko formularzy. Testuje założenia zespołu, który zaprojektował sprzedaż.
Co Pentestica powinna objąć zakresem, aby test miał wartość biznesową
Zakres testu trzeba ustalić przed rozpoczęciem prac. Ogólne zlecenie „sprawdźcie stronę” zwykle kończy się nieporozumieniem: zamawiający oczekuje weryfikacji całej platformy, podczas gdy wycena obejmuje wyłącznie publiczną witrynę i kilka formularzy.
Dla sklepu internetowego zakres powinien wskazywać konkretne domeny, aplikacje, interfejsy API, role oraz procesy. Najczęściej należy uwzględnić:
- stronę sklepu i panel klienta;
- panel administracyjny oraz zaplecze pracowników;
- API używane przez frontend i aplikację mobilną;
- konta klienta, konsultanta, partnera B2B i administratora;
- rejestrację, logowanie, reset hasła i zmianę adresu e-mail;
- koszyk, rabaty, płatność, zwroty i anulowanie zamówienia;
- integracje z operatorem płatności, ERP, CRM, WMS, marketplace’em i firmą kurierską;
- mechanizmy webhooków i cykliczne zadania wymieniające dane między systemami.
W wielu sklepach najlepszy stosunek czasu do liczby wykrytych problemów daje test grey box. Pentester otrzymuje dokumentację, kilka kont o różnych rolach i podstawowe informacje o architekturze, ale nadal próbuje przełamać zabezpieczenia z perspektywy użytkownika. Nie traci wtedy kilku dni na odgadywanie funkcji, które zespół może mu po prostu wskazać.
Test black box, wykonywany bez dokumentacji i kont testowych, lepiej symuluje przypadkowego napastnika z internetu, lecz ma ograniczenie: część czasu pochłania rozpoznanie systemu. Przy sztywnym budżecie może zabraknąć godzin na dokładne sprawdzenie rabatów, uprawnień i integracji. White box daje dostęp do kodu lub szczegółowej dokumentacji i ułatwia głębszą analizę, ale wymaga dobrego przygotowania materiałów po stronie firmy.
Proces powinien obejmować co najmniej:
- Ustalenie zasad testu — zakres, dozwolone techniki, godziny pracy, adres kontaktowy na wypadek awarii, zasady korzystania z danych oraz procedurę przerwania testów.
- Rozpoznanie i analizę powierzchni ataku — domeny, subdomeny, endpointy, role, technologie, integracje i publicznie dostępne zasoby.
- Skanowanie wspierające pracę ręczną — pomocne przy identyfikacji znanych błędów, ale niewystarczające jako samodzielna usługa.
- Ręczną weryfikację podatności — próby wykorzystania błędów, łączenia ich w scenariusze i oceny realnych konsekwencji.
- Raport techniczny i zarządczy — dowody, kroki odtworzenia, ryzyko, wpływ na biznes, lokalizacja problemu i sposób naprawy.
- Retest — ponowne sprawdzenie podatności po wdrożeniu poprawek.
Oferta Pentestica wskazuje cenę testów penetracyjnych od 8 000 zł, przy czym końcowa kwota jest ustalana indywidualnie. Na wycenę wpływają przede wszystkim liczba aplikacji i ról, wielkość API, liczba procesów sprzedażowych, rodzaj testu, dostęp do dokumentacji oraz zakres retestu. Prosty sklep oparty na gotowym silniku jest innym projektem niż marketplace z kilkoma panelami, aplikacją mobilną, indywidualnymi cennikami B2B i integracjami magazynowymi.
Najtańsza oferta nie zawsze jest oszczędnością. Trzeba sprawdzić, ile osobodni pracy specjalisty obejmuje, czy zawiera testy ręczne, analizę logiki biznesowej i retest. Raport wygenerowany głównie przez skaner może mieć kilkadziesiąt stron, a mimo to nie odpowiedzieć, czy klient potrafi zmienić cenę, podejrzeć cudze zamówienie lub przejąć konto.
Dobry raport powinien zawierać:
- opis podatności i jej dokładną lokalizację;
- warunki potrzebne do wykorzystania błędu;
- kroki pozwalające zespołowi technicznemu odtworzyć problem;
- bezpieczny proof of concept;
- ocenę ryzyka technicznego i skutków biznesowych;
- informację, jakie dane albo funkcje są zagrożone;
- konkretną rekomendację naprawy;
- priorytet oraz wskazanie, czy problem wymaga retestu.
Sama punktacja CVSS nie wystarcza. Luka oceniona technicznie jako średnia może być krytyczna dla sklepu, jeśli pozwala wygenerować nieograniczoną liczbę kuponów albo odczytać ceny przypisane do klientów B2B. Z drugiej strony brak jednego nagłówka HTTP nie powinien wyprzedzać naprawy błędu umożliwiającego przejęcie konta administratora.
Niedogodność jest realna: pentest wymaga zaangażowania zespołu sklepu. Trzeba przygotować konta, dokumentację, środowisko, dane testowe i osobę zdolną szybko odpowiedzieć na pytania. Test produkcji może też powodować alerty w systemach ochronnych, tworzyć zamówienia testowe i generować wiadomości e-mail. Bez wcześniejszego oznaczenia kont oraz uzgodnienia reguł obsługa klienta zaczyna reagować na działania pentestera jak na prawdziwy incydent.
Kiedy wykonać test i które poprawki wdrożyć najpierw
Pierwszy pełny test najlepiej przeprowadzić przed uruchomieniem sklepu albo dużej funkcji, gdy aplikacja jest już gotowa technicznie, ale nie obsługuje jeszcze normalnego ruchu. Testowanie nieukończonego modułu marnuje budżet, bo wyniki szybko tracą aktualność. Test wykonany dopiero po kampanii startowej jest natomiast spóźniony: luki trafiają na produkcję razem z klientami i płatnościami.
Pentest powinien zostać zaplanowany również:
- po zmianie mechanizmu logowania lub resetowania hasła;
- po wdrożeniu nowego systemu płatności albo przebudowie checkoutu;
- po uruchomieniu aplikacji mobilnej, panelu B2B lub nowej wersji API;
- po migracji hostingu, chmury, frameworka lub silnika sklepu;
- po dużej aktualizacji Magento, WooCommerce, PrestaShop albo autorskiej platformy;
- po incydencie, nawet jeśli jego bezpośrednią przyczyną był phishing lub wyciek hasła;
- przed Black Friday, świętami lub innym okresem, w którym awaria oznacza ponadprzeciętne straty;
- cyklicznie, zwykle co najmniej raz na 12 miesięcy, jeżeli aplikacja jest aktywnie rozwijana.
Coroczny test nie zwalnia z testowania zmian. Jeśli zespół co dwa tygodnie wdraża nowe funkcje, raport sprzed dziesięciu miesięcy opisuje inną aplikację. Rozsądny model to pełny pentest okresowy oraz krótsze testy obszarowe po modyfikacjach uwierzytelniania, płatności, uprawnień i API.
Nie każdy sklep musi testować wszystko w jednym projekcie. Przy ograniczonym budżecie priorytet należy ustalić według możliwego skutku:
- Przejęcie kont i panel administratora — najpierw logowanie, reset hasła, sesje, MFA oraz uprawnienia pracowników.
- Dostęp do danych klientów — zamówienia, faktury, adresy, zgłoszenia, eksporty i endpointy API.
- Płatności i wartość transakcji — ceny, rabaty, waluty, koszty dostawy, zwroty oraz obsługa webhooków.
- Integracje zewnętrzne — ERP, CRM, WMS, kurierzy, marketplace’y i systemy marketingowe.
- Pozostała konfiguracja — nagłówki bezpieczeństwa, komunikaty błędów i podatności o ograniczonym wpływie.
Ta kolejność ma znaczenie. Zespół, który zaczyna od poprawiania wszystkich problemów niskiego ryzyka, może przez kilka tygodni zostawić otwartą lukę pozwalającą pobierać cudze dokumenty.
W przypadku naruszenia danych osobowych administrator może mieć obowiązek zgłoszenia incydentu organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości nie później niż w ciągu 72 godzin od jego stwierdzenia. Ten czas trzeba przeznaczyć równocześnie na analizę zdarzenia, ograniczenie wycieku, zabezpieczenie dowodów, ocenę ryzyka i przygotowanie komunikacji. Nie jest to dobry moment na odkrywanie, gdzie znajdują się logi i kto ma dostęp do konfiguracji.
Sklepy, które przechowują, przetwarzają lub przesyłają dane kart płatniczych albo mogą wpływać na bezpieczeństwo takiego środowiska, muszą także uwzględnić wymagania PCI DSS. Sam fakt korzystania z zewnętrznego operatora płatności może zmniejszać zakres obowiązków, ale nie usuwa odpowiedzialności za własny checkout, skrypty, integracje i kontrolę dostępu.
Pentest nie daje gwarancji braku przyszłych włamań. Wynik opisuje określony zakres aplikacji w określonym czasie. Nowa wersja wtyczki, zmiana konfiguracji, dodatkowy endpoint lub błąd wdrożony tydzień później może utworzyć kolejną podatność. Dlatego raport należy traktować jako listę zweryfikowanych ryzyk i podstawę decyzji technicznych, a nie certyfikat „sklep bezpieczny na zawsze”.
FAQ
Czy test penetracyjny może zatrzymać sklep?
Może obciążyć aplikację albo uruchomić niepożądane procesy, jeżeli zakres i zasady nie zostały ustalone. Testy destrukcyjne, masowe próby logowania i scenariusze wpływające na płatności powinny być uzgodnione osobno. Ryzykowne przypadki najlepiej sprawdzać na środowisku stagingowym możliwie zbliżonym do produkcji.
Czy skaner podatności wystarczy małemu sklepowi?
Nie, jeśli sklep ma konta klientów, koszyk, rabaty, płatności lub API. Skaner pomaga wykrywać znane błędy techniczne, ale nie rozumie, że użytkownik nie powinien pobrać cudzej faktury ani wykorzystać kuponu pięć razy.
Czy testować produkcję, czy staging?
Staging jest bezpieczniejszy dla ryzykownych scenariuszy, lecz musi odwzorowywać wersję kodu, konfigurację i integracje produkcyjne. Produkcja pokazuje faktyczny stan systemu, dlatego część niedestrukcyjnych testów warto wykonać również tam.
Jak często robić pentest e-commerce?
Pełny test zwykle co najmniej raz w roku oraz po istotnych zmianach. Moduły logowania, płatności, uprawnień i API należy sprawdzać po każdej większej przebudowie, a nie dopiero w kolejnym rocznym cyklu.
Co naprawić bezpośrednio po otrzymaniu raportu?
Najpierw przejęcie konta, dostęp do cudzych danych, eskalację uprawnień, obejście płatności i błędy panelu administracyjnego. Po wdrożeniu poprawek trzeba wykonać retest, ponieważ zmiana kodu może jedynie ukryć objaw albo utworzyć nowy wariant luki.
Pierwszy krok to nie zakup kolejnego skanera. Trzeba rozpisać pięć krytycznych procesów sklepu: logowanie, dostęp do zamówień, zmianę ceny i rabatu, potwierdzenie płatności oraz operacje administratora. Następnie należy przekazać Pentestica konta dla wszystkich ról i zlecić próbę przełamania właśnie tych ścieżek. Jeżeli budżet nie pozwala objąć całej platformy, zacznij od kontroli dostępu do danych klientów — pojedynczy błąd w tym obszarze potrafi zmienić problem techniczny w pełnoprawne naruszenie danych.
Więcej informacji na: testy penetracyjne aplikacji webowych, Pentestica.
