Redakcja
Historia defektu aplikacji obsługującej catering “Kuchnia Vikinga” to klasyczny przykład na to, że najpoważniejsze luki wcale nie muszą być ukryte pod grubą warstwą skomplikowanego kodu. Czasem wystarczy po prostu szybki palec użytkownika i brak odpowiednich zabezpieczeń po stronie bazy danych, by system finansowy firmy zaczął przeciekać. Dla testerów to lekcja o tym, że testy wydajnościowe i badanie współbieżności to podstawa bezpieczeństwa produktu.
Race condition
U podstaw problemu leżała podatność znana jako race condition (wyścig). Mechanizm był zwodniczo prosty: użytkownik mógł anulować zamówienie, co skutkowało zwrotem środków w postaci punktów lojalnościowych. Jednak proces ten nie działał natychmiastowo. Wykorzystując to opóźnienie, spostrzegawczy klient był w stanie kliknąć przycisk anulowania wielokrotnie w krótkim czasie, zanim system zdążył przetworzyć pierwszą prośbę i zmienić status zamówienia.
W efekcie serwer otrzymywał kilka niemal jednoczesnych żądań. Ponieważ aplikacja pozwalała na współbieżny odczyt i modyfikację stanu punktów bez należytej izolacji, każde z tych żądań „widziało” zamówienie jako wciąż aktywne i naliczało punkty wielokrotnie. To podręcznikowy błąd projektowy, w którym stan systemu zmienia się szybciej, niż logika biznesowa potrafi go zablokować.
Model white label
Sprawa nabiera rumieńców, gdy spojrzymy na nią z perspektywy architektury oprogramowania. Aplikacja była dostarczana w modelu white label przez firmę MasterLife Solutions. Oznacza to, że ten sam kod, z tą samą luką, zasilał systemy co najmniej kilku innych dostawców cateringu.
Dla testera oprogramowania to sygnał alarmowy; błąd w jednej wersji bazowej powiela się u wszystkich klientów korzystających z danego rozwiązania. W tym przypadku problem dotyczył nie tylko Kuchni Vikinga, ale również platformy Dietly oraz pięciu innych podmiotów. To pokazuje, jak wielką odpowiedzialność ponoszą zespoły kontroli jakości pracujące nad produktami, które mają stać się fundamentem dla zewnętrznych marek.
Odpowiedzialność i etyka w procesie zgłaszania
Interesującym wątkiem jest sama droga, jaką musiało przebyć zgłoszenie o błędzie. Znalazca luki, który nie był specjalistą od bezpieczeństwa, napotkał spore bariery biurokratyczne. Odesłanie osoby nietechnicznej do profesjonalnych platform typu bug bounty często kończy się zniechęceniem i porzuceniem tematu, co w tym przypadku mogło oznaczać dalsze straty finansowe dla firmy.
Analiza historyczna wykazała, że z błędu korzystali inni, mniej etyczni użytkownicy, generując straty rzędu kilkunastu tysięcy złotych. Dopiero interwencja mediów i sprawne działania CEO Dietly pozwoliły na szybkie załatanie dziury poprzez wdrożenie pesymistycznego blokowania na poziomie bazy danych. Jest to rozwiązanie skuteczne, choć radykalne, wymuszające na systemie obsługę żądań w sposób sekwencyjny tam, gdzie integralność danych jest ważniejsza niż milisekundy opóźnienia.
Lekcje dla zespołów testowych
Czego ta sytuacja uczy osoby odpowiedzialne za jakość? Przede wszystkim tego, że testy funkcjonalne „ścieżki pozytywnej” to dopiero początek. Każdy proces, który wiąże się z portfelem użytkownika lub stanem magazynowym, musi być testowany pod kątem wielokrotnych, szybkich wywołań. Warto weryfikować, jak baza danych radzi sobie z równoległymi zapisami. Brak blokad na poziomie wiersza w krytycznych momentach to zaproszenie do nadużyć. Firmy powinny tworzyć też jasne kanały zgłaszania błędów i defektów dla zwykłych użytkowników. Nie każdy musi wiedzieć, jak wypełnić techniczny raport, by pomóc uratować budżet firmy.
Zakończenie tej historii jest pozytywne – błąd naprawiono w jeden dzień od uzyskania szczegółów, a uczciwy znalazca otrzymał nagrodę, choć wymagało to dodatkowych monitów. Dla nas pozostaje to przypomnieniem, że w testowaniu oprogramowania pesymizm i przewidywanie najdziwniejszych zachowań użytkownika to najbardziej pożądane cechy zawodowe.
Czy w Twoich projektach scenariusze zakładające wielokrotne kliknięcie w przycisk „anuluj” lub „zapłać” są częścią standardowej regresji? Jeśli nie, być może czas je wprowadzić, zanim zrobi to za was ktoś „spostrzegawczy”.
