Luka, którą opisujesz, to stan rasy.

Jest kilka sposobów, aby sobie z tym poradzić, ale poleciłbym SELECT ... FOR UPDATE Zapytanie SQL, które blokuje wybrane wiersze, aby zapobiec nowym zapisom do czasu zatwierdzenia bieżącej transakcji.

Pamiętaj, aby sprawdzić dokumentację RDBMS, aby sprawdzić, jak poprawnie zaimplementować:

• PostgreSQL
• MySQL
• MariaDB

Inne rozwiązanie tutaj jest absolutnie słuszne i ma sens w przypadku większych systemów, w których nie jest to takie łatwe.

Mając dane, które posiadasz, jest to stosunkowo proste, możesz skorzystać z opcji nieblokującej:

  UPDATE [FESTIVAL_TICKET] SET IS_SCANNED = TRUEWHERE TICKET_ID = @ScannedKey AND IS_SCANNED = FALSE  

To jest niepodzielna operacja. Żadne dwóch użytkowników bazy danych nie może wydać tego i kazać jej zaktualizować wiersza. Osoba, która otrzyma zwrot „1 wiersz dotknięty” (oczywiście istnieje sposób, aby to sprawdzić w kodzie, nie analizuj tego tekstu) może wejść. Wszyscy inni otrzymają zero wierszy, na które ma wpływ instrukcja. Jeśli chcesz być przyjazny dla użytkownika, możesz teraz sprawdzić, dlaczego nie można go znaleźć, czy był to zły identyfikator, czy jest już przeskanowany.

Ale ważny szczegół jest taki, że stwierdzenie jest niepodzielne. Tylko jeden wygra, bez względu na to, jak blisko jest zerowej różnicy czasu. Ponieważ nie masz już czytania i potem zapisu. Masz odczyt i zapis w jednej operacji atomowej.

Wadą tego wydaje się , że osoba może wejść za darmo (ze skopiowanym biletem).

W przypadku małych wydarzeń, które prawdopodobnie są poprawne.
Jednak jeśli dodasz zbyt duże opóźnienie z jakiegokolwiek powodu, ryzykujesz więcej niż wejście osoby .
skanery biletów po prostu przepuszczą kilka dodatkowych osób, jeśli ich urządzenia się zacinają lub są zbyt wolne ... ponieważ, do cholery, większość z nich prawdopodobnie ma ważne bilety, prawda?

Widziałem, jak to się dzieje podczas ważnego wydarzenia w tym roku kalendarzowym, w którym uczestniczyło tysiące fanów muzyków, o których wielu słyszało.
firma biletowa była główną firmą (może ta, dla której pracujesz?) i znajdowała się w miejscu, które zostało specjalnie zbudowane do przyjmowania biletów.
Moja grupa była jedną z tych, które przepuszczano bez skanowania (i tak ... Miałem ważny / legalny bilet).
Musiałem tam stać i obserwować przyjmujących bilety kilka minut, zanim mogłem się domyślić, dlaczego tak się stało.

TL; DR;
Nie koduj na każdą ewentualność kiedy zaangażowani są ludzie .
Strzelaj za dwie lub trzy dziewiątki (99% -99,9%) i nazwij to dniem.
Zachowaj wybór nicka, gdy w grę wchodzą tylko maszyny ... wtedy możesz zdobyć kilka dziewiątek.

Ta odpowiedź ma już świetną i tanią odpowiedź, jednak dodałbym własną odpowiedź zarówno z punktu widzenia inżynierii oprogramowania , jak i bezpieczeństwa. Może to pomóc w przyszłych podobnych pytaniach dotyczących mało prawdopodobnych exploitów .

i chociaż teoretycznie jest to możliwe ... W prawdziwym scenariuszu prawdopodobnie by się to nie udało.

A zatem, jakie są potencjalne szkody w porównaniu z kosztami? Mam zamiar udowodnić, że wysiłek i ból głowy na dodatkowe zabezpieczenia nie są warte ryzyka.

Teraz rozwiązanie już zaproponowane i zaakceptowane, aby poprawnie obsługiwać warunki wyścigu z transakcjami SQL, przenosząc odpowiedzialność / koszt na bazę danych , to najlepsze, zgodne ze standardami branżowymi i tańsze rozwiązanie. To może być koniec sprawy, ponieważ odpowiedź rzeczywiście została zaakceptowana”.

Jak już wspomniano, zdarzenie polegające na tym, że obaj uczestnicy są skanowani w bardzo dokładnym momencie i wyzwalają Exploit związany z sytuacją wyścigową można oszacować na milion, jeśli nie miliardy wielkości. Aby dać Ci jakościowy pogląd na szanse miliarderów, przeczytaj ten artykuł o loteriach i przekonaj się, że granie w SuperEnalotto na drugiej liście może być łatwą grą w porównaniu ze skanowaniem dwóch biletów, a nagroda jest zdecydowanie spójna. Szanse reprezentują możliwość wykorzystania luki, która jest zwykle klasyfikowana na dyskretnych poziomach ([bardzo] mało prawdopodobne, [bardzo] prawdopodobne ). Zawsze porównuję niedeterministyczne wydarzenia związane z bezpieczeństwem z loterią, aby zapewnić bardziej znane porównanie.

Aby dodatkowo wyjaśnić, na szanse wpływają:

• Możliwość aby zsynchronizować ich przemieszczanie się w kolejkach i jednocześnie wręczać bilet strażnikowi. Oznacza to, że obaj mają ciągłą komunikację i trenują się, nie wspominając o szczęściu (szanse!), Że ich linie poruszają się z przewidywalną prędkością.
• Fizyczny ruch strażników. Nie wszyscy strażnicy skanują bilety dokładnie w milisach, poruszają rękami z różnymi prędkościami. Jeden z biletów może spaść z rąk strażnika, jeden strażnik może odwrócić bilet. Jeden strażnik może się odwrócić, aby sprawdzić, czy linia nie jest zablokowana za nim. Innymi słowy, istnieje nadmierna entropia podczas planowania ataku
  • Bezzałogowe automaty do sprawdzania biletów mogą nie podlegać wpływowi tego czynnika
• Czas potrzebny systemowi komputerowemu na zeskanowanie biletu, tak aby dwa skany wypadały w tym samym przedziale czasowym i luka została wykorzystana.

A więc tutaj jest kwestia inżynierii oprogramowania.

Bilet ma swoją cenę, więc jest wart X $. Szacuję, że wielkość X może być rzędu 50-100. Każda osoba wykorzystująca lukę i wchodząca do obiektu w sposób nieuczciwy wiąże się z utratą X $.

Wdrażanie bardziej złożonych kontroli (np. Kontrola nazwiska paszportu) jest kosztowne zarówno pod względem kod wymagany w fazie tworzenia oprogramowania i czas potrzebny ludziom na wejście do obiektu. Ochroniarze są opłacani co godzinę. Wdrożenie kontroli bezpieczeństwa w stylu Ben-Guriona * jest znacznie droższe i bardziej bolesne dla uczciwych.

Teraz chcesz spać lepiej, mając pewność, że nikt nie może wykorzystać Twojego systemu. Ile to kosztuje? Po zapłaceniu olbrzymiej sumy pieniędzy za zabezpieczenie systemu może się okazać, że Twój konkurent, prowadzący „niezabezpieczony” system, toleruje stratę 80 USD z prawdopodobieństwem ponad miliona wielkości. Trudno jest oszacować to prawdopodobieństwo. Ponieważ masz większe szanse na wygranie najtrudniejszej loterii na świecie, lepiej postaw na to, że na dobre odejdziesz z pracy!

Wniosek: w naszym zawodzie szanse na wygraną są naszym najlepszym śpiącym partnerem!

Wniosek 2: ataki na warunki wyścigu mogą być prawdopodobne wykorzystane w zautomatyzowanych systemach sieciowych, w których atakujący mogą oczywiście zsynchronizować się co do mikrosekundy !!! To może również zwielokrotnić szkody, więc witaj z zadowoleniem najlepsze środki bezpieczeństwa!

Wniosek 3: jeśli system już działa, wysiłek związany z łataniem go akceptowaną odpowiedzią (projekt , programowanie, testowanie, UAT, wdrożenie, PMO ...) jest droższe od potencjalnych szkód. Proszę o komentarz poniżej

* Podałem to jako przykład, ponieważ linie bezpieczeństwa na lotniskach w Izraelu są legendarnie długie i dokładne

Tutaj są już dobre odpowiedzi, które obejmowały wiele exploitów części bazy danych, ale chciałem dodać moje prawdziwe doświadczenie, pracując na polu imprezy (festiwalu na świeżym powietrzu) ​​i projektując weryfikację biletów system i aplikacje.

Jednym z największych wyzwań jest stabilność sieci, ponieważ założenie, że wszystkie urządzenia skanujące mają możliwość pracy w sieci przez cały czas, jest dość błędne. Mogą wystąpić opóźnienia, przerwy lub niedostępność w dowolnym momencie podczas skanowania i nie powinno to opóźniać wejścia klientów na wydarzenie (przynajmniej z naszego punktu widzenia, inne wydarzenia mogą wymagać ściślejszej walidacji).

W naszej aplikacji bilety były sprawdzane przy użyciu podpisu, ale były synchronizowane i zatwierdzane w bazie danych tylko wtedy, gdy sieć była aktywna. Aplikacja zapisała sprawdzone / przeznaczone do zatwierdzenia bilety w zasobniku i próbowała zatwierdzić jak najwięcej biletów, gdy sieć była dostępna. Unikaj również wykonywania jednego INSERT na bilet.

Najdalej przy wejściu na wydarzenie wifi w ogóle nie docierało. Aby zaoszczędzić na kosztach posiadania innego routera dla zaledwie 10 metrów większego zasięgu, urządzenia skanujące mogą komunikować się między nimi i udostępniać swoje połączenia. Oznacza to, że gdyby tylko jedno urządzenie miało dostęp do Wi-Fi, inne mogłyby teoretycznie wysłać do niego swoje wiadra lub do najbliższego urządzenia w zasięgu, które je przekaże.

Prawdziwe życie pokazało nam, że większość z nich urządzenia skanujące traciły połączenie przynajmniej raz na minutę.

Teoretycznie więc jeden bilet może zostać zeskanowany przez dowolną liczbę niepodłączonych urządzeń, ale tylko raz na urządzenie. To jest stan rasy, ale o wiele bardziej trywialne wykorzystanie niż wspomniane inne odpowiedzi.

Słowo na temat Jak temu zapobiec? :

Możesz zapobiec wyścigowi, usuwając równoległość, co robi blokada. Wprowadzi opóźnienia, ponieważ zasadniczo ograniczasz zdolność bazy danych do akceptowania współbieżnych zapisów.

Pytanie brzmi, czy warto? Czy możemy zaakceptować dłuższe opóźnienie do weryfikacji, aby zapewnić prawidłowe uwierzytelnienie? Czy to uniemożliwi ludziom znalezienie otwartych drzwi lub przeskoczenie przez płot?

Dobrym rozwiązaniem może być użycie kolejki komunikatów zamiast wprowadzania opóźnień. Zeskanowany bilet nie jest przetwarzany od razu, czeka, aż wszystkie wysłane bilety zostaną przetworzone. System nie zwraca odpowiedzi, chyba że bilet opuścił kolejkę i został poprawnie przetworzony. Argumentem byłoby to, że mogłoby to być powolne, ponieważ każdy musi czekać, aż inni skończą. ale możesz logicznie podzielić identyfikatory biletów na fragmenty, na przykład: 2 kolejki, 1 dla biletów nieparzystych i 1 dla biletów parzystych. lub po prostu umieść numery grup w samym identyfikatorze.

Jest to typowy problem spowodowany niedopasowaniem między projektem Twojego systemu księgowego („księgowość” oznacza tutaj śledzenie wykorzystania dowolnego zasobu lub pozycji, nie tylko pieniędzy), a rzeczywistymi informacjami, które chcesz śledzić. p>

Wyjaśniłeś, że w prawdziwym świecie możliwe jest dwukrotne zeskanowanie kodu i chcesz śledzić tę sytuację, ale Twoja baza danych przechowuje tylko informację „została przeskanowana”. To nie jest błędne, jeśli chodzi o to, co się dzieje: SET is_scanned = TRUE WHERE ticket_id =? będzie rzeczywiście poprawne (jeśli w świecie rzeczywistym stan „ticket_id?” Został przeskanowany wcześniej, to jest nadal prawdziwe), ale to nie jest to, co chcesz rejestrować.

Zamiast utrzymywać stan, prowadź księgę: tabelę skanuj z nagłówkiem ticket_id, scanned_timestamp , scanner_id , gdzie kluczem są wszystkie trzy z tych pól.¹ W ten sposób rejestrujesz nie tylko to, że bilet został zeskanowany, ale każdy skan bilet. Jeśli nie ma wierszy zawierających ticket_id =? , wiesz, że bilet nigdy nie został zeskanowany, w przeciwnym razie masz listę wszystkich razy, kiedy został zeskanowany (i gdzie).

Teraz, gdy Twoja baza danych jest w stanie lepiej modelować informacje ze świata rzeczywistego, możesz zdecydować, co chcesz z tym zrobić. Twój konkretny DBMS może zaoferować jakiś sposób na obejście tego warunku wyścigu ( INSERT identyfikator_ biletu, skaner_id INTO skanuje GDZIE bilet_id NIE W skanach lub cokolwiek²). Alternatywnie możesz po prostu wpuścić obie osoby, a następnie przeanalizować swoje rekordy, aby dowiedzieć się, dlaczego wydawało się, że masz dwa bilety z tym samym identyfikatorem biletu.

To, którą drogą chcesz iść, jest w rzeczywistości decyzją biznesową, a nie techniczną. Istnieje wiele powodów, dla których możesz nieprawidłowo wystawić dwa ważne bilety z tym samym identyfikatorem biletu (powiedzmy, błąd związany z próbami zwrotu) lub bilet musi zostać użyty dwukrotnie przez tę samą osobę (zapominając o skanowaniu przy wyjściu). Jeśli liczba osób próbujących oszukać system jest niższa niż określony poziom, może być lepiej dla Twojej firmy, aby zjeść cenę kilku oszustów, niż zapłacić koszt (w reputacji, procesach sądowych lub w inny sposób) odmowy posiadania ważnego biletu .

Krótko mówiąc: dopasuj projekt bazy danych do rzeczywistej sytuacji, używając rejestrów zamiast stanów, w których ma to zastosowanie, i pozwól firmie podejmować decyzje biznesowe dotyczące radzenia sobie z rzeczywistymi sytuacjami.

¹ Macham rękami nad wieloma szczegółami tutaj, aby odpowiedź była krótka i wyraziła tylko ogólny pomysł.
² Zakładam tutaj odpowiednią strategię spójności, która ma ten sam efekt podczas serializacji tych żądań INSERT do tej tabeli.

W Clojure mają funkcję zwaną atomami, która zajmuje się takimi problemami.

Wchodzą dwa wątki. Oba odczytują wartość is_scanned = false i kontynuują. Po przetworzeniu swoich rzeczy zwracają is_scanned = true , aby zaktualizować atom. Jednak jeden wątek przyjdzie o chwilę szybciej.

Wątek, który pojawi się trochę później, będzie miał zmieniony atom, więc funkcja nie będzie w stanie zaktualizować atomu. Zamiast tego zostanie poproszony o ponowne uruchomienie z zaktualizowaną już wartością is_scanned = true . A teraz wynik będzie taki, że drugi bilet nie jest już ważny.

Tutaj jest film wyjaśniający tę funkcję clojure.