Questa soluzione è RESTful e sicura?

Naviga le tue risposte
8

Il nostro prodotto registra nuovi giocatori sul nostro servizio e abbiamo scelto di ospitarli su Azure (stiamo usando .NET) e volevamo che fosse stateless (per la scalabilità) e relativamente sicuro.

Poiché questo è il primo REST WS che sto scrivendo, volevo ottenere un riscontro sul fatto che si tratti di una soluzione solida.

Alcune supposizioni sulla nostra app:

  1. Gli utenti sono registrati nel servizio in modo anonimo, senza richiedere una password da un utente
  2. Il WS deve essere completamente senza stato per consentire il ridimensionamento orizzontale
  3. Ci stiamo connettendo tramite HTTPS (SSL) per impedire lo snooping di terze parti

Modifica

  1. Puntiamo ai dispositivi iOS / Android nativi
  2. La nostra preoccupazione principale è fare in modo che solo i client non manomessi possano inviare richieste

E il processo di autenticazione astratto:

  1. Il client crea un semplice hash (UDID: Timestamp) e lo crittografa utilizzando il timestamp con un algoritmo di base (ad esempio, la chiave segreta è ogni 2 ° carattere dell'hash)
  2. Il client invia il suo UDID, Timestamp & hash al server
  3. Il server ricostruisce l'hash e decrittografa l'hash crittografato inviato dall'utente
  4. Se i due sono uguali, sappiamo che è stato effettivamente inviato dal nostro client (e si spera non da un mittente dannoso)

Qualsiasi input / suggerimento sarebbe fantastico - ovviamente visto che è la prima volta che gestisco questo problema, forse l'ho progettato in modo errato.

Grazie!

Secondo aggiornamento:

Leggendo le specifiche di sicurezza per OAuth, sembra che non ci sia una vera risposta alla mia domanda - dal momento che il client e il server devono conoscere le chiavi segrete e il client è memorizzato localmente sui dispositivi mobili dei nostri utenti (al contrario di un web app).

Dalla guida alla sicurezza di OAuth ( link ):

When implementing OAuth, it is critical to understand the limitations of shared secrets, symmetric or asymmetric. The client secret (or private key) is used to verify the identity of the client by the server. In case of a web-based client such as web server, it is relatively easy to keep the client secret (or private key) confidential.

However, when the client is a desktop application, a mobile application, or any other client-side software such as browser applets (Flash, Java, Silverlight) and scripts (JavaScript), the client credentials must be included in each copy of the application. This means the client secret (or private key) must be distributed with the application, which inheritably compromises them.

This does not prevent using OAuth within such application, but it does limit the amount of trust the server can have in such public secrets. Since the secrets cannot be trusted, the server must treat such application as unknown entities and use the client identity only for activities that do not require any level of trust, such as collecting statistics about applications. Some servers may opt to ban such application or offer different protocols or extensions. However, at this point there is no known solution to this limitation.

    
posta Ron 28.04.2013 - 11:58
fonte

2 risposte

3

Questo è un po 'off su una tangente ma, da un punto di vista della sicurezza, qualsiasi segreto che si trova su un client non è un segreto. Nella tua domanda dichiari che

Our main concern is making sure only non-tampered clients are able to send requests.

Come qualcuno che ha lavorato nel settore dei giochi, questa è una causa persa. Se c'è abbastanza valore per poter inviare richieste arbitrarie, gli utenti scopriranno come inviare tali richieste. Non puoi mai fare affidamento sulla possibilità di sapere se una richiesta proviene da un client fidato. Ecco alcuni suggerimenti dalle mie esperienze.

  • Conserva la copia canonica dello stato del gioco sul server
  • Indica le nostre modifiche allo stato che ogni utente può eseguire e controlla i server per violazione.
  • Hai limiti di velocità su quanto gli utenti possono aumentare di livello o guadagnare valuta / elementi per catturare gli script.
  • Se l'imbroglione non può soffrire, gli altri giocatori non li vietano. Anche molti imbroglioni sono spender.
  • Avere controlli sociali sugli imbroglioni, in modo che gli imbroglioni diventino ovvi ai loro amici. Se è possibile avere una logica di corrispondenza rispetto a chi imbroglia verrà rimosso dal giocare contro i propri amici.
risposta data 14.05.2013 - 22:52
fonte
0

La chiave su REST è che stai utilizzando le funzionalità inerenti in http:

  • GET: per il semplice recupero dei dati
  • POST: per l'inserimento di un nuovo punto dati
  • PUT: per l'aggiornamento di un punto dati
  • DELETE: per l'eliminazione di un punto dati

Alcune delle altre indicazioni sono che i tuoi URL dovrebbero essere intuitivi, cioè se il tuo url per i giocatori è http://example.com/api/player allora un modo ragionevole per esporre la loro ultima storia di punteggi potrebbe essere http://example.com/api/player/1/scores (cioè i punteggi per l'id del giocatore 1 ).

Per quanto riguarda la sicurezza, ciò che hai letto dalle specifiche OAuth è molto vero ... se stai incorporando una specie di chiave privata in un binario su cui altre persone possono mettere le mani, non puoi presumere che sia del tutto privato . Vorrei suggerire che se hai qualche tipo di chiave privata nel tuo codice, lo imposti in modo da poterlo scadere, e poi spinga fuori un aggiornamento per cambiarlo. Con tutti i mezzi, cogli l'opportunità di proteggerlo con la crittografia e tutto il resto, ma rendilo facile da disattivare se è violato. La realtà è che Twitter e altri soffrono di questa stessa sfida, dove di tanto in tanto le chiavi segrete per le loro app ufficiali vengono scoperte e pubblicate su Internet e devono aggiornare le loro app.

    
risposta data 07.05.2013 - 01:37
fonte

Leggi altre domande sui tag

Quando le regole aziendali influenzano la presentazione in MVC Lingua compilata per JS - il modo più elegante per fare attese in stile sincrono