Newsgroup: it.comp.lang.javascript
Titolo: Trasmissione dati verso il server non alterabile

Ciao a tutti,
devo sviluppare una serie di applicazioni (diciamo dei giochi) in js dove 
il client comunica al server il punteggio conseguito. 
Vorrei che tali programmi fossero il meno possibile "crackabili", so che 
in teoria la cosa è impossibile visto che il codice che invia i punteggi 
sta sul client ed è modificabile con un semplice firebug, pero' almeno 
voglio rendere l'operazione il più complicata possibile, ecco.
Esiste qualcosa del genere ,oltre all'offuscazione del codice, in 
letteratura?
 
 
Grazie
 


La risposta breve e' no, non c'e' verso, puo ioffuscare o creare le cose piu' astruse ma prima o poi verranno craccate.
Daltrocanto e' anche vero che bisogna vedere quanto sia interessante craccare il punteggio per l'utente, ci sono premi in palio? Per la gloria?
Se ci sono premi o cose del genere non c'e' verso... se e' per la gloria, magari rendendo le cose complesse puoi scoraggiare i piu'. 
 
Ci sono pero' sistemi per lenire il problema, ad esempio sul server ti salvi quando inizia la partita, quando finisce eccetera, poi controlli che il puntaggio abbia senso, per dire se in un secondo qualcuno spedisce il punteggio di mille mila milioni qualcosa e' andato storto.
Oppure l'alra soluzione e' comunicare continuamente con il server, se qualcosa non funziona vai out-of-sync o qualcosa del genere, tanto il server sa sempre a che punto il gioco e' (ogni partita e' casuale perche' la fai partire con un seed diverso, ma conoscendo il seed sai tutto quello che avverra')
 
 
Ma come al solito bisogna vedere se il gioco vale la candela, sia per il cracker (al 90% la risposta e' si.. vale la candela craccare tutto) che per lo sviluppatore.
 
J.
 


nodejs con qualche versione di libreria per gestire i socket
Io l'ho fatto con nowjs perché il progetto era già stato impiantato e mi 
sono dovuto adeguare
Lato server fai comunque qualche check sulla connessione per vedere che 
il client sia davvero chi dice di essere e poi sei a bolla
Se poi il "punteggio" è un dato sensibile apri il socket in wss
 
-- 
I fatti mi cosano


Io farei eseguire il calcolo del punteggio al server, non al client. Al
server invii le azioni effettuate nel gioco, e il server calcola quindi
conseguentemente il punteggio, che può anche reinviare al client – o al
piú il client può comunque calcolarselo per visualizzarlo, ma alla fin
fine il punteggio finale sarà quello tenuto dal server.
 
Ovviamente dipende molto dalla tipologia di gioco, ma come semplice
regola generale userei questa.

 La risposta breve e' no, non c'e' verso, puo ioffuscare o creare le cose piu' astruse ma prima o poi verranno craccate.
 
Assolutamente d'accordo. Se è concorso (o comunque una cosa con un 
termine temporale) è bene che la durata sia ragionevolmente breve, 
altrimenti meglio predisporre più meccanismi di comunicazione / 
sicurezza da cambiare periodicamente e di frequente. Ma anche così se 
dall'altra parte trovi uno che ha deciso di scardinarlo lo scardinerà.
 
Io mi sono cimentato una sola volta con questo problema e nello 
specifico la richiesta era che il protocollo potesse sopravvivere per 
diversi mesi. Alla mia obiezione che stavamo perdendo tempo il 
committente fece spallucce. Contento lui. Quello che concepii 
compatibilmente col budget funzionava così:
 
- L'intero gioco era scritto in flash e questo ha aiutato non poco. Era 
composto da due parti: il sottostrato di comunicazione col server e i 
file dei giochi veri e propri.
 
- La comunicazione avveniva tramite xmlsocket, un protocollo presente 
presente nativamente in flash che invia e riceve stringhe di xml su un 
socket nudo e crudo, niente http. Il socket si apriva all'inizio della 
partita e rimaneva su fino al termine. Il protocollo xmlsocket è 
talmente stupido da implementare che il server era stato scritto in casa 
con poche manciate di righe di C#. Per contro questa cosa ha tagliato 
fuori chiunque passa da un proxy, caso tipico 
p.es
. di una rete 
aziendale. Il committente di nuovo ha fatto spallucce.
 
- Gli xml scambiati per segnalare i punteggi ed inviare comandi push ai 
giochi cambiavano in modo casuale ad ogni partita secondo una decina di 
schemi e con i nomi dei nodi e degli attributi formati da sequenze di 
caratteri casuali diversi per ogni istanza. C'era un batch che partendo 
dai sorgenti flash precompilava un certo quantitativo di swf combinando 
la versione specifica della parte di comunicazione col gioco vero e 
proprio, scrivendo in un db le corrispondenze tra il file, schema xml e 
nomi dei nodi xlm da questo usato.
 
- La pagina che serviva il gioco prelevava la prima istanza non usata di 
swf, l'abbinava alla sessione e segnava l'inizio della partita. A 
servire gli swf c'era un handler che usava una one-time-password 
generata dalla pagina con validità di pochi secondi per impedire che 
qualcuno potesse tenare di scaricarsi le istanze non ancora usate. Le 
quali comunque avevano un nome casuale di 100 caratteri...
 
- Dato che in tutti i giochi una partita aveva una durata massima 
predeterminata il server non accettava ulteriori comandi da un'istanza 
oltre un certo periodo dopo l'inizio della partita.
 
Io l'ho crackato impiegandoci un pomeriggio, ben sapendo come 
funzionava. La mia valutazione fu che qualcuno che non conosceva il 
meccanismo avrebbe impiegato qualche giorno di lavoro per arrivare al 
risultato, presumibilmente troppo rispetto al valore ridicolo della roba 
in palio (e al fatto che a termine concorso il premio sarebbe stato un 
robo fuori produzione da mesi...).
 
E - per inciso - per quello che mi riguarda uno che avesse avuto tempo e 
voglia di decompilare i flash e/o guardare con wireshark cosa si 
dicevano client e server per poi tirare in piedi un sistema in grado di 
simulare di autenticarsi sul sito, avviare una partita, scaricare 
un'istanza valida di swf, estrarne i dati specifici ed usarli per 
inviare la sequenza di comandi che simula una partita ed infine 
automatizzare questo processo si meritava abbondantemente di portarsi a 
casa il premio a sbafo.
 
Ah! dimenticavo... dopo lo sbattimento necessario ad implementare tutto 
il giro del fumo descritto i giochi che ci giravano sopra erano talmente 
mediocri nella loro meccanica che per falsare i punteggi è bastato un 
gruppetto di pensionati con un po' di iniziativa e un programmino che 
registrasse e replicasse i movimenti del mouse. Dai log risultò che non 
erano riusciti ad automatizzare l'avvio di una nuova partita, ma quando 
uno c'ha da tirar sera evidentemente non è un problema. Quindi occhio 
che il protocollo di comunicazione non è tutto...
 
-- 
r--r--r--


Documentandomi un po' in rete questa sembra (logicamente) la soluzione 
corretta, il problema è che ne potrebbe risentire  la velocità del gioco, 
quindi dovrò strutturarlo in modo da fare queste comunicazioni con 
chiamate ajax non bloccanti, ma credo sia  fattibile.
Vero è che il server in questo caso deve conoscere, o addirittura creare 
lui stesso e comunicarle al client, le condizioni iniziali.
Supponendo un tetris, ad esempio, deve sapere tutta la sequenza dei pezzi 
che escono, e deve esserci una infrastruttura che se siamo quasi alla 
fine dei pezzi comunicati, comunicarne altri.
 
Grazie
 

 bolla Se poi il "punteggio" è un dato sensibile apri il socket in wss
 
 
Scusa non credo di aver capito, mi sembra che questa soluzione sia per 
avitare eventuali bot costruiti ad hoc, ma una chiamata ajax fatta 
inserendo codice nello script originale con un tool tipo firebug come me 
la previene? (visto che il client risulterebbe essere quello giusto)


La tua domanda era diversa e verteva sulla trasmissione
Aprendo un socket che io sappia il tampering non può avvenire durante la 
trasmissione, ma non ne sono sicuro
 
Usare nodejs ti da il vantaggio che ci puoi mantenere lo stato dei 
client connessi, quindi sul client non fai aggiungimiPunti(3), ma fai 
solo getMioPunteggioAttuale()
Il punteggio del singolo client te lo calcoli in autonomia lato server
Ovviamente nemmeno così sei sicuro al 100%, ma sei un passo più avanti
Molto dipende dalla struttura del giochino


 La tua domanda era diversa e verteva sulla trasmissione 
 
Scusa in effetti rileggendomi mi rendo conto di aver scritto una cosa 
facilmente male interpretabile.
 
Grazie per la risposta
 


Figurati
Quel lavoro (che dovrò probabilmente reiterare per espanderlo) mi ha 
intrippato non poco e al netto delle molte bestemmie dovute a nodejs e 
librerie immature è stato uno dei più gratificanti finora
