Abbiamo un servizio Web che registra / registra i dati utente inviati tramite https dalla nostra applicazione client. C'è un modo per garantire in modo sicuro che i dati vengano inviati dall'applicazione client e non da uno strumento falso che impersona la nostra app? Idealmente, non mi piacerebbe dover ricorrere a cose come nascondere una chiave offuscata nel client o altre tecniche di "sicurezza attraverso la segretezza ..."
Non puoi. Un server fondamentalmente non può fidarsi di un client (ci sono alcune eccezioni - se la macchina client è indurita (l'hardware verifica il firmware, il firmware verifica il SO, il sistema operativo verifica ogni applicazione in esecuzione), potrebbe essere possibile farlo (ma non proprio - qualcuno con un saldatore potrebbe sempre modificare la verifica dell'hardware), ma se non controlli il 100% il cliente, sei piuttosto sfortunato.
Devi chiederti: quali sono i rischi del caricamento dei dati fasulli da parte del client? Quali sono le conseguenze della mancata autenticazione di quella che è la tua applicazione che carica i dati? Una domanda difficile da porsi: il cliente ha un incentivo a caricare dati fasulli? Se l'utente non ha un incentivo a caricare dati falsi, probabilmente non si preoccuperanno.
Una cosa che puoi fare: puoi autenticare l'utente che esegue l'applicazione (tramite uno qualsiasi dei numerosi meccanismi di autenticazione) e quindi salvare i dati caricati insieme all'ID utente autenticato (e Indirizzo IP). In questo modo se l'utente fa carica dati falsi, puoi rintracciare chi ha apportato la modifica. Ovviamente ora hai reso le informazioni personali che potrebbero avere problemi di privacy per il tuo servizio.
Devi autenticare il client e questo richiede che ci sia una sorta di segreto. Se un utente umano sta controllando il cliente, potresti semplicemente essere in grado di registrare e autenticare l'utente, usando un segreto che conoscono o di cui hanno accesso.
Se il client è automatizzato e non si controlla l'ambiente hardware e software su cui si basa il client, si è sfortunati di fronte a un determinato utente malintenzionato che ha il controllo del client. Ma puoi renderlo difficile.
Il tuo problema sembra correlato al problema generale delle licenze delle applicazioni client e una buona panoramica di un approccio a questo (per le app Android, in Java) è qui:
Puoi adattarlo al tuo ambiente o cercare altre librerie open source adatte alla tua situazione.
A proposito, "sicurezza via segretezza" va bene: i segreti come le chiavi private fanno parte della maggior parte dei buoni schemi. È "la sicurezza attraverso l'oscurità" che le persone cercano di evitare, cioè semplicemente complicando le cose, o facendo finta che gli aggressori non comprendano i tuoi algoritmi.
Se leggi le 10 leggi di sicurezza immutabili , la legge n. 3 spiega il problema a un livello fondamentale:
Legge n. 3: se un ragazzo cattivo ha accesso fisico illimitato al tuo computer, non è più il tuo computer
Potresti usare kerberos per eseguire l'autenticazione reciproca tra client e server. Preferibilmente avresti qualche metodo fuori banda per identificare inizialmente il cliente, ad es. rilasciare all'utente un identificatore. ovviamente, ora fai affidamento su quell'identificatore che non viene compromesso ...
Come hanno detto gli altri ragazzi, non ci si può fidare di un cliente, finché il client non si autentica con un certificato creato da te. In questo momento l'intero problema si riduce a un problema di distribuzione di chiave / cert:
Fino a quando queste domande avranno una risposta (correttamente!) tutti gli altri eventi che seguono l'autenticazione sono moot.
Leggi altre domande sui tag authentication client-side appsec