Sicurezza del Web Game su WebSockets?

3

Il progetto su cui sto lavorando dipende da WebSockets per comunicare tra il server e il browser client per tutte le interazioni all'interno del gioco. Sto frequentando l'università per Computer Security, ma non sono ancora sicuro dei potenziali attacchi contro il sistema di validazione corrente.

Inizierò molto velocemente e dirò che in questo momento non posso usare Secure WebSockets a causa di Autobahn ( ancora ) che non supporta Secure WebSockets. Se devo cambiare il mio framework che sto usando per risolvere eventuali problemi, lo farò comunque.

Come funziona adesso, collegando l'utente richiede la chiave pubblica del server (2048 bit) che può essere modificata a intervalli regolari, il server fornisce la chiave pubblica all'utente. Per convalidare la chiave, un rapido scambio di invio di una stringa nota costante crittografata con la chiave viene inviato al server e il server verifica che la chiave sia corretta per l'utente. Dopo aver verificato la chiave, il client crittografa la password in testo semplice fornita dall'utente e la invia al server. Il server decrittografa la password, esegue l'hash della password con bcrypt e convalida la password in un modo resistente agli attacchi di temporizzazione (nessuna interruzione anticipata, quasi costante). La crittografia utilizza un nonce randomizzato come parte del padding per impedire attacchi di riproduzione.

La parte di cui sospetto di più è il modo in cui la mia attuale implementazione "tiene traccia" di quale socket appartiene a chi . Fondamentalmente se una richiesta di "login" viene gestita da un socket e il risultato è positivo, il socket viene "denominato" impostando un attributo speciale sul socket con lo username fornito nella richiesta di accesso.

Al momento della disconnessione, il socket viene distrutto e vi sono dei controlli di stallo per i socket che non hanno ricevuto una richiesta da molto tempo per essere disconnessi automaticamente. L'unico modo per impostare l'attributo su un socket sul lato server è eseguire una richiesta di accesso corretta.

Sono a conoscenza della possibilità di attacco del MITM in merito allo scambio di chiavi.

Le mie preoccupazioni sono quali sono i difetti in questo sistema e come dovrei prevenirli o attenuarli?

    
posta Seth M. Larson 06.01.2016 - 14:44
fonte

1 risposta

2

In sostanza, si dispone di una stringa equivalente alla password (la password crittografata a chiave pubblica), che è sorta di protezione dal requisito per la stringa costante da inviare. Tuttavia, se si tratta di una stringa costante, un utente malintenzionato potrebbe semplicemente riprodurre una vecchia chiamata, in quanto possono ottenere la chiave (è pubblica) dopo tutto. Il nonce randomizzato deve anche essere trasferito al client, o essere generato sul client - in entrambi i casi, poiché accade prima dell'autorizzazione, un utente malintenzionato può presumibilmente ottenerlo.

Potrebbe valere la pena prendere in considerazione l'inclusione di una qualche forma di token in tutte le richieste, disaccoppiando in modo efficace lo specifico socket da un determinato utente e bypassando la tua area principale di interesse - presumibilmente non importa quale socket entri in un utente, finché è possibile dimostrare che la richiesta proviene da un utente autorizzato specifico. Ciò ha anche il vantaggio di consentire agli stessi processi di backend di gestire metodi di accesso alternativi (ad esempio, se hai aggiunto un'API alla tua applicazione per l'utilizzo delle applicazioni mobili). Ciò garantisce anche che le sessioni utente possano essere proseguite con un riavvio del processo lato server - al momento, dai suoni di ciò, gli utenti si ritroverebbero disconnessi se fosse necessario riavviare il processo del server, anche se il riavvio del processo fosse momentaneo. Presumibilmente, i flag su socket specifici non verrebbero impostati in questo caso, senza un nuovo login.

    
risposta data 06.01.2016 - 16:34
fonte

Leggi altre domande sui tag