Potwierdzona operacja.
Ale które dane?

Uwierzytelnienie to dopiero początek

Wielostopniowa operacja może wyglądać bezpiecznie: użytkownik jest zalogowany, widzi ekran potwierdzenia, a osobny komponent zatwierdza działanie. W jednym z ostatnich autoryzowanych przeglądów kodu aplikacji webowej i API sprawdziliśmy, czy wszystkie etapy odnoszą się do tej samej operacji oraz do tych samych danych.

Badanie było wyłącznie statyczne. Nie uruchamialiśmy aplikacji, nie wysyłaliśmy żądań do systemów ani nie potwierdzaliśmy exploitu w działającym środowisku. Poniżej opisujemy mechanizmy widoczne w analizowanym kodzie i ryzyka wymagające testów integracyjnych. Schematy są edukacyjne; nie publikujemy kodu klienta, nazw systemów, endpointów ani parametrów pozwalających go zidentyfikować.

Potwierdzenie nie obejmowało wszystkich istotnych danych

Prześledziliśmy przepływ od danych wejściowych do przygotowania potwierdzenia i wykonania zmiany. Analizowany mechanizm wiązał potwierdzenie z częścią kontekstu, ale nie uwzględniał wszystkich istotnych danych przekazywanych później do wykonania operacji. To stwarzało ryzyko, że zmiana części danych nie będzie odpowiednio odzwierciedlona w weryfikacji.

Nie oznacza to złamania funkcji skrótu ani kryptografii. Pytanie dotyczyło tego, jakie dane objęto ochroną i co backend porównuje przed wykonaniem działania. Nawet poprawnie użyty mechanizm kryptograficzny nie chroni informacji, których do niego nie włączono.

Najnowsza inicjacja nie musi być właściwą inicjacją

Kolejnym obszarem było przypisywanie odpowiedzi do rozpoczętego procesu. W badanym kodzie znaleźliśmy wyszukiwanie najnowszej inicjacji według wspólnych cech użytkownika i rodzaju działania, zamiast jednoznacznego powiązania z konkretną transakcją.

Przy równoległych działaniach albo opóźnionych odpowiedziach taki wzorzec może przypisać wynik do innej inicjacji niż oczekiwana. Nie ogłaszamy tu potwierdzonego przejęcia cudzej operacji: wskazujemy ryzyko błędnej korelacji i wyścigu, które trzeba sprawdzić w testach integracyjnych.

Powtórzenie i równoległe wykonanie to osobne pytania

W przeglądanej warstwie nie znaleźliśmy kompletnej, lokalnej kontroli jednorazowego wykorzystania potwierdzenia dla mutującej operacji. Zaznaczyliśmy, że ochrona przed replay mogła istnieć w innym komponencie. Brak jej w dostępnym kodzie nie uprawnia do stwierdzenia, że cały system akceptuje każde ponowienie.

Plan dalszych testów powinien rozróżnić ponowne wysłanie tej samej operacji, dwie równoległe próby oraz opóźnione powiadomienie. Idempotencja i jednorazowość potwierdzenia rozwiązują powiązane, ale różne problemy: pierwsza ogranicza powielone skutki, druga pilnuje użycia zgody w dozwolonym kontekście.

Logi zapisywały więcej, niż potrzebowała diagnostyka

Przegląd ścieżek błędów i logowania ujawnił zapisywanie pełnych tokenów JWT oraz komunikatów zawierających dane wrażliwe. Było to ustalenie dotyczące kodu i konfiguracji logowania. Nie badaliśmy, kto faktycznie odczytywał te logi ani czy doszło do użycia zapisanych tokenów.

Zaleciliśmy ograniczenie logowania do informacji niezbędnych do diagnostyki i audytu, maskowanie danych oraz przegląd dostępu i retencji. Rekomendacje dotyczące wyłączania sekretów i wrażliwych informacji z zapisów opisuje OWASP Logging Cheat Sheet. Monitoring bezpieczeństwa potrzebuje użytecznych zdarzeń; nie wymaga kopiowania całej treści żądań.

Działanie zewnętrzne i lokalny zapis mogą się rozejść

Sprawdziliśmy również obsługę błędów pomiędzy systemami. W analizowanym przepływie wykonanie działania zewnętrznego i zapis lokalnego stanu nie tworzyły jednej atomowej całości. Przy błędzie pośrednim możliwe były rozbieżności wymagające obsługi, a mechanizm ponowień nie miał wystarczająco wyraźnych ograniczeń.

Samo użycie lokalnej transakcji bazy nie gwarantuje spójności z usługą zewnętrzną. Potrzebne są jasno zdefiniowane stany, zasady ponowień, rozpoznawanie już wykonanej operacji i proces uzgadniania rozbieżności. W raporcie oddzieliliśmy widoczny wzorzec implementacji od niezweryfikowanej częstotliwości jego skutków na produkcji.

Jak sprawdzamy odporność całego przepływu

Wiązanie danych. Ustalenie niezmiennego stanu operacji po stronie serwera i objęcie potwierdzeniem jej istotnych parametrów. Przy zmianie tych danych potrzebna jest ponowna autoryzacja.

Wiązanie odpowiedzi. Jednoznaczny identyfikator procesu, kontrola jego właściciela i dozwolonych przejść stanu. Bez wyboru procesu tylko dlatego, że jest najnowszy.

Testy negatywne. Zmienione dane, ponowione i równoległe żądania, opóźniona odpowiedź, błąd integracji i rozbieżność lokalnego stanu. Wynik ma określać także, czy operacja została wykonana dokładnie raz.

Te zalecenia są spójne z zasadami autoryzacji operacji przedstawionymi w OWASP Transaction Authorization Cheat Sheet. W praktyce przegląd kodu pomaga wskazać warunki, a pentest aplikacji i testy integracyjne weryfikują je na uzgodnionym środowisku.

Secure code review i pentest API w praktyce