Articolo
06/14/2018

Maggio 2018

Volume 33 Numero 5

Il presente articolo è stato tradotto automaticamente.

Sicurezza - Rileva e rispondi ai dispositivi Android rooted da Xamarin Apps

Problema di ultima novembre, ho illustrato come utilizzare i controlli Runtime, un inserimento di codice funzionalità inclusa in Visual Studio 2017, per proteggere le app .NET Framework da usi non autorizzati di un debugger, oltre che da eventuali manomissioni (msdn.com/magazine / mt845626). Da allora, un nuovo tipo di controllo è più disponibile. Il controllo radice rileva quando un'app xamarin è in esecuzione in un dispositivo "rooted", ovvero uno che consente alle App normale operare con le autorizzazioni di amministratore (accesso alla directory radice).

In questo articolo follow-up, è possibile spiegare perché dispositivi rooted rischi che devono comprendere tutti gli sviluppatori Android; in dettaglio come xamarin. Android gli sviluppatori possono utilizzare radice controlla per rilevare e rispondere a tale rischio; e illustrano le procedure consigliate con uno scenario di esempio.

Motivo per cui è necessario proteggersi radice

La piattaforma di Xamarin consente di creare facilmente App per dispositivi mobili per dispositivi Android, iOS e Windows. Gli sviluppatori esperti in linguaggi .NET come c# possono richiedere tali informazioni e applicare allo spazio di dispositivi mobili. Le tecnologie, ad esempio xamarin. Forms astraggono stoccaggi molti delle differenze tra le piattaforme, riducendo la complessità, costo e rischio di sviluppo di App multipiattaforma. Per mantenere aggiornati gli strumenti di Xamarin, è possibile continuare a supportare le nuove versioni e funzionalità di ogni piattaforma.

Tuttavia, alcuni aspetti specifici della piattaforma di sviluppo di applicazioni mobile meritano attenzione dello sviluppatore. Un aspetto di questo tipo è la sicurezza. Ogni piattaforma presenta rischi di sicurezza univoci e un modello di sicurezza univoci per soddisfare tali rischi. Ad esempio, i sistemi di autorizzazione diversi tra piattaforme e talvolta anche tra le versioni della stessa piattaforma.

Per le app Android, dispositivi rooted rappresentano un problema di sicurezza particolarmente importante. Tali dispositivi sono stati modificati per consentire alle app di interrompere il sandbox sicurezza normale che impone il sistema operativo. Ciò può esporre il dispositivo a molti pericoli, ad esempio malware e keylogger furto di password. Spesso, gli utenti radice i propri dispositivi per risolvere un problema, come una versione di un'app che non è normalmente disponibile per il dispositivo è stato, ovvero inavvertitamente la gravità di queste minacce. In altri casi, un utente non può essere anche tenere presente che il dispositivo è rooted e pertanto vulnerabile.

Ultimo mese di settembre, Payment Card Industry Consiglio di sicurezza standard (PCI SSC) rilasciato la versione 2.0 di dispositivi mobili pagamento accettazione sicurezza linee guida per gli sviluppatori. Per contrastare i rischi di sicurezza associati ai dispositivi rooted, le linee guida consiglia agli sviluppatori di app per dispositivi mobili implementano il rilevamento di radice e un meccanismo di risposta per l'app in quarantena (bit.ly/2H5ymge). Ecco il testo corrispondente dalla sezione 4.3 (enfasi aggiunto):

[T] dispositivo he da monitorare per le attività che aggirare sicurezza controls—e.g. sistema operativo, jailbreaking o radice, e, se rilevato, il dispositivo deve essere messi in quarantena da una soluzione che rimuove dalla rete, rimuove l'accettazione di pagamento applicazione dal dispositivo, attivare o disattivare l'applicazione di pagamento. Rilevamento jailbreak e radice offline e la quarantena automatiche sono chiave poiché alcuni utenti non autorizzati potrebbero tentare di inserire il dispositivo in uno stato offline per un'ulteriore aggirare il rilevamento.

Oltre ai rischi associati a un utente legittimo operativo l'app in un ambiente rooted, un tale ambiente può anche indicare un utente malintenzionato tentativo di decodificare l'app. Gli utenti malintenzionati utilizzano spesso dispositivi rooted per analizzare e creare versioni alterate delle App, che vengono quindi inseriti con malware. Aprire Web applicazione sicurezza progetto (OWASP) Elenca codice manomissione come uno dei principali 10 Mobile rischi (bit.ly/2GNbd4o) e in particolare alle chiamate di rilevamento radice e risposta come un modo per contrastare questo rischio. In caso contrario, in base a OWASP, può causare danni reputational e perdita di profitti.

Controlli di primo livello

Può essere difficile rilevare dispositivi rooted. Un dispositivo può essere impostato come radice adottare molte tecniche diverse e il set di tecniche disponibili cambia nel tempo e nelle versioni di Android. Di conseguenza, il codice di rilevamento radice deve evolversi costantemente adattare. Ciò è composto dal fatto che alcune tecniche radice malintenzionati tentano di nascondere all'utilizzo, in modo che il codice di rilevamento radice buona necessario risolvere anche questi contromisure. La gestione del codice di rilevamento radice aggiornato è un'operazione complessa e potrebbe non essere in cui si desidera impiegare le risorse limitate.

Fortunatamente, non è necessario scrivere codice personalizzato per rilevare radice. Protezione preEmptive - Dotfuscator Community Edition (CE), che è incluso in Visual Studio 2017 per Windows, può inserire radice controlla in App xamarin. Android. Radice controlla rilevare rooted ambienti, anche quando il dispositivo è offline. Oltre a un'azione standard "uscire dall'app", è possibile configurare i controlli per rispondere a rooting chiamando personalizzato codice dell'app.

Proprio come Xamarin stesso, radice controlla ridurre la complessità, costo e rischio rispetto all'implementazione di un'implementazione personalizzata. Mantenere aggiornati Dotfuscator e consentire che gestiscono il rilevamento di radice, ovvero riprendere a lavorare per le parti interessanti della tua app più veloce.

Scenario di esempio

Per dimostrare controlla radice, ho fornito un'app di esempio denominata TodoAzureAuth protetti. Si basa su un esempio di xamarin. Forms, TodoAzureAuth esistente (bit.ly/2InvU48), è stato scritto originariamente da David Britch.

Il resto di questo articolo viene illustrato l'app, la strategia di protezione è stata applicata al componente c++ e modalità di applicazione di tale strategia con verifica di radice. È possibile utilizzare questo case study, nonché scenari aggiuntivi inclusi nel repository GitHub dell'esempio (bit.ly/2GQutOv) per informazioni su approcci alla radice controlla è quindi possibile applicare alle App xamarin. Android.

Esempio: TodoAzureAuth originale si connette a un'istanza di App per dispositivi mobili di Microsoft Azure, consentendo agli utenti di visualizzare e modificare un elenco condiviso. Per illustrare come eseguire l'autenticazione in un'app Xamarin, l'esempio richiede all'utente di accedere con un account di Google prima dell'accesso all'elenco di attività da eseguire.

L'app inizia nella pagina di accesso, che non dispone di alcun campo, un pulsante di accesso. Quando l'utente seleziona questo pulsante, l'app delega il processo di accesso al sistema di OAuth di Google, che potrebbe richiedere all'utente di immettere credenziali, inclusa una password. Di conseguenza, l'app stessa non gestisce le credenziali. Dopo che l'utente ha effettuato l'accesso, l'app consente di visualizzare la pagina di elenco Todo, consentendo all'utente di accedere all'elenco di cose condivisa. L'utente può effettuare la disconnessione e tornare alla pagina di accesso selezionando il pulsante chiusura sessione.

Strategia di protezione: Per questo articolo, il progetto TodoAzureAuth Android, TodoAzure.Droid, è possibile trattato come se sta gestendo i dati sensibili, come farebbe un'app conforme con PCI. È possibile implementare una strategia di protezione appropriato tramite Dotfuscator CE per inserire un controllo principale nell'app, che produce una versione protetta dell'app, Protected TodoAzureAuth.

Nell'app protetto, quando l'utente seleziona il pulsante di accesso, il controllo radice attiva. Se l'app è in esecuzione in un dispositivo rooted, viene chiusa in modo anomalo e tutti gli ulteriori tentativi di eseguire l'app verranno chiuso anche dopo un messaggio di errore breve, anche se il dispositivo non è più una radice. Figura 1 Mostra una panoramica dell'app protette da questa strategia.

Panoramica delle App di esempio TodoAzureAuth protetto
Figura 1 Panoramica dell'App di esempio TodoAzureAuth protetto

Questa strategia sono in linea con le raccomandazioni fornite per le linee guida PCI indicate in precedenza:

L'app esegue il monitoraggio del dispositivo per radice.
L'app vengono messi in quarantena il dispositivo dalla disabilitazione di se stessa se radice viene rilevato.
Questo controllo di sicurezza opera anche quando il dispositivo è offline.

Quando l'app si disabilita automaticamente, gli avvisi di messaggio di errore l'utente che il dispositivo è unsafe. Benché non usato nell'esempio, un'app usando questo scenario potrebbe anche "numero di telefono home" per una piattaforma analitica, ad esempio Visual Studio App Center (bit.ly/2pYMuk5).

Oltre alle seguenti linee guida PCI, questa strategia anche sia allineato con l'indicazione OWASP per arrestare l'app in un ambiente radice per impedire la decompilazione. Ho configurato il controllo radice per attivare in altre parti nel codice, non solo il processo di accesso, in modo che se un utente malintenzionato produce una versione alterata dell'app con il rilevamento di radice del processo di accesso rimosso, altre parti dell'app possono comunque rispondere al radice. Dotfuscator offuscato anche il codice, l'aggiunta di un altro livello di protezione per l'app e il controllo radice.

Non tutte le app hanno gli stessi requisiti di sicurezza e pertanto non tutte le app devono rispondere al rooting nello stesso modo. Si è scelto un approccio strict per l'esempio, ma una strategia più severo potrebbe consentire all'app di eseguiti in dispositivi rooted in determinate circostanze. Per un esempio, vedere "Una protezione strategia alternativa."

Esempio protetto: È possibile visualizzare l'esempio TodoAzureAuth protetti utilizzando il collegamento di GitHub fornito in precedenza. Nel ramo master di impostazione predefinita, è possibile ho già configurato Dotfuscator CE per proteggere TodoAzure.Droid con una radice controllare in modo che l'app soddisfi la strategia illustrata in precedenza. È possibile seguire la cronologia Git, a partire da branch, prima di controlli per scoprire come applicata la procedura descritta in questo articolo per l'esempio.

Vedere Leggimi dell'esempio per informazioni dettagliate su come impostare, compilare ed eseguire l'esempio. Dopo aver configurato il controllo radice, è possibile terminato finestra del controllo facendo clic su OK, quindi ho salvato le modifiche apportate al file di configurazione Dotfuscator scegliendo File | Salvare progetto.

Ho creato TodoAzure.Droid in Visual Studio per testare l'applicazione protetta, per verificare che sia configurato correttamente il controllo radice per applicare la strategia di protezione desiderato.

Nota importante: Dopo l'avvio nuovamente l'app, l'app visualizzata la finestra di dialogo di errore visualizzato figura 4; dopo la chiusura di finestra di dialogo, l'app sia ancora una volta terminato. Per visualizzare la pagina di accesso anche in questo caso era necessario disinstallare e reinstallare l'app.

Il TodoAzure.Droid protetta in esecuzione in un emulatore Figura 4 il TodoAzure.Droid protetta in esecuzione in un emulatore

E speriamo che in questo articolo ha contribuito accende un modo per rilevare in modo efficace e di rispondere a una radice di dispositivi Android usando gli strumenti gratuito incluso in Visual Studio.

Mentre si usa un'app di esempio noto come riferimento, è possibile applicare i concetti introdotti in questo articolo per tutti i tipi di App xamarin. Android e varie altre strategie di protezione. Se è interessati a ottenere maggiori informazioni sulle verifiche, consiglia di leggere il mio precedente articolo di MSDN Magazine.

Al suo interno, discusso ulteriori tipi di controlli che è possibile applicare alle app .NET Framework e la modalità di utilizzo dei controlli può impedire violazioni dei dati. Può anche essere interessante le avanzate funzionalità di controllo e offuscamento di Dotfuscator Professional Edition (bit.ly/2xgEZcs) o lo strumento di supporto per Java e Android le app tradizionali, protezione PreEmptive - DashO (bit.ly/2ffHTrN). È possibile mantenersi aggiornati sulle sviluppi tutti i controlli e la protezione PreEmptive seguendo PreEmptive Solutions su Twitter (twitter.com/preemptive) e, visitare il blog (preemptive.com/blog). Una strategia di protezione alternativi

È quindi possibile applicare radice controlla per implementare la strategia scelta. Ad esempio, se l'app non deve uscire in alcuna circostanza, è possibile configurare un controllo radice per disabilitare determinate funzionalità quando viene rilevato radice, anziché se chiudesse l'app. Una singola app potrebbe essere necessario anche rispondere a rooting in modi diversi a seconda delle informazioni note in fase di esecuzione. Si consideri un'applicazione disponibile in più aree geografiche. Risposta dell'app a radice potrebbe essere necessario variano a seconda area per essere conformi alle leggi locali e ai regolamenti in vigore, soprattutto se la risposta include l'invio di report di incidenti allo sviluppatore ("collegarsi home").

È necessario valutare i rischi di sicurezza associati ai dispositivi rooted contro i rischi di business associati alienating agli utenti legittimi di tali dispositivi. Per questo articolo, presuppone che TodoAzure.Droid gestito i dati sensibili e di conseguenza, per impedire il furto di dati ed Esegui reverse engineering, dispositivi rooted sarà completamente proibiti. Se è possibile invece avevo considerati i dati non sensibili, è possibile potrei abbia implementato una strategia di protezione che consente ai dispositivi rooted in determinate circostanze, rendendo l'applicazione più accessibile per gli utenti esperti. Questa strategia alternativa, anziché l'app stessa, la disabilitazione dell'app avvisa l'utente quando viene rilevato un dispositivo rooted.

Questo avviso assicura l'utente è a conoscenza dello stato non protetto del dispositivo e i rischi associati come il furto di credenziali. L'utente può scegliere di annullare il tentativo di accesso o di accettare i rischi e continuare la connessione. Sul ramo del repository GitHub Protected TodoAzureAuth avvisa utenti, è possibile ho configurato Dotfuscator CE per proteggere TodoAzure.Droid con un controllo radice che implementa questa strategia di protezione alternativa.

Il file Leggimi in quel ramo vengono illustrati i punti più accurati della configurazione. Si noti che questa strategia alternativa esegue un compromesso tra accessibilità per utenti avanzati e minacce di decodifica. È anche possibile visualizzare la configurazione per il controllo facendo doppio clic su tale riga.

Il Dotfuscator verifica pagina, con un segno di spunta radice
Figura 2 di Dotfuscator verifica pagina, con un segno di spunta radice

Si noti che è possibile configurare più di una radice cercare un unico file di configurazione di Dotfuscator, anche se si non esegue questa operazione per questo articolo. Per un esempio di un'app protetta da più controlli, vedere l'app AdventureWorksSalesClient .NET Framework che ho scritto sull'ultima versione di novembre.

Aggiunta di un controllo radice

Dalla pagina di verifica, aggiunto un controllo radice facendo clic sul pulsante Aggiungi controllo radice. Quando ha, Dotfuscator visualizzata una nuova finestra per la configurazione del nuovo controllo. Figura 3 Mostra la configurazione completa; in questa sezione viene illustrato il significato di ogni impostazione e perché si è scelto di tali impostazioni.

Figura 3 configurazione del controllo radice, ovvero percorsi aggiuntivi nascosti per il nodo TodoAzure.dll compresso

Percorsi: Ogni controllo è associato a uno o più metodi nell'app, denominato percorsi. Quando l'app chiama tale metodo, il controllo radice viene attivata, il rilevamento in quel momento, se il dispositivo viene visualizzato per contenere una radice. Dopo l'esecuzione di tutti i configurato la funzionalità di reporting e risposta, presupponendo che tali misure non uscire dall'app, il controllo restituisce il controllo all'inizio del metodo.

Per il controllo dello scenario, sono selezionate più posizioni. Il percorso utilizzato inizialmente nell'app è TodoAzure.Droid.MainActivity.AuthenticateAsync, che consente di coordinare una richiesta di accesso. Utilizzando questo percorso, che il controllo radice eseguirà il rilevamento e una risposta ogni volta che inizia il processo di accesso.

Per la strategia di protezione dati, un'app in esecuzione in un dispositivo rooted viene chiuso quando viene raggiunto prima il metodo AuthenticateAsync. Pertanto, motivo per cui è stata aggiungere altri metodi che si verificano in un secondo momento nel ciclo di vita dell'app come percorsi aggiuntivi? Si tratta di proteggere le app attacchi di reverse engineering. Se un pirata informatico crea una versione dell'app che consente di ignorare o rimuovere il codice radice controllare a AuthenticateAsync alterata, questi altri percorsi ancora sarà in grado di rispondere a un ambiente rooted.

Alcuni di questi percorsi aggiuntivi vengono definiti in TodoAzure.dll. Può essere sorprendente, in tale assembly contiene la logica comune a tutte le piattaforme di Xamarin, non solo Android. Come può Dotfuscator inserire un controllo radice, ovvero che rileva una radice i dispositivi Android, ovvero in un assembly indipendente dalla piattaforma? Tenere presente che questo file di configurazione di Dotfuscator è specifico per il progetto TodoAzure.Droid, che fa riferimento al progetto TodoAzure. Quando Dotfuscator modifica TodoAzure.dll, verrà modificato solo l'assembly che Visual Studio o le copie di MSBuild da usare nel progetto corrente, TodoAzure.Droid. Assembly del progetto TodoAzure originale non subisce modifiche.

Notifica dell'applicazione: Controlli possono segnalare i risultati del loro rilevamento per il codice dell'app. In questo modo è possibile personalizzato dei comportamenti di reporting e risposta, mentre con i controlli inseriti dall'handle di Dotfuscator il lavoro di rilevamento. Il codice dell'app che riceve il risultato di rilevamento viene chiamato un Sink di notifica dell'applicazione.

Per soddisfare la strategia di protezione in questo scenario, è possibile necessarie per l'app stessa, disabilitare in modo che le esecuzioni future dell'app terminano con un messaggio di errore. Si è scelto di aggiungere questa logica in un metodo, TodoAzure.App.DisableIfCompromised, disabilitazione e usarlo come Sink del controllo impostando le proprietà di controllo seguenti:

ApplicationNotificationSinkElement: Il tipo di elemento di codice; In questo caso, un metodo.
ApplicationNotificationSinkName: Il nome semplice dell'elemento di codice. In questo caso, DisableIfCompromised.
ApplicationNotificationSinkOwner: Il tipo che contiene l'elemento di codice. In questo caso, TodoAzure.App.

Uno dei percorsi del controllo può chiamare questo metodo di Sink è pubblico e statico. Per essere compatibile con un segno di spunta, il metodo è sincrono (non-async), accetta un argomento singolo bool e presenta un tipo restituito void.

Quando attivata, il controllo della chiamata del metodo, passando il true argomento se il dispositivo è rooted e false in caso contrario. Quando questo argomento è vero, vale a dire, quando il controllo rileva definizione radice, ovvero il metodo consente di salvare un valore all'archiviazione locale, che indica l'app è stata disabilitata. Associata una proprietà, IsDisabled, espone il valore salvato:

// Definitions in TodoAzure.App
private const string DisabledPropertyKey = "AppStatus";
public static void DisableIfCompromised(bool wasCompromised)
{
  if (!wasCompromised) { return; }
  Current.Properties[DisabledPropertyKey] = new Random().Next();
  SavePropertiesNow();
}
public static bool IsDisabled =>
  Current.Properties.ContainsKey(DisabledPropertyKey);

Dopo la disabilitazione dell'app, le esecuzioni future necessario visualizzare un messaggio di errore e di uscita. A tale scopo, è possibile overrode TodoAzure.LoginPage.OnAppearing, che viene chiamato subito prima che venga mostrata la pagina di accesso all'avvio dell'app. Se l'app è disabilitato, questo metodo nasconde la pagina di accesso, visualizza una finestra di dialogo di errore e quindi viene chiuso.

// Definition in TodoAzure.LoginPage
protected override async void OnAppearing()
{
  if (App.IsDisabled)
  {
    IsVisible = false;
    var message = "The security of this device has been compromised. "
      + " The app will exit.";
    await DisplayAlert("App deactivated", message, "Exit App");
    App.Exit(); // Delegates to platform-specific exit logic
  }
  base.OnAppearing();
}

Poiché desidera inoltre difendersi attacchi di reverse engineering, ha impiegato misure aggiuntive per verificare che l'app sarebbe più resiliente a tali attacchi. È possibile utilizzare un nome per il valore salvato, AppStatus, rammenta e impostare il valore per un numero casuale, poco chiaro il significato del valore. È possibile inoltre configurare Dotfuscator per offuscare l'app, rinominare gli identificatori, ad esempio DisableIfCompromised, in modo che un utente malintenzionato visualizzazione codice decompilata non identificherà facilmente questo metodo come in corso di interesse. Per informazioni dettagliate sulla modalità di configurazione di offuscamento ridenominazione, vedere file Leggimi dell'esempio.

Azione: Mentre il Sink (il metodo DisableIfCompromised) una proprietà viene impostata per verificare che le esecuzioni future del exit app, non stesso uscire dall'app quando radice viene prima rilevato. Al contrario, ho configurato il controllo a tale scopo automaticamente impostando la proprietà azione di controllo in uscita.

Quando il controllo rileva un dispositivo rooted, il Sink di notifica e quindi chiude immediatamente l'app. Richiedendo la verifica, anziché il Sink, esegue questo uscita iniziale, è possibile distribuire più copie della logica di uscita tramite l'app. Come accade più percorsi, più copie della logica di uscita consentono all'app di migliore difendersi quando un utente malintenzionato ha rimosso alcuni la verifica di radice.

Per creare e testare l'App

Dopo aver configurato il controllo radice, è possibile terminato finestra del controllo facendo clic su OK, quindi ho salvato le modifiche apportate al file di configurazione Dotfuscator scegliendo File | Salvare progetto. Ho creato TodoAzure.Droid in Visual Studio per testare l'applicazione protetta, per verificare che sia configurato correttamente il controllo radice per applicare la strategia di protezione desiderato.

È possibile testare l'app in un dispositivo non contiene una radice, in un dispositivo rooted e in un emulatore. Nel dispositivo non contiene una radice, l'app siano stati eseguiti in genere, consentendo di accedere per visualizzare l'elenco attività. Tuttavia, nel dispositivo rooted e nell'emulatore, dopo aver selezionato il pulsante di accesso, l'app in modo anomalo chiuso. Dopo l'avvio nuovamente l'app, l'app visualizzata la finestra di dialogo di errore visualizzato figura 4; dopo la chiusura di finestra di dialogo, l'app sia ancora una volta terminato. Per visualizzare la pagina di accesso anche in questo caso era necessario disinstallare e reinstallare l'app.

Figura 4 il TodoAzure.Droid protetta in esecuzione in un emulatore

Conclusioni

E speriamo che in questo articolo ha contribuito accende un modo per rilevare in modo efficace e di rispondere a una radice di dispositivi Android usando gli strumenti gratuito incluso in Visual Studio. Mentre si usa un'app di esempio noto come riferimento, è possibile applicare i concetti introdotti in questo articolo per tutti i tipi di App xamarin. Android e varie altre strategie di protezione.

Se è interessati a ottenere maggiori informazioni sulle verifiche, consiglia di leggere il mio precedente articolo di MSDN Magazine. Al suo interno, discusso ulteriori tipi di controlli che è possibile applicare alle app .NET Framework e la modalità di utilizzo dei controlli può impedire violazioni dei dati.

Può anche essere interessante le avanzate funzionalità di controllo e offuscamento di Dotfuscator Professional Edition (bit.ly/2xgEZcs) o lo strumento di supporto per Java e Android le app tradizionali, protezione PreEmptive - DashO (bit.ly/2ffHTrN). È possibile mantenersi aggiornati sulle sviluppi tutti i controlli e la protezione PreEmptive seguendo PreEmptive Solutions su Twitter (twitter.com/preemptive) e, visitare il blog (preemptive.com/blog).

Una strategia di protezione alternativi

Questo articolo presenta una strategia per il rilevamento e la risposta a una radice dispositivi, ma altre strategie sono anche possibili. La strategia scelto deve essere appropriata per l'app, il contesto in cui viene usata l'app e la sicurezza implica il rischio è da risolvere. È quindi possibile applicare radice controlla per implementare la strategia scelta. Ad esempio, se l'app non deve uscire in alcuna circostanza, è possibile configurare un controllo radice per disabilitare determinate funzionalità quando viene rilevato radice, anziché se chiudesse l'app.

Una singola app potrebbe essere necessario anche rispondere a rooting in modi diversi a seconda delle informazioni note in fase di esecuzione. Si consideri un'applicazione disponibile in più aree geografiche. Risposta dell'app a radice potrebbe essere necessario variano a seconda area per essere conformi alle leggi locali e ai regolamenti in vigore, soprattutto se la risposta include l'invio di report di incidenti allo sviluppatore ("collegarsi home").

Quando si sviluppa una strategia di protezione, è anche necessario prendere in considerazione l'impatto che la strategia avrà sugli utenti dell'app che sono intenzionalmente rooted i propri dispositivi in buona fede. Questi "power users" potrebbe essere una parte significativa della base per i clienti e la disattivazione di dispositivi rooted Impossibile unità li lontano da app. È necessario valutare i rischi di sicurezza associati ai dispositivi rooted contro i rischi di business associati alienating agli utenti legittimi di tali dispositivi.

Per questo articolo, presuppone che TodoAzure.Droid gestito i dati sensibili e di conseguenza, per impedire il furto di dati ed Esegui reverse engineering, dispositivi rooted sarà completamente proibiti. Se è possibile invece avevo considerati i dati non sensibili, è possibile potrei abbia implementato una strategia di protezione che consente ai dispositivi rooted in determinate circostanze, rendendo l'applicazione più accessibile per gli utenti esperti. Questa strategia alternativa, anziché l'app stessa, la disabilitazione dell'app avvisa l'utente quando viene rilevato un dispositivo rooted. Questo avviso assicura l'utente è a conoscenza dello stato non protetto del dispositivo e i rischi associati come il furto di credenziali. L'utente può scegliere di annullare il tentativo di accesso o di accettare i rischi e continuare la connessione.

Sul ramo del repository GitHub Protected TodoAzureAuth avvisa utenti, è possibile ho configurato Dotfuscator CE per proteggere TodoAzure.Droid con un controllo radice che implementa questa strategia di protezione alternativa. Il file Leggimi in quel ramo vengono illustrati i punti più accurati della configurazione.

Si noti che questa strategia alternativa esegue un compromesso tra accessibilità per utenti avanzati e minacce di decodifica. In questa strategia, cattivi attori ancora possibile installare l'app in un dispositivo rooted ai fini di decompilazione; la finestra di dialogo di avviso non sarebbe arrestarli. È possibile comunque usato Dotfuscator per offuscare l'app, che fornisce un livello di protezione dalla decompilazione. Una vera app è stato possibile implementare controlli aggiuntivi, ad esempio richiedendo l'autenticazione speciale a usare l'app su un dispositivo rooted.

Figura A viene visualizzato l'avviso visualizzato dall'app quando viene eseguito un dispositivo rooted.

TodoAzure.Droid, protetto da questa strategia alternativa, in esecuzione in un emulatore, dopo che l'utente seleziona il pulsante di accesso
Figura un TodoAzure.Droid protetto da questa strategia alternativa, in esecuzione in un emulatore, dopo che l'utente seleziona il pulsante di accesso

Joe Sewellè un tecnico del software e un writer tecniche del team di Dotfuscator presso PreEmptive Solutions. Ha scritto in precedenza per il Blog ufficiale di Xamarin e MSDN Magazine.

Grazie per il seguente esperto tecnico di Microsoft per la revisione dell'articolo: David Britch
David Britch funziona nel gruppo di documentazione di Xamarin presso Microsoft. Ha scritto per una gamma di pubblicazioni di sviluppo software tra cui documentazione, questa documentazione, le implementazioni di riferimento, white paper, video e corsi di formazione con istruttore