Invio sicuro di pacchetti senza che vengano falsificati

Question

Invio sicuro di pacchetti senza che vengano falsificati

#1 da (6 voti)

2

Sto lavorando a un semplice gioco multiplayer per rompere il ghiaccio con la programmazione di rete. Ho un sistema in cui se il giocatore si muove, il server riceve un pacchetto di mosse che contiene alcune cose come il timestamp che il pacchetto è stato inviato, le chiavi che premono codificate in un byte, l'ID univoco dei giocatori e la loro posizione.

Cosa succede se il giocatore può in qualche modo inviare un pacchetto fingendo che il proprio ID sia X, dove X è un ID giocatore o moderatore casuale? Mi sto avvicinando a questo pacchetto sbagliato, dovrei crittografare i pacchetti? Oppure esiste un metodo comunemente usato nei protocolli della rete di gioco per garantire che i pacchetti siano chi dichiarano di essere?

network spoofing

posta Jon Blow 16.04.2016 - 01:46

fonte

1 risposta

Leggi altre domande sui tag network spoofing

Puoi mai essere sicuro al 100% di aver decifrato un messaggio? Bypassing login con SQL Injection

score 6 · Accepted Answer

Hai sentito parlare di sessioni JWT o stateless?

Sembra un lavoro per un pacchetto crittografato che viene inviato al client e inviato indietro, per il successivo pacchetto da inviare. Questo token Web JSON può essere utilizzato per indicare chi parla al server, contenendo le informazioni necessarie in un formato crittografato per assicurarsi che le cose siano sicure e conformi. È meglio farlo su una connessione criptata.

Un esempio

Andy e Deli stanno giocando. Andy ottiene un JWT con le sue informazioni e Deli ottiene un JWT con le sue informazioni.

Alcune delle informazioni nel JWT sono le stesse (id del gioco, metadati del gioco, ecc.) e alcune di esse sono uniche (id giocatore unico, giocatore ip, qualcos'altro unico per il giocatore).

Quando Andy comunica, JWT viene inviato insieme ai suoi pacchetti e verifica le sue informazioni univoche. Una volta verificato, la sua mossa viene quindi eseguita e inoltrata. Ottiene quindi alcune informazioni uniche ALTERATE (come l'aggiornamento dell'ora dell'ultima mossa da parte di questo giocatore) e gli viene rispedito, e la mossa viene inviata a tutti gli altri.

Ora Deli vuole imbrogliare. Invece mette l'id di Andy's Unique nella sua mossa e lo invia per far sembrare che Andy abbia fatto una nuova mossa in un brutto posto.

Il JWT è decodificato, e si vede che Deli sta barando, quindi Deli viene calciato, e Andy vince di default poiché Deli ha inviato un comando per un utente che non è Deli.

Una rosa con qualsiasi altro nome

Spesso vedrai queste anche chiamate Sessioni Cookie, Sessioni Stateless, Token Web JSON e una miriade di altri nomi, ma hanno tutti la stessa idea (e quando vengono inviati su TCP, di solito sono nei cookie)

Che cos'è una sessione senza stato?

Una sessione senza stato è una sessione che vive e muore con il suo token.
Di solito sono crittografati sul server con un server segreto che è collegato a qualsiasi cosa stia accadendo. Questi token non vivono nei database, non riflettono alcun tipo di archiviazione a lungo termine e scadono alla fine.

Per tenerli al sicuro, di solito vengono crittografati con una potente suite di crittografia e un segreto di qualche tipo che viene decodificato al volo, modificato e quindi crittografato. Questa informazione è solitamente un documento JSON contenente meta informazioni che non vengono modificate spesso (se non del tutto) che possono essere inviate avanti e indietro e poiché è crittografato significa che qualsiasi modifica lo rende nullo e vuoto .

Qualsiasi modifica a questi li rende come nuove sessioni e tutti i dati in essi contenuti vengono persi. Ciò significa che se esegui correttamente i controlli e i saldi, puoi persino utilizzarlo come sessione completa per un utente sulla maggior parte dei siti web.