Un utente può leggere i valori dei membri statici?

0

Per la mia applicazione Android, volevo memorizzare valori come username, userid e cose in un oggetto sharedpreferences. Tuttavia, quando leggo di più su di esso, gli utenti rooted possono ancora avere accesso a quei valori. Quindi mi chiedo, se memorizzo quei valori in variabili statiche in una classe, ad esempio:

class foo{
  public static String username = null;
}

e chiamalo per cambiare in un'altra classe, ad esempio:

class bar{
   foo.username = "user1";
}

Gli utenti potrebbero ancora scoprire il valore di username è user1 in alcun modo?

    
posta AndroidDev 26.09.2018 - 21:44
fonte

1 risposta

4

Qualsiasi modello di sicurezza che cerchi di difendersi da un utente legittimo di un dispositivo è difettoso. Qui, la tua tattica di offuscamento fornirà sicurezza solo se entrambi:

  • l'app non può essere scaricata, decompilata e sottoposta a analisi statiche e
  • l'app non può essere soggetta all'analisi dinamica, ad es. acquisizione di dump dell'heap o immagini di memoria durante l'esecuzione dell'app o acquisizione del traffico di rete.

Se pubblichi la tua app, può essere scaricata e analizzata.

Normalmente l'utente non sarà in grado di acquisire i dump dell'heap (ad esempio tramite adb), ma questa garanzia svanisce fuori dalla finestra nel momento in cui l'app viene eseguita in un emulatore o in una variante non Google Android. Il traffico di rete è particolarmente facile da catturare (a meno che non si utilizzi il blocco dei certificati), poiché gli utenti possono facilmente montare un attacco man-in-the-middle contro il proprio dispositivo.

Quindi in generale non puoi impedire l'analisi statica o dinamica.

Dovrai rielaborare il tuo modello di sicurezza in modo da non memorizzare più segreti sui dispositivi dell'utente a cui non dovrebbero avere accesso. Invece, potresti dover introdurre un server di backend che gestisca i segreti.

Esempio: autenticazione API.

Cattivo design: la tua app contiene un token segreto. L'API di back-end accetta solo richieste con quel token per impedire l'utilizzo non autorizzato.

Il difetto: il token può essere estratto e utilizzato per l'accesso non autorizzato e il server back-end non può distinguere tra richieste autorizzate e non autorizzate.

Design migliore: autentica l'utente, non il dispositivo. È quindi possibile controllare l'accesso per account utente e rifiutare le richieste con credenziali non valide.

Esempio: autenticazione API di terze parti.

Cattivo design: l'app comunica con terzi. Hai un account con quella terza parte. Hai incorporato le tue credenziali nell'app in modo che l'app effettui richieste per tuo conto.

Il difetto: le credenziali possono essere estratte e utilizzate per l'accesso non autorizzato. La terza parte penserà che tu sia responsabile per qualsiasi azione non autorizzata.

Migliore design: consenti alla tua app di comunicare con un server back-end sotto il tuo controllo. Questo server quindi comunica con la terza parte. È in grado di memorizzare tutti i segreti necessari in modo sicuro.

    
risposta data 26.09.2018 - 23:12
fonte

Leggi altre domande sui tag