Non è chiaro quale tipo di requisiti di sicurezza hai in primo luogo e quindi non è chiaro se le tue misure di sicurezza siano sufficienti o meno.

Non è possibile proteggersi completamente da un utente malintenzionato che utilizza la tua applicazione fintanto che non sei in grado di controllare completamente il dispositivo dell'utente. Questo rischio include l'esecuzione dell'applicazione su emulatori, ma include anche l'esecuzione su un dispositivo rooted o altrimenti manomesso, e non tutto questo verrà rilevato da qualsiasi metodo di rilevamento root utilizzato.

Invece è necessario progettare la tua applicazione in modo che un utente malintenzionato non possa arrecare danno a te o ad altri utenti ma solo a se stesso. Questo, ad esempio, significa avere segreti specifici dell'utente nell'applicazione e non usare segreti globali. Ciò significa anche che non dovresti fidarti di nulla dei rapporti dell'applicazione, ma invece verificare se ha senso (cioè non fidarti di alcun punteggio alto auto-segnalato nei giochi o simili).

Di quale sicurezza ti preoccupi qui e cosa stai cercando di proteggere? Stai cercando di proteggere gli utenti dal fatto che altre persone accedano ai loro dati o stai cercando di proteggere l'azienda da tecnici inversi che tentano di vedere come funziona l'app perché la tua API non è sicura?

Se lo sei puramente tentando di proteggere la sicurezza degli utenti, quindi non c'è alcun problema con l'app in esecuzione in una VM a meno che non si pensi che gli utenti eseguiranno l'app in una VM scarsamente protetta e avranno i loro dati rubati, il che è molto improbabile ed problema loro, non tuo.

Se stai tentando di impedire alle persone di eseguire il reverse engineering dell'app, stai combattendo una battaglia difficile perché i root checker sono facilmente aggirati. Anche questo è quasi sempre uno sforzo inutile poiché l'app non dovrebbe avere nulla di utile per un utente malintenzionato se è stata progettata in modo sicuro.

Inoltre, tieni presente che a volte le persone che eseguono test di sicurezza a volte risolvono solo non problemi se non riescono a trovare problemi reali poiché un rapporto vuoto rende difficile giustificare i soldi spesi. Se possibile, sfidali su questa affermazione e chiedi loro di fornire un esempio reale di come questo sia effettivamente un problema.

La risposta classica e corretta al tuo cliente è NOTANISSUE”.

Nessun software lato client * * dovrebbe mai essere considerato sicuro , nel senso che pone la tua domanda. Non possono essere. Il software lato client - sia esso web o app - è totalmente sotto il controllo del cliente, così come il suo ambiente, così come la totale capacità di riscrivere / modificare il software, o eseguirlo su un ambiente non sicuro o modificato in modo non rilevabile. Non è un bug. Questo è inerente al modello * *.

Lo scopo dei tuoi vari controlli è ridurre i rischi e alzare il livello, come spesso accade con la sicurezza. Non è fatto per rendere il client sicuro o per garantire la sicurezza lato client e il tuo client non è corretto nel presumere tale scopo.

• * * Con forse la sola esclusione del software lato client in cui l'intero software lato client e il suo ambiente sono progettati e controllati con lo scopo di creare un ambiente altamente resistente alle manomissioni e verificabile , come Trusted Execution, o il firmware di alcune YubiKeys (che non può essere scaricato o modificato facilmente una volta eseguito il flashing), o quando il client è un sistema remoto con la propria sicurezza in atto, come server di failover ben protetti sincronizzandosi tra loro tramite SSH.
  
  Anche allora, forse il modulo specifico può essere considerato sicuro (per un certo modello di minaccia) ma ciò non significa che nient'altro, come il controllo di un'app locale la risposta del dongle è in alcun modo protetta.

Sto leggendo tra le righe qui, ma credo di vedere da dove proviene il ricercatore.

La tua app non ha alcun compito di memorizzare (o utilizzare) segreti che potrebbero esporre i dati di altri clienti.

progetta il tuo backend in modo che i segreti dati al frontend diano solo accesso a compartimenti stagni ai servizi di backend. quindi, se un utente esegue il root del proprio dispositivo, può violare solo il proprio account.

Sento il bisogno di difendere il povero tester di penna diffamato qui.

Che cosa è stato assunto per fare questo tester e con quale scopo?

Se lo sviluppatore dell'app ha fornito un white paper o strategia di sicurezza ecc. che afferma che il rilevamento dei root è parte della loro strategia di sicurezza, quindi è assolutamente appropriato sottolineare che il rilevamento dei root è una finzione per gli apk disponibili pubblicamente. In genere, non è un problema del tester capire se l'architettura complessiva è effettivamente vulnerabile dal lato client e dovrebbe essere eseguita solo su dispositivi controllati, oppure la direzione voleva solo l'elenco più ampio possibile di "funzionalità di sicurezza". Lui o lei segnala semplicemente che non è riuscito contro le affermazioni fornite (che il rilevamento di root sta migliorando la sicurezza.)

La "correzione" è smettere di affermare che i controlli dell'ambiente lato client fanno qualsiasi cosa per la sicurezza in modo che tu possa avere un un elenco più ampio di "funzionalità di sicurezza".

La formulazione che implica che questa persona abbia detto "essere sul playstore è una vulnerabilità" non è loro. (avendo avuto cose che ho detto riaffermate in modo errato in un modo che lo rende abbastanza sbagliato volte nella mia carriera ...!)

Non considererei nessuna delle applicazioni lato client o web come stand-alone sufficientemente sicura, ovvero senza proteggere la soluzione lato server in modo indipendente sul sistema operativo.

Tutti i livelli di sicurezza, le convalide e i controlli implementati all'interno dell'applicazione lato client devono essere almeno ripetuti con convalide corrispondenti o più efficaci all'interno dei componenti lato server dell'applicazione.

Inoltre, l'utilizzo dell'emulatore per eseguire l'applicazione significa che le vulnerabilità dell'emulatore possono danneggiare la sicurezza dell'utente, ad esempio alcune vulnerabilità hanno consentito agli aggressori di eseguire l'esecuzione di codice in modalità remota, la divulgazione di informazioni, il furto di backup e dati, nonché l'accesso alle funzioni di comunicazione tra processi dell'emulatore * .

* Fonte: https://www.bleepingcomputer.com/news/security/bluestacks-flaw-lets-attackers-remotely-control-android-emulator/

C'è poca differenza tra una JVM in esecuzione su un dispositivo hardware o un emulatore. Ovviamente si potrebbe vedere se la stringa di build del sistema operativo ha "generico" (che solo l'emulatore ha) e quindi uscire dall'applicazione, quando si tratta di una build di rilascio - ma questo fornisce zero miglioramenti della sicurezza complessiva (poiché il bytecode può essere facilmente decompilato - e solo la firma del codice impedisce in una certa misura modifiche alla funzionalità). Inoltre, le build di rilascio non sono configurate come debuggable.

Il punto è che quando non può essere eseguito su un dispositivo rooted, non verrà eseguito su un emulatore (rooted).

Il rilevamento affidabile della radice è impossibile, a causa di evidenti buchi di test della penna logica.

Se l'utente ha accesso all'apk, l'utente può anche solo analizzare l'apk e quindi chiamare direttamente l'API del server abbastanza facilmente e bypassare completamente l'applicazione o trasferirla su un sistema diverso. Devi ripensare il tuo approccio generale alla sicurezza se fa parte della strategia per proteggere i tuoi sistemi per rilevare se viene eseguito su un dispositivo rooted, poiché non puoi nemmeno sapere in modo affidabile cosa viene eseguito.

L'utente può, se vuole, decompilare la tua applicazione e rimuovere tutte le parti di rilevamento dall'applicazione in primo luogo. Il processo sarebbe lo stesso del software di "cracking".

Quello che puoi fare con il rilevamento dei root è semplicemente far sapere a un utente che pensi che il suo telefono sia rootato, come avvertenza di sicurezza per utente - forse il telefono è rootato senza che l'utente lo sappia? ma anche in questo caso non ci si può fidare. non puoi sapere se si tratta di hardware effettivo o meno su cui stai eseguendo. Non puoi sapere se è in esecuzione su un sistema come knox dove puoi pagare Samsung per ottenere essenzialmente poteri di root nel sistema (attraverso la funzionalità aziendale - e sì, fondamentalmente può garantirti poteri quasi come root per fare confusione con altre applicazioni e altri componenti dell'applicazione - il telefono apparirà come knox secure anche allora e senza root).

Il rilevamento dei root e simili di solito finiscono in un'applicazione per scoraggiare l'hacking, ma è l'approccio sbagliato al 100% per combattere il problema. Mi dispiace, ma ciò di cui hai bisogno è un cambiamento del pensiero culturale nell'organizzazione per quanto riguarda la sicurezza: non puoi fidarti che il software che gira altrove sia ciò che pensi sia così pentito perché è inutile.

modifica: se hai bisogno di un modo per spiegarlo ai tuoi superiori, potresti provare questo: "Se potessimo farlo, quel pezzo di codice varrebbe più di quanto valga l'intera azienda" - e quella citazione sarebbe comunque valida per la tua azienda anche se lavorassi per Google.

L'avviso del ricercatore di sicurezza è corretto, ma devi inserire questo avviso nel contesto della tua applicazione per sapere se è rilevante.

Hai elencato il "rilevamento root" come un'importante funzione di sicurezza del tuo app.

Essendo io stesso un esperto di sicurezza, vorrei sottolineare che il rilevamento dei root può essere facilmente aggirato. Non solo su macchine virtuali: ma anche su dispositivi fisici. Molti framework che affermano di eseguire il rilevamento dei root non rilevano molti dispositivi rootati e ne rilevano alcuni normali come root. Anche se fosse così, il lato client di qualsiasi applicazione può essere facilmente decodificato. Un aggressore motivato sarà in grado di accedere alla tua interfaccia back-end bypassando del tutto l'app lato client. Ciò significa che qualsiasi controllo sul lato client può essere aggirato e qualsiasi calcolo può essere modificato. Nessun controllo o calcolo lato client può essere considerato attendibile.

È possibile creare un client affidabile, ma richiede hardware proprietario, sistema operativo proprietario e software. Le console di gioco e le reti via cavo lo fanno, ma soffre ancora molto della pirateria che dovrebbe contare come un buon esempio di quanto sia difficile a prova di manomissione un dispositivo. Questa strategia è teoricamente possibile, ma fallisce nella pratica perché è troppo costosa, ruba e impedisce investimenti sulla funzionalità del prodotto che diventa debole e obsoleto di fronte alla sua concorrenza.

Quanto deve essere sicura?

Non esiste un'app sicura / protetta. La sicurezza riguarda la comprensione dei rischi, la probabilità e l'entità delle perdite che può causare e l'identificazione di contingenze e strategie di mitigazione per mantenere un sano margine di profitto. Le domande che dovresti porci sono:

• cosa succede quando il "rilevamento root" fallisce?
• da quali tipi di attacchi il "rilevamento root" dovrebbe proteggere?
• qual è la probabilità che ciò accada?
• che tipo di perdite può causare un errore di "rilevamento radice"?
• esistono altre protezioni contro questo?
• è possibile rilevare rapidamente questo tipo di violazioni?
• è possibile innescare imprevisti che riducono o eliminano le perdite?
• L'azienda sarà ancora redditizia con quelle perdite?

Tutta la logica importante deve essere lato server

Sembri infastidito dalla possibilità di un utente malintenzionato in grado di installare la tua app in un ambiente virtuale. Sospetto che molti dei controlli di sicurezza e dei calcoli importanti siano sul lato client. In tal caso, devi davvero riprogettare la tua app per spostare tutti i controlli sul lato server:

• Le API dell'interfaccia di back-end esposte alle reti degli utenti devono richiedere l'autenticazione dell'utente.

• Le API dell'interfaccia back-end devono limitare ciò che l'utente può vedere e fare. I limiti di accesso dovrebbero essere imposti dal lato server, mai dal lato client. Con l'eccezione, ovviamente, dei servizi che non includono informazioni e comandi sensibili;

• Le API dell'interfaccia di back-end devono tenere conto della possibilità di attacchi di forza bruta. Un utente malintenzionato può scaricare enormi porzioni del database e indovinare password e codici di conferma deboli provandoli tutti.

• Le API interne - quelle usate dal back-end e non esposte alle reti degli utenti - compongono un livello di servizio interno che dovrebbe utilizzare utenti del servizio o certificati client per l'autenticazione. Le informazioni dell ' utente reale dovrebbero essere propagate a quei servizi per scopi di registrazione.

So che questo è molto deludente. Con queste limitazioni, le API dell'interfaccia di back-end devono essere molto specifiche per i flussi di lavoro delle app e quindi meno riutilizzabile. Sfortunatamente, solo le API interne possono essere riutilizzabili. Ciò significa anche che gli sviluppatori back-end dovranno comprendere molto bene l'esperienza utente, i flussi di lavoro progettati e lavorare a stretto contatto con i team front-end che sono cose che alla maggior parte degli sviluppatori non piacciono o sono preparate a fare.

Anche con tutta la logica importante sul server, è necessario progettare i flussi di lavoro per tenere conto di altri rischi

Se l'app segue le linee guida sopra menzionate, non importa se il lato client l'app è manomessa sul dispositivo di un utente malintenzionato. Lui o lei non sarà in grado di fare nient'altro che ciò che le credenziali utente che hanno gli consentirebbero di fare tramite l'app ufficiale lato client.

Ma se il dispositivo di un utente reale è rootato, il malware sarà in grado di:

• bypassare il rilevamento del dispositivo rooted;
• acquisire le credenziali dell'utente;
• reindirizza l'utente a una pagina falsa;
• reindirizza l'utente a un'app falsa;
• controlla in remoto il dispositivo;

Questi attacchi non sono molto comuni. Questi sono difficili perché di solito richiedono all'utente di eseguire procedure complicate. Ma se il prodotto è costoso o le informazioni sono troppo sensibili, questi attacchi devono essere presi sul serio.

Se la tua preoccupazione è perché i tuoi "venditori" trattano prodotti costosi in cui le perdite sono notevoli e non facilmente recuperabili, devi considerare barriere secondarie come:

• convalida del supervisore su operazioni più grandi;
• convalidare l'indirizzo di consegna con diversi database esterni;
• migliorare il monitoraggio delle consegne;
• imporre vincoli di tempo alle consegne in base al rischio.

Se ciò non bastasse, puoi scegliere di fornire un dispositivo di proprietà dell'azienda che è bloccato per impedire installazione dell'app e bloccare l'USB solo per la ricarica. Conosco alcune persone che girano continuamente con tre telefoni aziendali di aziende diverse: è ancora una cosa.

Sviluppa buoni log e monitorali

Anche il monitoraggio è una buona strategia per evitare molte perdite. Il backtracking delle perdite sui registri consente una migliore comprensione di come si verificano e di cosa hanno fallito, propone modifiche ai prodotti o almeno monitora tali situazioni per ottenere avvisi anticipati di situazioni simili in futuro.

Se i registri sono sufficientemente dettagliati, esistono tecniche di biometria comportamentale facili da implementare e in grado di rilevare molti tipi di intrusioni e alcuni tipi di errori operativi abbastanza presto per evitare perdite.

Hai una versione desktop?

Quando hai detto "Abbiamo una versione mobile del prodotto", sembrava che ne avessi un'altra. Hai una versione desktop? I sistemi operativi desktop sono rootati per impostazione predefinita e non c'è isolamento delle app. Se riesci a convivere con una versione desktop, probabilmente non hai nemmeno bisogno del rilevamento dei root in primo luogo.

È una buona cosa migliorare continuamente la sicurezza, e dovresti farlo, ma puoi aspettarti che la versione mobile sia più sicura di quella desktop a meno che non commetti un terribile errore nel nuovo sviluppo.