Crittografia del corpo di richiesta dell'API HTTP

1

Sto costruendo un'API Web per un gioco semplice. L'API è solo SSL e utilizza token a tempo limitato per l'autenticazione dell'utente. Vorrei crittografare il contenuto di una richiesta specifica per evitare imbrogli.

Capisco che per farlo avrò bisogno di rendere disponibili alcune chiavi di crittografia per l'applicazione client (a cui l'utente ha accesso completo), quindi la soluzione non sarà sicura al 100% contro il reverse engineering.

Tuttavia, sento che qualcosa è meglio di niente e mi chiedo quale sia l'approccio migliore.

Ho trovato un paio di alternative:

  1. Hardcode un segreto condiviso nel codice sorgente dell'applicazione.
  2. Utilizza il token di sessione corrente dell'utente in combinazione con un algoritmo di offuscamento e utilizza il risultato come chiave di crittografia.

Non mi piace particolarmente nessuno di questi, quindi ho voluto verificare se c'è un modo migliore. Qualche idea?

    
posta Shade 02.08.2017 - 18:26
fonte

1 risposta

3

Come hai affermato correttamente, se l'utente ha il controllo sul suo dispositivo, non è possibile smettere di barare. Può monitorare l'ingresso GPS, fare il reverse-engine del codice, identificare la crittografia (se presente) e inviare la richiesta di conseguenza.

L'offuscamento è discutibile, può rallentare (ma non si ferma) l'attaccante. Farai del male alle tue capacità di debug e al design pulito.

Il design corretto è il seguente: invia la richiesta in chiaro per la tua API, ma firmala. La tua API dovrebbe rifiutare tutte le richieste che sono state firmate in modo errato. Basta aggiungere un altro campo parametro alla tua API, che contiene la firma.

Puoi utilizzare la tua PKI o la semplice generazione di hash (se la prestazione è un problema). Ovviamente, l'attaccante può ancora decodificare la firma algo, ma supponiamo che non abbia l'abilità.

Modifica: ti suggerisco di includere il timestamp nell'API per impedire l'attacco di riproduzione. (Ovviamente il timestamp dovrebbe essere firmato digitalmente insieme al resto dei dati). In questo modo i tuoi utenti non possono salvare le stringhe degli URL di posizione e riprodurle manualmente quando sono non in quell'area. Senza data e ora possono farlo indipendentemente dall'uso della crittografia.

    
risposta data 07.08.2017 - 13:31
fonte

Leggi altre domande sui tag