La vulnerabilità che stai descrivendo è una condizione di competizione.

Ci sono diversi modi per affrontarla, ma preferirei un SELECT ... FOR UPDATE Query SQL, che pone un blocco sulle righe selezionate per impedire nuove scritture fino a quando non viene eseguita la transazione corrente.

Assicurati di controllare la documentazione RDBMS per verificare come implementarla correttamente:

• PostgreSQL
• MySQL
• MariaDB

L'altra soluzione qui è assolutamente giusta e ha senso per sistemi più grandi in cui non è così facile.

Con i dati che hai, che è relativamente semplice, potresti optare per un'opzione non bloccante:

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

Ora, questa è un'operazione atomica. Nessun due utenti del database possono emettere questo e fare in modo che aggiorni la riga. La persona che viene restituita "1 riga interessata" (ovviamente c'è un modo per scoprirlo nel codice, non analizzare il testo per questo) può entrare. Tutti gli altri avranno zero righe interessate dall'istruzione. Se vuoi essere facile da usare, ora puoi verificare perché non è stato trovato, se era l'ID sbagliato o se è già scansionato.

Ma il dettaglio importante è che l'affermazione è atomica. Solo uno vincerà, non importa quanto siano vicini a zero differenza di tempo. Perché non hai più una lettura e poi una scrittura. Hai la lettura e la scrittura in un'unica operazione atomica.

Lo svantaggio di questo sembra essere che una persona potrebbe entrare gratuitamente (con un ticket copiato).

Per piccoli eventi probabilmente è corretto.
Tuttavia, se aggiungi troppo ritardo, per qualsiasi motivo, rischi più di una persona di entrare.
gli scanner di biglietti lasceranno passare alcune persone in più se i loro dispositivi si inceppano o sono troppo lenti ... perché, diamine la maggior parte di loro probabilmente ha biglietti validi, giusto?

L'ho visto accadere durante un importante evento di quest'anno solare a cui hanno partecipato migliaia di fan di musicisti di cui molte persone hanno sentito parlare.
La compagnia di biglietti era una delle principali (forse quella per cui lavori?) ed era in un sito creato su misura per la raccolta dei biglietti.
La mia festa è stata una di quelle che sono state lasciate passare senza una scansione (e sì ... Avevo un biglietto valido / legale).
Dovevo stare lì a guardare gli acquirenti del biglietto alcuni minuti prima di poter capire perché era successo.

TL; DR;
Non codificare per ogni evenienza quando le persone sono coinvolte .
Scatta per due o tre nove (99% -99,9%) e chiamalo un giorno.
Salva la scelta dei nick per quando sono coinvolte solo le macchine ... è allora che puoi ottenere un mucchio di 9.

Questa risposta ha già un'ottima ed economica risposta, tuttavia, aggiungerei la mia risposta sia dal punto di vista dell ' ingegneria del software che dal punto di vista della sicurezza. Questo può essere utile per future domande simili su improbabili exploit .

e sebbene sia possibile in teoria ... In uno scenario reale, probabilmente non funzionerebbe.

E poi, qual è il potenziale danno rispetto al costo? Dimostrerò che spendere sforzi e grattacapi per una sicurezza aggiuntiva non vale il rischio.

Ora, la soluzione già proposta e accettata per gestire correttamente le condizioni di gara con le transazioni SQL, spostando la responsabilità / costo sul database , è la soluzione migliore, standard del settore ed economica. Potrebbe essere la fine del caso, poiché la risposta è stata effettivamente accettata”.

Come già sottolineato, il fatto che entrambi gli assistenti vengano scansionati nel momento esatto e attivino il l'exploit della condizione di razza potrebbe essere stimato in probabilità di milioni se non di miliardi di grandezza. Per darti un'idea qualitativa delle probabilità dei miliardari, leggi questo articolo sulle lotterie e scopri che giocare per quel SuperEnalotto in cima alla seconda lista potrebbe essere un gioco facile rispetto alla scansione di due biglietti e la ricompensa è decisamente coerente. Le probabilità rappresentano l ' sfruttamento di una vulnerabilità e che normalmente è qualificata in livelli discreti ([molto] improbabile, [molto] probabile ). Confronto sempre gli eventi non deterministici relativi alla sicurezza con la lotteria per fornire un confronto più familiare.

Per fare ulteriori chiarimenti, le probabilità sono influenzate da:

• La capacità di i due sincronizzano il loro spostamento tra le code e allo stesso tempo consegnano il biglietto alla guardia. Ciò implica che i due abbiano una comunicazione costante e si siano allenati, per non parlare della fortuna (probabilità!) Che le loro linee si muovano a velocità prevedibili
• Il movimento fisico delle guardie. Non tutte le guardie impiegano il tempo esatto in millisecondi per scansionare i biglietti, muovono le braccia a velocità diverse. Uno dei biglietti potrebbe cadere dalle mani della guardia, una guardia potrebbe trattenerlo al contrario. Una guardia può girarsi per controllare se la linea non è bloccata dietro di loro. In altre parole, c'è un'entropia eccessiva per pianificare un attacco
  • Le macchine di controllo dei biglietti senza equipaggio potrebbero non essere influenzate da questo fattore
• Il tempo necessario al sistema informatico per eseguire la scansione del biglietto, in modo che le due scansioni rientrino nella stessa fascia oraria e la vulnerabilità venga sfruttata.

Quindi ecco la considerazione dell'ingegneria del software.

Il biglietto ha un prezzo, quindi vale X $. Stimo che la grandezza di X possa essere nell'ordine di 50-100. Per ogni persona che sfrutta la vulnerabilità e accede alla struttura in modo fraudolento, si applica una perdita di $ X.

Implementare controlli più complessi (ad es. Controllo del nome del passaporto) è costoso entrambi in termini di il codice richiesto nella fase di sviluppo del software e il tempo impiegato dalle persone per entrare nella struttura. Le guardie di sicurezza vengono pagate ogni ora. Implementare un controllo della sicurezza in stile Ben-Gurion * è molto più costoso e doloroso per gli onesti.

Ora, vuoi dormire meglio assicurato che nessuno possa sfruttare il tuo sistema. Quanto costa? Dopo aver pagato una somma di denaro esorbitante per proteggere il tuo sistema potresti scoprire che il tuo concorrente, che gestisce un sistema "non protetto", sta tollerando una perdita di $ 80 con probabilità di uno su milioni di grandezza. È difficile quantificare questa probabilità. Dato che hai più probabilità di vincere alla lotteria più difficile del mondo, è meglio che scommetti per lasciare il tuo lavoro per sempre!

Conclusione: nella nostra professione, le probabilità di vincita sono il nostro miglior partner addormentato!

Conclusione 2: gli attacchi in condizioni di competizione possono essere probabili sfruttati su sistemi di rete automatizzati dove gli aggressori possono ovviamente sincronizzarsi al microsecondo !!! Ciò potrebbe anche moltiplicare il danno, quindi benvenute le migliori misure di sicurezza!

Conclusione 3: se il sistema è già in esecuzione, lo sforzo di patchare con la risposta accettata , sviluppo, test, UAT, rollout, PMO ...) è più costoso del potenziale danno. Si prega di commentare di seguito

* L'ho citato come esempio perché le linee di sicurezza degli aeroporti in Israele sono leggendariamente lunghe e complete

Ci sono già buone risposte qui che hanno coperto gran parte degli exploit della parte del database, ma volevo aggiungere la mia esperienza di vita reale , avendo lavorato nel campo degli eventi (festival all'aperto) e progettando la convalida dei biglietti sistema e applicazioni.

Una delle grandi sfide è la stabilità della rete, perché il presupposto che tutti i dispositivi di scansione abbiano sempre funzionalità di rete è sbagliato. Possono verificarsi ritardi, interruzioni o indisponibilità in qualsiasi momento durante la scansione processo e questo non dovrebbe ritardare le iscrizioni dei clienti all'evento (almeno dal nostro punto di vista, altri eventi potrebbero richiedere una convalida più rigorosa).

Nella nostra applicazione, i biglietti sono stati convalidati utilizzando una firma, ma lo erano sincronizzato e impegnato nel database solo quando la rete era attiva. L'applicazione ha archiviato i ticket convalidati / di cui eseguire il commit in un bucket e ha cercato di eseguire il commit del maggior numero di ticket possibile una volta che la rete era disponibile. Evita anche di fare un INSERT per ticket.

All'estremità dell'ingresso all'evento, il wifi non arrivava affatto. Per risparmiare sui costi di avere un altro router per soli 10 metri in più di copertura, i dispositivi di scansione potrebbero comunicare tra loro e condividere le loro connessioni. Significa che se solo uno dei dispositivi avesse accesso al wifi, gli altri potrebbero teoricamente inviare i loro bucket ad esso, o al dispositivo più vicino nel raggio d'azione che lo inoltrerà.

La vita reale ci ha mostrato che la maggior parte di i dispositivi di scansione hanno perso la connessione almeno una volta in un minuto.

Quindi, in teoria, un ticket potrebbe essere scansionato da tutti i dispositivi non collegati che desidera, ma solo una volta per dispositivo. Questa è una condizione di competizione, ma molto più banale da sfruttare rispetto a quanto menzionato nelle altre risposte.

Una parola sul Come prevenirlo? :

Puoi prevenire la race condition, rimuovendo il parallelismo, che è ciò che fa un lock. Introdurrà latenze poiché stai sostanzialmente riducendo la capacità del tuo database di accettare scritture simultanee.

La domanda quindi diventa: ne vale la pena? Possiamo accettare un ritardo maggiore fino alla convalida per garantire la corretta autenticazione? Questo impedirà alle persone di trovare una porta aperta o saltare una recinzione?

Una buona soluzione potrebbe essere quella di utilizzare una coda di messaggi invece di inserire ritardi. Il ticket scansionato non viene elaborato immediatamente, attende che tutti i ticket inviati prima di essere elaborati. E il sistema non restituisce una risposta a meno che il ticket non abbia lasciato la coda e non sia stato elaborato correttamente. Un argomento a favore potrebbe essere lento perché tutti devono aspettare che gli altri finiscano. ma puoi logicamente frammentare gli ID dei biglietti, ad esempio: 2 code, 1 per i biglietti con numero dispari e 1 per quelli con numero pari. o semplicemente inserire i numeri di gruppo nell'ID stesso.

Questo è un tipico problema causato da una mancata corrispondenza tra il design del tuo sistema contabile (la "contabilità" qui sta monitorando l'uso di qualsiasi risorsa o oggetto, non solo denaro) e le informazioni del mondo reale che desideri monitorare.

Hai spiegato che nel mondo reale è chiaramente possibile che un codice venga scansionato due volte e desideri monitorare questa situazione, ma il tuo database memorizza solo "è stato scansionato". Questo non è corretto fino in fondo: SET is_scanned = TRUE WHERE ticket_id =? sarà effettivamente corretto (se nel mondo reale lo stato era "ticket_id? È stato scansionato" prima, e questo è ancora vero ora), ma in realtà non è quello che vuoi registrare.

Invece di mantenere uno stato, tieni un libro mastro: una tabella scan con intestazione ticket_id, scanned_timestamp , scanner_id , con la chiave che è tutti e tre questi campi.¹ Stai quindi registrando non solo che un biglietto è stato scansionato, ma ogni scansione del biglietto. Se non ci sono righe contenenti ticket_id =? , sai che il biglietto non è mai stato scansionato, altrimenti hai un elenco di tutte le volte che è stato scansionato (e dove).

Ora che il tuo database è in grado di modellare meglio le informazioni del mondo reale, puoi decidere cosa fare al riguardo. Il tuo particolare DBMS può offrire un modo per aggirare questa condizione di competizione ( INSERT ticket_id, scanner_id INTO scans WHERE ticket_id NOT IN scans o qualsiasi altra cosa²), nel qual caso eviti definitivamente due voci per lo stesso ticket_id. In alternativa, potresti semplicemente far entrare entrambe le persone e successivamente analizzare i tuoi record per capire il motivo per cui sembra che tu abbia due biglietti con lo stesso ticket_id.

Il modo in cui vuoi andare è in realtà una decisione aziendale, non tecnica. Ci sono molti motivi per cui potresti emettere in modo errato due biglietti validi con lo stesso ticket_id (ad esempio, un bug relativo ai tentativi di restituzione) o un biglietto deve essere utilizzato due volte dalla stessa persona (dimenticando di scansionare all'uscita). Se il numero di persone che tentano di imbrogliare il sistema è inferiore a un certo livello, potrebbe essere meglio per la tua azienda mangiare il costo di alcuni imbroglioni piuttosto che pagare il costo (in reputazione, azioni legali o altro) di negare un titolare di biglietto valido .

In breve: abbina il design del tuo database alla situazione reale del mondo, utilizzando libri contabili anziché stati in cui ciò si applica, e lascia che l'azienda prenda le decisioni aziendali su come affrontare queste situazioni del mondo reale.

¹Sto gesticolando qui su molti dettagli per mantenere la risposta breve ed esprimere solo l'idea generale.
² Presumo qui una strategia di coerenza appropriata che abbia lo stesso effetto come serializzare queste richieste INSERT in questa tabella.

In Clojure hanno una funzionalità chiamata atomi per prendersi cura di questi problemi.

Entrano due thread. Entrambi leggono il valore is_scanned = false e procedono. Dopo aver elaborato il loro contenuto, restituiscono is_scanned = true per aggiornare atom. Tuttavia, un filo arriverà un po 'più velocemente.

Il thread che arriva un po 'più tardi avrà l'atomo cambiato, quindi quella funzione non sarà in grado di aggiornare l'atomo. Verrà invece detto di rieseguire se stesso con il valore ora aggiornato di is_scanned = true . E ora il ritorno sarà che l'altro biglietto non è più valido.

Ecco un video che spiega questa funzione di clojure.