Proteggersi dal Race condition

[iacoposk8]

Ciao a tutti! ho letto un libro che si chiama "La sicurezza delle applicazioni web" e parlava di un attacco chiamato "Race condition".
Faceva l'esempio di un sito di pocker, dove ci sono ad un tavolo 3 utenti, che in realtà sono la stessa persona, ma registrata con account diversi.
Un utente ha 1000 euro e gli altri due zero.
Quindi con uno script si creano due flussi paralleli che invocano la pagina che si occupa del trasferimento dei soldi.
Il primo controllo che farà è vedere se ci sono effettivamente i 1000 euro da trasferire, ma siccome ho lanciato due thread paralleli il controllo andrà a buon fine per entrambe le richieste, e quindi sposterà 1000 euro a un utente e 1000 all'altro raddoppiando il suo capitale.
Questo è solo un esempio, credo che qualsiasi gioco multiplayer possa essere vulnerabile a questo attacco... la mia domanda è:
Come mi posso proteggere?

[oly1982]

Non conoscevo questa problematica e non ci avevo mai pensato... però effettivamente. Seguirò questa discussione sperando che qualcuno risponda.

[_debo]

Non mi è molto chiaro come nel tuo esempio possa verificarsi una race conditions? Non stai accedendo a risorse condivise. Ricorda inoltre che le race condition si verificano maggiormente in contesti muti-thread

[satifal]

Dovrebbe essere sufficiente utilizzare contesti transazionali quando possibile oppure bloccare una particolare risorsa finchè le operazioni che la coinvolgono non vengono completamente espletate.

[iacoposk8]

Originariamente inviato da _debo
Non mi è molto chiaro come nel tuo esempio possa verificarsi una race conditions? Non stai accedendo a risorse condivise. Ricorda inoltre che le race condition si verificano maggiormente in contesti muti-thread

Si infatti nel mio esempio esiste il multi-thread, forse l'ho spiegato male, ma era in queste frasi:

Originariamente inviato da iacoposk8
Quindi con uno script si creano due flussi paralleli
...
siccome ho lanciato due thread paralleli

Originariamente inviato da satifal
Dovrebbe essere sufficiente utilizzare contesti transazionali quando possibile oppure bloccare una particolare risorsa finchè le operazioni che la coinvolgono non vengono completamente espletate.

è preticamente come si può fare?

[Virus_101]

C On i controlli adeguati si fa.

ad esempio giochi a poker :

1- fai 1 conto soldi totali = soldi giocatori
2- se i totali nelle transazioni > soldi totali BANNA TUTTI

Il problema si verifica perche' vengono esguite 2 transazioni nello stesso tempo. quindi
in primis non eseguire mai le transazioni (movimenti dei crediti di gioco) nello stesso momento ma le inserisci in una coda. Quindi le richieste arrivano ma non vengono eseguite subitissimo.
Vengono accodate in un buffer di richieste e quindi processi il buffer => hai fregato chi ti vuole fregare

[iacoposk8]

Originariamente inviato da Virus_101
1- fai 1 conto soldi totali = soldi giocatori
2- se i totali nelle transazioni > soldi totali BANNA TUTTI

E questa soluzione andrebbe sicuramente bene per questo esempio, la mia domanda era più a scopo didattico, non sto facendo un gioco di poker

Originariamente inviato da Virus_101
Il problema si verifica perche' vengono esguite 2 transazioni nello stesso tempo. quindi
in primis non eseguire mai le transazioni (movimenti dei crediti di gioco) nello stesso momento ma le inserisci in una coda.

Da come mi immaginerei il gioco, non farei che ogni volta che si finisce una "mano" di gioco parta un refresh/redirect di una pagina che faccia tutti i movimenti di soldi. Ma per non far ricaricare la pagina userei ajax, quindi se un utente malintenzionato capisce qual'è la pagina che si occupa dei movimenti e che parametri GET/POST gli passa, potrebbe creare uno script che con qualche injection o da remoto possa eseguire un multi-thread a questa pagina, quindi (idealmente) il multi-thread è possibile con qualche "escamotage" quindi... l'uso "normale" dell'applicazione non lo permetterebbe

Originariamente inviato da Virus_101
Quindi le richieste arrivano ma non vengono eseguite subitissimo.
Vengono accodate in un buffer di richieste e quindi processi il buffer => hai fregato chi ti vuole fregare

Ecco, con questo metodo, come logica si può risolvere tutti le minacce di race condition (credo) ma questo buffer in che forma si presenta? come lo avevi immaginato? tipo elenco di record in un database?

grazie mille a tutti

[Virus_101]

puoi creare questi buffers comme tabelle temporanee oppure una bella tabellona buffer (ovviamente dipende da quanta gente ci sta smanacciando sopra) pero' sono problemi risolvibili con un job manager o da cron temporizzate ogni x tempo fatte occulatamente.

COsi' ti risolvi un sacco di problemi in quanto anche se viene eseguita una richiesta doppia questa viene accodata controllata ed eventualemtne scartata e segnalata l'anomalia.

Sappi che non e' porprio immediata come cosa da fare e ti servireanno almeno 3 tabelle

1- main match buffer
2- processing list
3- logs
x- e forse altre

il main buffer e' quello che e' una lista di richieste con determinati parametri

la processing list serve per tenere traccia di cosa stanno facendo i cron jobs

la terza serve per ovviamente loggare (ma puoi fare anche in altro modo)


l'idea e' :
si parte dai push delle richieste nel buffer

dopo tempo x parte cron
1-> controlla da pocessing list se ci sono altre istanze di cron a lavoro sui match in corso
2-> esegui selezione delle request non in fase di processamento in base al controllo al punto precedente
3-> esegui processamento e traccia nella proccess list cosa stai processando.


Questo serve perche' se l'ìistanza del cron job non termina prima del clock potresti avere 2 istanze dello stesso cron che lavorano sugli stessi dati.

Fatto questo vedrai che non potranno fre request duplicate etc...

Questo epro' genera problemi di gestione sincronia lato cron tab e controllo operazioni per l'utente. Ma sono problemi risolvibili con un poca di attenzione che d'altro canto evitano una marea di problemi di utenti malintenzionati

[_debo]

Forse non mi sono spiegato bene.

Allora partiamo da un presupposto sul quale spero siamo tutti d'accordo.

PHP non è multi thread (questo comunque non esclude al 100% le race condition)

Detto questo il punto che non mi è chiaro è, se ho tre account diversi registrati, uno con 1000 euro e due senza, anche nell'eventualità che si verifichi una race condition su di un trasferimento soldi, mi spieghi come faccio a richiedere di trasferire soldi che non ho?

Il primo controllo che farà è vedere se ci sono effettivamente i 1000 euro da trasferire, ma siccome ho lanciato due thread paralleli il controllo andrà a buon fine per entrambe le richieste, e quindi sposterà 1000 euro a un utente e 1000 all'altro raddoppiando il suo capitale.

Questa situazione non ha senso, non vedo proprio come possa verificarsi.

Tre account diversi insistono su tre entità diverse e sono associati a tre balance account diversi... per questo non capisco come possa questo specifico scenario essere problematico.

[Virus_101]

Se hai request concorrenti potrebbe essere che lo scriptx che gestisce il balancing viene chiamato nello stesso moento da 3 scripts.

Quindi hai 3 script che lavorano sugli stessi dati nello stesso momento.

Php non eì mthread ... beh apache si (o thread o forks cmq e' in grado di eseguire richieste simultanee e avviare script simultaneamente) quindi cio rende gli scrip php parallellizzati e queste condizioni posso creare problemi.
Appunto lo stesso script eseguito 3 volte su set di dati condivisi puo' creare problemi . E quandi appunto il fatto che un trasferimento viene duplicato nel momento in cui esegui lo script 2 volte e la prima esecuzione non e' terminata prima della seconda.

Mettere le richieste asicnrone in un buffer sincorno puo' aiutare ad evitare il problema.