Inviare dati su server in modo sicuro

[cp94]

Siccome non sono troppo esperto di come funzioni una comunicazione tra una propria applicazione ed un server volevo porre una domanda.
Io voglio inviare una string (criptata) di dati su un mio server altervista tramite php, però come faccio a far si che questi dati possano essere inviati solo tramite l'applicazione e non manualmente da un cheater?
Qual'è il metodo migliore per evitare problemi di questo tipo (cheating online, ecc..) ?

[Tizzio]

Siccome non sono troppo esperto di come funzioni una comunicazione tra una propria applicazione ed un server volevo porre una domanda.
Io voglio inviare una string (criptata) di dati su un mio server altervista tramite php, però come faccio a far si che questi dati possano essere inviati solo tramite l'applicazione e non manualmente da un cheater?
Qual'è il metodo migliore per evitare problemi di questo tipo (cheating online, ecc..) ?

Un metodo semplice
Per sapere se stai inviando i dati dall'app, devi mandare al server una stringa identificativa (salvata nel codice dell'app come stringa costante) quando fai la chiamata alla pagina
All'autenticazione mandi un'altra stringa dal tuo server php e utilizzi quel dato a ogni successiva comunicazione col server.

Questo limita il 99% dei wanna be hacker, ma se uni più esperto sniffa i pacchetti in uscita trova subito l'id per comunicare col server.
Ci sono sicuramente altri metodi, ma ti consiglio di affidarti a robe di terze parti (google +, facebook) etc per essere sicuro che si sta inviando da un dispositivo mobile

Sicuramente ci sono metodi più complessi e sicuri, ma non sono ancora in grado di spiegarteli:
http://www.html.it/pag/16477/la-crittog ... ica-e-rsa/

[Nix]

Il metodo di tizzio si può migliorare usando gli hash in molti modi diversi. L'idea di base è che invece di inviare direttamente l'ID segreto, invii un hash che deriva dall'ID e da qualche altro dato variabile. In questo modo il server può controllare la validità della connessione in generale o dei pacchetti calcolando l'hash allo stesso modo, e un cheater che sniffa i pacchetti non se ne fa nulla dell'hash visto che poteva essere usato solo in quel caso. Si può per esempio fare che il server invia ogni volta (per esempio insieme ai suoi pacchetti) un codice e il client deve saper rispondere con l'hash formato dal codice del server e dall'ID segreto che condividono il tuo eseguibile e il server. Oppure semplicemente il client hasha l'ID e i dati del pacchetto, ma così è possibile inviare pacchetti uguali a quelli inviati in passato dal tuo eseguibile con un'altra applicazione (si potrebbe risolvere con un timestamp, comunque).

[cp94]

Se ho capito bene, più semplicemente:
1. il server genera una string_id a inizio sessione di gioco
2. la string viene inviata all'app
3. quando l'app deve mandare i dati al server mando string_id+dati
4. controllo sul server se string_id ricevuta == string_id, in tal caso salvo i dati

Corretto?

@Nix: Grazie della risposta, ma non ho ben capito la storia degli hash e di come potrebbero migliorare la situazione.
Hai detto che il server deve inviare un codice (insieme ai pacchetti), e il client deve rispondere con l'hash di codice+id_segreto, ma a cosa mi serve l'hash?
Non so niente dell'argomento, quindi perdonatemi

[Solid Snake]

http://gmitalia.altervista.org/gmi_foru ... 09#p196209

[Nix]

Se ho capito bene, più semplicemente:
1. il server genera una string_id a inizio sessione di gioco
2. la string viene inviata all'app
3. quando l'app deve mandare i dati al server mando string_id+dati
4. controllo sul server se string_id ricevuta == string_id, in tal caso salvo i dati

Corretto?

No, la stringa dovrebbe essere sempre la stessa e andrebbe salvata nel codice.

@Nix: Grazie della risposta, ma non ho ben capito la storia degli hash e di come potrebbero migliorare la situazione.

L'hash serve perché in realtà quella tecnica non ha molto senso in questo caso. Se ti preoccupa che uno può mandare i dati fuori dalla tua applicazione, bisogna considerare che per farlo è necessario sapere in che formato mandare questi dati (il protocollo), quindi uno dovrebbe comunque sniffare i pacchetti, scoprendo la stringa. Le funzioni hash trasformano dei dati di qualunque dimensione in una stringa di dati di lunghezza costante, e rendono molto difficile risalire ai dati iniziali a partire da quelli finali. Quindi, se tu hashi (correttamente) la stringa segreta insieme ad altri dati, non è possibile risalire alla stringa a partire dall'hash. La stringa segreta rimane dentro al codice, però nei pacchetti non c'è da nessuna parte, quindi sniffando non si può scoprire.

Hai detto che il server deve inviare un codice (insieme ai pacchetti), e il client deve rispondere con l'hash di codice+id_segreto, ma a cosa mi serve l'hash?

Serve a confermare che quel pacchetto l'ha generato la tua applicazione. Infatti uno che sniffa i pacchetti non può scoprire l'id segreto, che lo sanno la tua applicazione e il server, quindi non può generare quell'hash (ovviamente questo protegge semplicemente dallo sniffing, si può comunque fare del reverse engineering sull'eseguibile). Te l'ho spiegato in modo molto generale, come ho detto l'hash si può usare in diversi modi, se guardi il post di Xeryan c'è una tecninca precisa.

[cp94]

Ok, quindi ciò che devo inviare è una sorta di:
string = hash_app(dati)+dati
dove per fare l'hash uso il codice segreto salvato nell' app?
Dal server controllo che il hash_app(dati) appena ricevuto sia uguale ad hash_server(dati)

Do un occhiata all'altro post e vedo cosa riesco a fare.
Grazie mille!

[Nix]

Ok, quindi ciò che devo inviare è una sorta di:
string = hash_app(dati)+dati
dove per fare l'hash uso il codice segreto salvato nell' app?
Dal server controllo che il hash_app(dati) appena ricevuto sia uguale ad hash_server(dati)

Do un occhiata all'altro post e vedo cosa riesco a fare.
Grazie mille!

hash_app e hash_server devono essere identici. Non usare cose come hash(chiave + dati), perché sono vulnerabili. Meglio hash(dati + chiave), o se proprio vuoi essere sicuro usa HMAC. Inoltre considera in questo modo è possibile creare pacchetti validi, se sono già stati inviati in passato e sniffati. Infatti per lo stesso pacchetto l'hash è lo stesso. Come ho scritto sopra, puoi risolvere questo problema con un timestamp, in modo da rendere i pacchetti con lo stesso significato diversi.

[Jak]

La verità è che finchè i controlli vengono gestiti in locale la sicurezza non esiste, infatti i giochi escono hackerati prima ancora dell'uscita effettiva.
Per lo stesso principio non puoi assicurarti che dati derivano dall'applicazione anzichè essere inviati a manina, puoi solo rendere difficili le cose ed a meno che uno non si vada a spulciare il codice (ne vale la pena per un'hacker nel tuo caso?) la soluzione più conveniente è prendere un paio di buone funzioni per criptare e dargli una password di default, giusto per farli faticare quanto basta per far si che perdano la voglia di provarci.
Le uniche cose sulle quali conviene perderci tempo sono eventuali sniffamenti tra client e server e quindi dare sicurezza ai dati dell'utente piuttosto che all'applicazione in se ed in quel caso ci sono soluzioni diverse che però non offrono nessuna protezione extra nel tuo caso, ossia evitare che barino sui punteggi e cose di questo tipo giusto?

[Tizzio]

la soluzione di nix/xeryan è migliore

edit: non va bene, per il motivo detto da nix

Bisogna mandare il current_time insieme all'hash e il server farà il calcolo usando quel timestamp

[cp94]

evitare che barino sui punteggi e cose di questo tipo giusto?

Se fosse solo questo non mi preoccuperei più di tanto, qua si tratterà di proteggere dati come i Gold ingame, che potranno essere acquistati con soldi veri.

Edit: Ma è sicuro poi salvare i dati su un database altervista?

[Nix]

Codice: Seleziona tutto

string result = hash(current_time + funzione_matematica_a_tua_scelta(current_time) + stringa costante)
Send(result)

Nel server

Codice: Seleziona tutto

string expected = hash(current_time + funzione_matematica_a_tua_scelta(current_time) + stringa costante)

if( expected != received)
    BanHaxx0r();

Così non saranno mai uguali, visto che i pacchetti vengono inviati e arrivano in momenti diversi.

Se fosse solo questo non mi preoccuperei più di tanto, qua si tratterà di proteggere dati come i Gold ingame, che potranno essere acquistati con soldi veri.

Questo è un problema del protocollo, non della sicurezza della connessione.

Edit: Ma è sicuro poi salvare i dati su un database altervista?

Se non lasci vulnerabilità, sì.

[Jak]

Se fosse solo questo non mi preoccuperei più di tanto, qua si tratterà di proteggere dati come i Gold ingame, che potranno essere acquistati con soldi veri.

Se non è multiplayer e tutta la roba finisce in locale ti inculeranno i gold prima che tu faccia il gioco.
Se è multiplayer dipende da molte cose ma uno non bananarappato potrebbe riconoscere facilmente se l'altro è un'hacker o no ed in caso non collegarsi proprio a lui. Classicissimo dei giochi multiplayer nonchè spiegato perchè generamente non si può giocare online con le bananarap.
Su minecraft non giochi perchè è chi mette su il server MC a controllare e non quelli mohjang direttamente. Un server chiede al tuo db se il tizzio è in regola oppure no ed agisce di conseguenza limitando così i danni a server bananarappato + bananarap e smagheggi vari che nel 99.99% dei casi non conviene.
Ogni cosa ha soluzioni più o meno sicure, dacci più dettagli sulla natura del gioco a sto punto.

[cp94]

Se fosse solo questo non mi preoccuperei più di tanto, qua si tratterà di proteggere dati come i Gold ingame, che potranno essere acquistati con soldi veri.

Se non è multiplayer e tutta la roba finisce in locale ti inculeranno i gold prima che tu faccia il gioco.
Se è multiplayer dipende da molte cose ma uno non bananarappato potrebbe riconoscere facilmente se l'altro è un'hacker o no ed in caso non collegarsi proprio a lui. Classicissimo dei giochi multiplayer nonchè spiegato perchè generamente non si può giocare online con le bananarap.
Su minecraft non giochi perchè è chi mette su il server MC a controllare e non quelli mohjang direttamente. Un server chiede al tuo db se il tizzio è in regola oppure no ed agisce di conseguenza limitando così i danni a server bananarappato + bananarap e smagheggi vari che nel 99.99% dei casi non conviene.
Ogni cosa ha soluzioni più o meno sicure, dacci più dettagli sulla natura del gioco a sto punto.

Si il gioco è Multiplayer, ma non in tempo reale. E' un multiplayer come può esserlo il Multi dei giochi di Facebook (tipo Farmville per intenderci).
Un player può entrare nel mondo di un altro player e interagire con esso. Il problema è che se uno cheata i Gold, inutile dire che può fare quello che vuole.
Gold e salvataggi vari saranno contenuti tutti nella stessa string che, con codice e un hash, invierò al database.

[cp94]

L'algoritmo AES che uso per criptare non funziona su android...
A questo punto mi chiedevo se era proprio necessario. E' vero che senza di esso i dati risultano visibili, ma è anche vero che senza la key che genera l'hash non possono essere inviati e salvati sul server.
Dite che è comunque vulnerabile lasciarli scoperti?

[Nix]

L'algoritmo AES che uso per criptare non funziona su android...
A questo punto mi chiedevo se era proprio necessario. E' vero che senza di esso i dati risultano visibili, ma è anche vero che senza la key che genera l'hash non possono essere inviati e salvati sul server.
Dite che è comunque vulnerabile lasciarli scoperti?

Se il problema è sempre quello, qui l'AES non è necessario. Anche se il token è visibile non puoi farci proprio nulla, perché è legato a quel particolare pacchetto in quel contesto.