Cybersecurity& ArchitectureIT Consulting

Ustawienia wyglądu

Wszystkie ustawienia wyglądu i animacji
Omów zakres audytuKontakt
Wróć do wniosków z przeglądu

DEMONSTRACJA E-COMMERCE

Bezpieczeństwo e-commerce: ochrona zamówień i płatności

Trzy odtworzone słabości pokazują przekroczenie granicy zaufania przy dostępie do zamówienia, ustalaniu ceny i potwierdzaniu płatności.

Niezależna demonstracja z przykładowymi klientami, zamówieniami i zdarzeniami płatniczymi. Problemy odtworzono w kontrolowanym modelu. Materiał nie opisuje zlecenia klienta ani audytu działającego sklepu.

Pytanie biznesowe

Czy można odczytać lub przekazać do realizacji zamówienie bez uprawnionego klienta albo zweryfikowanej płatności?

Model referencyjny zawiera syntetycznych klientów, katalog i zamówienie. Sprawdza wybrane reguły aplikacji w pamięci. Lokalna kontrola podpisu płatności modeluje autentyczność; rzeczywista integracja wymaga SDK dostawcy i testów w jego środowisku testowym. Zakres nie obejmuje całego sklepu ani operatora płatności.

Zakres demonstracji

  • Kontrola właściciela zamówienia
  • Ustalanie ceny na etapie zakupu
  • Autentyczność i zgodność potwierdzeń płatności

DEMONSTRACJA E-COMMERCE

Ustalenia i sprawdzone zmiany

SEC-01Priorytet w przeglądzie: Wysoki

Klient może odczytać zamówienie innego klienta

W modelu uwierzytelniony klient uzyskuje dostęp do cudzego zamówienia. W sklepie wpływ na poufność zależałby od ujawnionych pól i liczby dostępnych rekordów.

Zaobserwowany problem
Test zmienia identyfikator zamówienia, zachowując tożsamość drugiego klienta. Odczyt bez kontroli uprawnień zwraca 1 cudze zamówienie ze statusem 200.
Zalecana zmiana
Chroń dane zamówień. Sprawdzaj właściciela przy każdym odczycie i zmianie; tożsamość pobieraj z uwierzytelnionego kontekstu serwera. Odmawiaj dostępu, gdy nie można potwierdzić reguły.
Weryfikacja i dalsze testy
Powtórz próbę między kontami i potwierdź brak danych zamówienia. W rzeczywistym API zachowaj test właściciela oraz testy brakującego zamówienia i nieuwierzytelnionego żądania.

Przed zmianą

Ujawnione cudze zamówienia: 1; status 200.

Po zmianie

Ujawnione cudze zamówienia: 0; status 403.

SEC-02Priorytet w przeglądzie: Wysoki

Zakup przyjmuje cenę przesłaną z przeglądarki

W pokazanym zakupie kwota za produkt jest zaniżona. Samo powodzenie płatności nie potwierdza poprawności naliczonej ceny.

Zaobserwowany problem
Cena katalogowa wynosi EUR 129.00. Podmiana ceny jednostkowej w żądaniu daje kwotę do zapłaty EUR 0.01.
Zalecana zmiana
Chroń kwotę do zapłaty. Wyliczaj ją według zaufanego katalogu oraz reguł ilości, rabatów, podatku i dostawy. Wartości z przeglądarki traktuj jako żądanie, a nie wiążącą cenę.
Weryfikacja i dalsze testy
Ponownie prześlij zmienioną cenę i potwierdź zachowanie poprawnej kwoty. Testy rzeczywistego zakupu rozszerz o błędne ilości, uprawnienia do rabatów, waluty i zaokrąglenia.

Przed zmianą

Kwota do zapłaty: EUR 0.01.

Po zmianie

Kwota do zapłaty: EUR 129.00.

SEC-03Priorytet w przeglądzie: Krytyczny

Niepodpisane potwierdzenie oznacza zamówienie jako opłacone

Model ufa nieuwierzytelnionej wiadomości o sukcesie i zatwierdza opłacenie bez dowodu od źródła płatności. W pokazanej granicy realizacji ma to priorytet krytyczny.

Zaobserwowany problem
Sfabrykowana wiadomość o sukcesie bez podpisu zostaje przyjęta. Poprawiona reguła ją odrzuca, a prawidłowo podpisana i zgodna wiadomość kontrolna nadal zostaje przyjęta.
Zalecana zmiana
Chroń decyzję o realizacji. Sprawdzaj podpis dostawcy na oryginalnej treści wiadomości, a następnie zgodność płatności, zamówienia, kwoty i waluty. Stosuj kontrole aktualności i powtórzeń dostawcy.
Weryfikacja i dalsze testy
Odrzucaj niepodpisane, zmienione, nieaktualne i niezgodne potwierdzenia. Sprawdź poprawną wiadomość kontrolną. Lokalny test HMAC potwierdza regułę modelu; nadal potrzebna jest weryfikacja SDK i środowiska testowego dostawcy.

Przed zmianą

Niepodpisana wiadomość oznacza opłacenie: tak.

Po zmianie

Niepodpisana wiadomość oznacza opłacenie: nie; poprawna podpisana wiadomość przyjęta: tak.

Jakie decyzje wspiera przegląd

  • Tożsamość klienta i właściciela zamówienia muszą być częścią decyzji o uprawnieniach na serwerze.
  • Katalog i reguły cenowe muszą określać kwotę przed utworzeniem płatności.
  • Realizację zamówienia dopuszczaj po zweryfikowanym, zgodnym przejściu płatności; sprawdź integrację z dostawcą przed wdrożeniem.

Co otrzymujesz po przeglądzie

Rejestr ustaleń z priorytetami, konkretne zmiany mechanizmów ochrony i testy regresji dla drogi od klienta do płatności.

Powiązana usługaZobacz strukturę raportu z audytu

Materiały techniczne

Źródła wyjaśniają zasady działania zabezpieczeń. Powyższe obserwacje pochodzą z lokalnej demonstracji.

Poznaj pozostałe przeglądy

Wnioski z przeglądu

KONTAKT

Omów zakres audytu.

Zacznij od pytania biznesowego, ogólnego opisu systemu i preferowanego terminu. Poufność i zasady postępowania z informacjami ustalamy przed udostępnieniem materiałów technicznych.

Wybierz przycisk, aby wyświetlić adres e-mail lub numer telefonu.

Pracuję z Polski. Audyty na miejscu u klienta w kraju i za granicą ustalam indywidualnie.

Przygotuj się do audytu