---

Novembre 2017

Volume 33 Numero 11

Il presente articolo è stato tradotto automaticamente.

Sicurezza - Protezione di dati e app da diffusione e uso non autorizzati

Da Joe Sewell

"Violazione dei dati". Queste due parole sono le parole più nello sviluppo del software. Software riguarda tutti i dati, l'elaborazione, la gestione e garantirne la protezione. Se un utente malintenzionato può violare i dati, l'azienda potrebbe annullata fondamentale per il successo di informazioni riservate, essere soggetta a problemi di responsabilità e la perdita del marchio importanti riguardo di fedeltà dei clienti.

Per gestire il rischio e conformarsi alle normative HIPAA e PILR, i team di sviluppatori e le operazioni consigliabile implementerà i controlli di sicurezza nel database e i servizi Web. Questi controlli includono la crittografia end-to-end, gestione delle identità rigorosi e rilevamento di anomalie di comportamento di rete. In caso di problemi di sicurezza, molti di questi controlli di reazione attivamente la registrazione di dettagli evento imprevisto, l'invio degli avvisi e bloccare le richieste sospette.

Durante queste e altre procedure consigliate è possono proteggere i componenti server, non avviene quanto per il software client. E per i dati siano utili, devono essere esposti in un modo per gli utenti con privilegi e software. La modalità è anche possibile verificare che il software client non causa una violazione dei dati?

Ad esempio, molte società creare software in modo specifico per l'utilizzo da ai dipendenti, spesso progettati per accedere ai dati aziendali riservati. E anche se Microsoft .NET Framework semplifica lo sviluppo di App di line-of-business (LOB) in linguaggi come c# o Visual Basic .NET, tali App compilata contiene ancora ad alto livello dei metadati e codice intermedio. Questo semplifica per un attore non valido per modificare l'applicazione con un utilizzo non autorizzato di un debugger, oppure decodificare l'app e creare una versione di compromessa. Entrambi gli scenari può comportare una violazione dei dati, anche se i componenti server sono completamente protette.

Mentre vi sono alcune misure è possibile intraprendere per proteggersi da tali attacchi: Authenticode firma e il codice offuscamento, al nome due, la maggior parte di essi sono passiva sono semplicemente deterrente agli attacchi, anziché rilevare, report e rispondere ad essi. Tuttavia, di recente, nuove funzionalità in Visual Studio consentono di inserire le funzionalità di rilevamento, reporting e la risposta di minaccia in App .NET con little-no necessità di codice aggiuntivo. Questi controlli di Runtime sono una misura di protezione dati attiva, in grado di modificare il comportamento dell'app in risposta a una minaccia alla sicurezza, pertanto la protezione dei dati sensibili.

In questo articolo presente una metodologia per utilizzando Runtime controlla in modo efficiente, tramite un'app LOB tipica come esempio. Verrà esaminato come un utente malintenzionato può utilizzare un debugger per causare una violazione di dati dettaglio come Runtime controlla possibile proteggere questa violazione e discutere il ruolo di questi controlli in un approccio a più livelli di protezione.

Soluzione di esempio

Per illustrare come una violazione dei dati può verificarsi in un client, ho preparato una soluzione di esempio LOB che può essere scaricata da bit.ly/2yiT2eY. Istruzioni per la compilazione, in esecuzione e utilizzando le varie parti della soluzione sono disponibili nella finestra-file Leggimi del codice di esempio.

La soluzione include quattro componenti:

Database AdventureWorks2014: Si tratta di un database di Microsoft SQL Server contenente il database di esempio Adventure Works 2014 OLTP. È possibile scaricare questo esempio bit.ly/2wM0yy0.

Servizio di vendita AdventureWorks: Si tratta di un servizio Web ASP.NET che espone i dati dal database, inclusi i dati riservati, quali le carte di credito dei clienti. Per rendere più semplice configurare questo componente, il codice di esempio omette la maggior parte dei controlli di sicurezza, ma ai fini di questo articolo presupporrà che il servizio implementa le operazioni seguenti:

• Due fattori di autenticazione, ovvero una password utente e un SMS inviato al telefono dell'utente su account di accesso
• Sessioni di tempo limitato
• Crittografia SSL per tutte le richieste e risposte

Adventure Works Client vendita: Si tratta di un client desktop di Windows Presentation Foundation (WPF) che si connette al servizio di vendite per manipolare i dati del cliente. Questo è il componente con cui l'articolo sarà maggiormente interessato.

Quando un dipendente di vendite viene eseguito il Client, l'accesso tramite il LoginDialog, che avvia la sessione autenticata e apre il CustomerWindow. Da questa finestra, il dipendente può visualizzare e modificare i nomi dei clienti o aprire EmailWindow, PhoneWindow o CreditCardWindow per modificare i dati riservati dei clienti. Alcune funzioni comuni vengono fornite anche in una classe statica denominata utilità.

Application Insights: Sebbene non sia necessario per eseguire l'esempio, Sales e del servizio Client può inviare dati di telemetria sull'utilizzo e di errore ad Application Insights. Con il Runtime controlla descritti in questo articolo, dati di telemetria del Client include anche la segnalazione di sicurezza.

Per questo articolo, sarà possibile concentrarsi sulla protezione del Client di vendite. Presupporrà che il database e il servizio di vendita sono già protetti. Naturalmente, che non è un presupposto provvisoria per rendere in uno scenario reale, ma consente di illustrare un punto: anche se è "eseguire tutto il diritto" con sicurezza del server, le violazioni di dati sono comunque possibili tramite il software client.

Verrà inoltre utilizzare i nomi dei clienti come dati non sensibili e invece lo stato attivo sulla protezione di carte di credito, indirizzi di posta elettronica e numeri di telefono. In uno scenario reale, i nomi dei clienti potrebbe inoltre essere considerate riservate e i dati sensibili non può includere, ad esempio, gli indirizzi di archivio delle vendite al dettaglio.

Violazione dei dati con un Debugger

Debugger sono gli strumenti di sviluppo eccellente. Consentono di individuare gli errori di logica critici, esaminare gli scenari di flusso di controllo complessa e diagnosticare i dump di arresto anomalo. Tuttavia, come qualsiasi strumento, debugger possono anche essere usati per male.

Si supponga che la rete intranet Adventure Works è un attore non valido, ad esempio un vindictive dipendente, un consulente esterno o anche un pirata informatico che ha ottenuto l'accesso non autorizzato alla intranet. L'autore dell'attacco non dispone dell'accesso al database o il servizio di vendita, ma può accedere portatile del dipendente di un cliente. Ovviamente si tratta di un problema di sicurezza, ma poiché il servizio di vendita implementa l'autenticazione a due fattori e l'autore dell'attacco non dispone dell'accesso al telefono del dipendente, i dati dei clienti non dovrebbero presentare rischi destra?

In realtà, no. L'utente malintenzionato può attendere per il dipendente di vendite di accedere tramite il Client di vendite e quindi, manualmente o tramite uno script, collegare un debugger al processo Client. Poiché il Client è un'applicazione .NET, il debugger, verrà visualizzate numerose informazioni di alto livello, incluso il token di sessione, anche se non sono presenti alcun simboli di debug (file PDB, ad esempio).

Figura 1 illustra questo scenario. Utilizzo del debugger WinDbg (bit.ly/2sh4clf) con l'estensione Psscor4 (bit.ly/2hbG2kk), dump di vari oggetti .NET nella memoria di un processo di vendita Client in esecuzione. Infine trovato l'oggetto AuthToken e il valore della proprietà HashField il dump.

Figura 1 WinDbg rivelare un Token di sessione nel Client di vendita

Con questo token di sessione, l'utente malintenzionato può effettuare richieste autenticate al servizio di vendite nel nome del dipendente. L'autore dell'attacco non è necessario continuare il debug o la modifica del Client. una volta possiede il token di sessione, egli può passare direttamente al servizio Web e usare il token per causare una violazione dei dati.

Esistono altri scenari in cui cattivi attori può utilizzare il Client in modo non autorizzato:

Manipolazione diretta di dati sensibili: Durante lo scenario precedente è una sessione Hijack attacco, perché il Client di vendite accede a dati sensibili (ad esempio carte di credito) come parte del normale funzionamento, che i dati possono essere visualizzati anche con un debugger. Gli utenti malintenzionati potrebbe provocare l'app funzioni insolitamente o modificare i dati nel database.

Esegui reverse Engineering: Gli utenti malintenzionati può inoltre eseguire autonomamente il Client e collegare un debugger per individuare il funzionamento di Client. In combinazione con la facilità di decompilare applicazioni .NET, gli utenti malintenzionati potrebbero essere in grado di rilevare exploit o altri dettagli importanti sul Client o servizio che consentono loro di pianificare un attacco.

Manomissione: Se gli utenti malintenzionati possono decodificare l'app e accedere al sistema di file del dipendente, il Client legittimo possono sostituire con una modifica segretamente estrazione o manipolazione dei dati quando il dipendente esegue l'accesso.

Altre applicazioni potrebbero essere esposti ai debugger in modi diversi. Ad esempio, un'app che indica la posizione del dipendente ai fini del rilevamento di lavoro può essere modificata per fornire dati non accurati. In alternativa, un gioco potrebbe rivelare informazioni strategiche chiave in un debugger.

Sui controlli Runtime

Controlli runtime è una nuova funzionalità di protezione PreEmptive - Dotfuscator Community Edition (CE), uno strumento di protezione incluso con Visual Studio dal 2003 (bit.ly/2wB0b9g). Si potrebbe sapere che Dotfuscator CE offuscare il codice intermedio degli assembly .NET, ma l'offuscamento non è l'oggetto di questo articolo. Invece mostro modalità di utilizzo viene verificato dal Runtime, successivamente, controlla solo, ovvero per consentire al Client di vendite per proteggersi mentre viene eseguito.

I controlli vengano convalide predefinite che Dotfuscator può inserire in applicazioni .NET. Le app sarà quindi in grado di rilevare usi non autorizzati, ad esempio debug o la manomissione. Nonostante il nome, controlli rilevano molto più di questi stati; sono anche reagire in modi precedentemente specificati, ad esempio uscendo dall'app. Controlli possono inoltre effettuare chiamate nel codice dell'applicazione, consentendo di comportamento personalizzato basato sul risultato del controllo. Queste funzionalità di reporting e di risposta sono configurabili per ogni controllo, in modo che tutte le App in grado di rilevare di utilizzo non autorizzato nello stesso modo, ma ogni app può rispondere in modo diverso per il rilevamento.

L'esempio di codice include un file di configurazione Dotfuscator.xml che è possibile indicare Dotfuscator per impedire che il Client di vendite non autorizzati di debug e di eventuali manomissioni. Nella parte restante di questo articolo, verrà illustrato modalità di creazione di questa configurazione, le scelte apportate, e come è possibile configurare in modo analogo Dotfuscator per proteggere la propria app.

Gli strumenti di configurazione

Il modo più semplice per iniziare con Dotfuscator CE consiste nell'utilizzare Visual Studio veloce (Ctrl + Q) per cercare "dotfuscator". Se non è installato Dotfuscator, verrà visualizzata un'opzione per installare PreEmptive protezione - Dotfuscator. Selezionare questa opzione e confermare le finestre di dialogo appropriate.

Una volta installato Dotfuscator, ripetizione di questa ricerca fornirà un'opzione per avviare gli strumenti | Protezione preEmptive - Dotfuscator; Selezionare questa opzione per iniziare a usare Dotfuscator. Dopo alcuni tipici prima utilizzare le finestre di dialogo, viene visualizzata l'interfaccia utente di Dotfuscator CE.

Nota importante: La protezione descritte di seguito e incluso nell'esempio richiede almeno la versione 5.32 di Dotfuscator CE. È possibile visualizzare la versione installata scegliendo Guida | Informazioni su. Se si utilizza una versione precedente, scaricare la versione più recente della Community Edition da bit.ly/2fuUeow.

Dotfuscator opera sui file di configurazione specializzato che specificano gli assembly deve essere protetto e su come applicare la protezione. Dotfuscator inizia con un nuovo file di configurazione caricato. Dopo aver modificato il per il Client di vendita usando la procedura seguente:

1. Innanzitutto, salvato il nuovo file di configurazione come AdventureWorksSalesClient\Dotfuscator.xml.
2. Successivamente, detto Dotfuscator dove trovare gli assembly del Client. Si passa alla schermata di Dotfuscator input e fatto clic sull'icona di segno verde. Finestra di dialogo Sfoglia seleziona Input, I spostarsi nella directory AdventureWorksSalesClient\bin\Release e quindi fa clic su Apri senza selezionare un file.
3. Dotfuscator aggiunto l'intera directory come un input denominato versione. Espanso il nodo dell'albero per verificare che l'assembly AdventureWorksSalesClient.exe era presente.
4. Quindi, apportate il file di configurazione portabile, anziché i percorsi specifici assoluto nel mio ambiente. È selezionato il nodo di rilascio, fatto clic sull'icona della matita e sostituito il percorso assoluto con \bin\Release ${configdir}. ${configdir} è una macro di Dotfuscator che rappresenta la directory che contiene il file di configurazione.
5. Infine, come in questo articolo non è attualmente preoccupato per le funzionalità di offuscamento del codice Dotfuscator, disabilitato li facendo clic sull'elemento nell'elenco di navigazione di Dotfuscator deselezionando Abilita ridenominazione.

Attacco intrusivo nel codice di controllo di configurazione

Dotfuscator consente di configurare i controlli dalla schermata attacco intrusivo nel codice, nella scheda controlli. Le scelte effettuate per la configurazione, tuttavia, variano a seconda del tipo di app per la protezione. Anziché elencare tutte le funzionalità e impostazioni, verrà dimostrativo le scelte e configurazione apportate per l'esempio Sales Client.

Per un esempio è stata configurata tre controlli:

• Due debug verifica, che consentono di individuare usi non autorizzati di un debugger:
  • Un "Login" debug controllare, per rilevare sessione Hijack scenari, come descritto in precedenza
  • Un "Query" debug controllare, per rilevare un debugger viene utilizzato per i dati sensibili nel Client di lettura/scrittura
• Un alterare assegno, che consente di rilevare utilizzo di un file binario dell'applicazione modificato

Figura 2 Mostra una panoramica dei controlli e il codice dell'applicazione con cui interagiscono. Nelle prossime tre sezioni, verrà illustrato lo scopo e la configurazione di ciascuna di queste verifiche.

Figura 2, il Client di vendita con i controlli Runtime inserito

Configurazione di debug di controllo dell'account di accesso

Questo primo debug verificare risolve lo scenario di Hijack della sessione. Rileva se un debugger è presente durante il processo di autenticazione e invia una notifica all'app in tal caso. L'app segnalerà l'evento imprevisto di Application Insights e successivamente errore in modo intuitivo.

Questo controllo aggiunto facendo clic sul pulsante Aggiungi debug verifica, portata in una nuova finestra di configurazione. È stata configurata questa verifica, come illustrato nel figura 3.

Figura 3 configurazione per il debug di controllo dell'account di accesso

Sede: Si è scelto innanzitutto la posizione nel codice dell'applicazione deve essere eseguito il controllo. In questo controllo deve rilevare il debug quando l'utente effettua l'accesso, archiviare il metodo LoginDialog.ConfirmLogin dall'albero di percorsi.

Si noti che il controllo viene eseguito solo quando viene chiamato il relativo percorso. Se un utente malintenzionato collega un debugger in un secondo momento, questo controllo non lo rileva; ma sarà risolvere questo problema in un secondo momento con il controllo di debug della Query.

Notifica di applicazione: Dopo l'esecuzione di un controllo, è possibile notificare il codice dell'applicazione in modo che l'app può segnalare e reagire in modo personalizzato. L'elemento di codice che riceve questa notifica è noto come il Sink di notifica di applicazione e viene configurato usando le proprietà di controllo seguenti:

• ApplicationNotificationSinkElement: Il tipo di elemento di codice (campo, metodo e così via)
• ApplicationNotificationSinkName: Il nome dell'elemento di codice
• ApplicationNotificationSinkOwner: Il tipo che definisce l'elemento di codice

Per tutti i tre controlli, si usa questa funzionalità di segnalazione dei problemi ad Application Insights. Inoltre, per questo controllo, ho deciso che desiderava una risposta personalizzata, anziché una risposta predefinito inserito da Dotfuscator (che verranno utilizzati da altri controlli). Risposta consente l'account di accesso abbia esito positivo, ma gli arresti anomali quindi l'app pochi istanti. Separando il rilevamento e la risposta, rende più difficile per un utente malintenzionato di individuare e risolvere il controllo.

Per ottenere la risposta, aggiunto un campo booleano, isDebugged, alla classe LoginDialog e configurato come Sink del controllo. Quando si esegue il controllo (ovvero, quando l'app chiama LoginDialog.ConfirmLogin), il risultato di rilevamento il debugger viene archiviato in questo campo: true per un debugger rilevato e false in caso contrario.

Si noti che il Sink deve essere accessibile in scrittura e accessibile dal percorso del controllo. Poiché sia il percorso e il Sink sono membri di istanza della classe LoginDialog, questa regola viene soddisfatta.

Successivamente, modificate LoginDialog.RunUserSession per passare al costruttore di CustomerWindow questo campo:

// In LoginDialog class
private void RunUserSession(AuthToken authToken) 
{
  // ...
  var customerWindow = new Windows.CustomerWindow(clients, isDebugged);
  // ...
}

Quindi, apportate il costruttore CustomerWindow impostare un campo, CustomerWindow.isDebugged e quindi segnalare l'evento imprevisto ad Application Insights:

// In CustomerWindow class
public CustomerWindow(Clients clients, bool isDebugged)
{
  // ...
  this.isDebugged = isDebugged;
  if (isDebugged)
  {
    // ClientAppInsights is a static class holding the Application 
    // Insights telemetry client
    ClientAppInsights.TelemetryClient.TrackEvent(
      "Debugger Detected at Login");
  }
  // ...
}

Infine, ho aggiunto codice che legge questo campo per vari gestori di eventi. Ad esempio:

// In CustomerWindow class
private void FilterButton_OnClick(object sender, RoutedEventArgs e)
{
  // ...
  if (isDebugged) { throw new InvalidCastException(); }
  // ...
}

Obviousness di isDebugged di nome di campo più avanti in questo articolo verranno descritti.

Configurazione di debug controllo Query

Poiché un debugger può essere associato al Client in qualsiasi momento durante l'esecuzione, l'account di accesso di debug verificare solo è insufficiente. Il controllo di debug della Query questa lacuna viene verificando un debugger, quando l'app sta eseguire query sui dati sensibili, ad esempio i numeri di carta di credito. La riservatezza dei dati significa anche che non permettersi di separare di rilevamento, rapporti e di risposta come con l'account di accesso di debug verificare, in quanto che consente a un utente malintenzionato visualizzare i dati. Il controllo di debug della Query, invece, verranno segnalare l'evento imprevisto e verrà quindi uscire immediatamente l'app quando viene rilevato un debugger.

Aggiunto il secondo debug controllare esattamente come è stato aggiunto il primo, ma questa volta, è stata configurata la verifica, come illustrato nel figura 4.

Figura 4 configurazione per la Query di controllo che indica la posizione di CreditCardWindow.UpdateData di debug, non vengono visualizzati in altre posizioni

Percorsi: Esistono tre tipi di dati sensibili in uno scenario: carte di credito, indirizzi di posta elettronica e numeri di telefono. Per fortuna, è possibile selezionare più percorsi per un singolo controllo. In questo caso, tali percorsi sono EmailWindow.UpdateData, PhoneWindow.UpdatePhones e CreditCardWindow.UpdateData. Il controllo viene eseguito ogni volta che uno di questi vengono chiamato, pertanto che è necessario configurare un solo set di proprietà di controllo per tutti e tre i tipi di dati sensibili.

Notifica di applicazione: Presenza di più percorsi Modifica funzionamento il Sink di notifica dell'applicazione. Nell'account di accesso di debug Archivia, potrebbe specificare il campo di LoginDialog.isDebugged come Sink di perché tale campo è accessibile dal percorso solo del controllo, LoginDialog.ConfirmLogin. Questa volta, ogni percorso deve essere in grado di accedere a un Sink.

In particolare, se la proprietà ApplicationNotificationSinkOwner è vuota, il Sink per impostazione predefinita utilizzando il tipo che definisce la posizione del controllo. Poiché il controllo dispone di più percorsi, il Sink pertanto possono variare a seconda della posizione in cui è stato attivato il controllo. In questo caso, questa proprietà a sinistra vuota e impostare il altri ApplicationNotificationSink proprietà a un metodo denominato ReportDebugging.

Si consideri il metodo EmailWindow.ReportDebugging:

// In EmailWindow class
private void ReportDebugging(bool isDebugging)
{
  if (isDebugging)
  {
    ClientAppInsights.TelemetryClient.TrackEvent(
      "Debugger Detected when Querying Sensitive Data",
      new Dictionary<string, string> { { "Query", "Email Addresses" } });
    ClientAppInsights.Shutdown();
  }

Quando l'app chiama il metodo EmailWindow.UpdateData, il controllo viene eseguito e quindi chiama questo metodo ReportDebugging true argomento se il debug è stato rilevato e false in caso contrario.

Lo stesso avviene quando il codice dell'applicazione chiama PhoneWindow.UpdatePhones o CreditCardWindow.UpdateData, ad eccezione del fatto che il metodo chiamato dal controllo di è definito da PhoneWindow o CreditCardWindow, rispettivamente. Questi metodi sono implementati in modo leggermente diverso, ma sono tutti denominati ReportDebugging accettano un solo argomento booleano e viene restituito alcun valore.

Azione: Per rendere l'app Chiudi se un debugger è collegato, impostare la proprietà azione di uscita. In questo modo Dotfuscator inserire il codice che consente di chiudere l'app quando il controllo rileva uno stato non autorizzato. Si noti che il controllo esegue questa operazione dopo avere notificato l'applicazione, pertanto in questo scenario che il report degli eventi imprevisti verrebbe inviato prima dell'applicazione viene chiusa.

Configurare il controllo manomissioni

Infine, aggiunto un controllo alterare all'indirizzo lo scenario di decodifica. Facendo clic su pulsante Aggiungi alterare verifica per configurare un nuovo alterare Check, come illustrato nella figura 5.

Figura 5 configurazione per il controllo di manomissioni, che indica la posizione di LoginDialog.ConfirmLogin, ovvero non vengono visualizzati in altre posizioni

Percorsi: Proprio come con la Query debug vedere, si è scelto di concedere il controllo alterare più posizioni: LoginDialog.ConfirmLogin, CustomerWindow.UpdateData e Utilities.ShowAndHandleDialog.

Con un debug controllare, disporre più posizioni è importante perché è stato possibile collegare il debugger in qualsiasi momento durante l'esecuzione. Ma alterare controllo avrà un solo risultato su un'esecuzione dell'app, il runtime caricato un assembly che è stato modificato o meno. Non deve essere sufficiente un'unica posizione? In realtà, poiché questo controllo è scoraggiare alterati i file binari, è necessario prendere in considerazione uno scenario in cui un utente malintenzionato è in grado di rimuovere il controllo alterare stesso da una posizione. Richiedendo a più posizioni, l'applicazione è molto più adattabile ai manomissione.

È possibile notare che uno dei percorsi, LoginDialog.ConfirmLogin, sia lo stesso di quello per il controllo di accesso di debug. Dotfuscator consente più tipi diversi di essere inseriti nella stessa posizione. In questo caso, dopo che l'utente accede, il debug sia manomissione verrà verificate.

Notifica di applicazione: Per il Sink di notifica dell'applicazione, ho deciso che sarebbe meglio in questo caso avere solo un Sink per tutte le posizioni. Questo avviene perché a differenza di con la Query debug verificare, non effettivamente rilevanti sul lato di creazione report quale percorso attiva il controllo.

Si è scelto di definire il metodo Utilities.ReportTampering come Sink. Con il contesto di ogni località, era necessario dichiarare il Sink statico e assicurarsi che sia stata accessibile da ogni posizione. Di conseguenza è definito il metodo:

// In Utilities static class
internal static void ReportTampering(bool isTampered)
{
  if (isTampered)
  {
    ClientAppInsights.TelemetryClient.TrackEvent(“Tampering Detected”);
    ClientAppInsights.Shutdown();
  }
}

Ogni volta che uno dei percorsi del controllo viene chiamato, il controllo determina se è stato modificato dopo Dotfuscator elabora e quindi chiama il metodo di ReportTampering con un parametro di true se è stata rilevata la modifica e false in caso contrario.

Azione: Se l'applicazione viene modificata, è pericoloso continuare. È configurato azione del controllo di uscita, in modo che l'app si chiude quando manomissione venga individuata.

Inserire i controlli

Con i controlli configurati, Dotfuscator può ora inserire tali in app. A tale scopo, da Dotfuscator CE, aprire il file di configurazione AdventureWorksSalesClient\Dotfuscator.xml e quindi fare clic sul pulsante di compilazione.

Dotfuscator elaborerà assembly del Client, inserire i controlli e scrivere Client protetti in AdventureWorksSalesClient\Dotfuscated\Release. L'app non protetta rimane in AdventureWorksSalesClient\bin\Release.

I controlli di test

Come con qualsiasi controllo di sicurezza, è importante testare il comportamento dell'app quando è stato introdotto il controllo.

Scenari normali: I controlli non devono avere alcun impatto sugli utenti legittimi dell'app. Si è stato eseguito il Client protetti in genere e non visto arresti anomali del sistema imprevisto, chiusura dell'applicazione o gli eventi di Application Insights.

Scenari non autorizzati: È inoltre necessario verificare che i controlli non previsto quando l'app viene utilizzata in modo non autorizzato. File Leggimi del codice di esempio sono elencati le istruzioni dettagliate per il test controlla il debug e il controllo di manomissioni. Ad esempio, per testare il controllo di debug della Query, è stata eseguita Client protetti più volte, collegare WinDbg per il processo in diversi punti. L'app correttamente segnalati e ha risposto alla presenza di un debugger in base alla configurazione del controllo.

Strategia di protezione a più livelli

Utilizzando una sola misura di protezione non è sufficiente per i casi più pratici e controlli non sono un'eccezione. Controlli devono essere un solo livello di una strategia di protezione, insieme a tecniche come la crittografia end-to-end, firma Authenticode dell'assembly e così via. Quando si usa più livelli di protezione, è possono che le potenzialità di un livello offset punto debole di un altro livello.

Nell'esempio di questo articolo, alcuni usato dai controlli di sink di notifica dell'applicazione hanno nomi come isDebugged o ReportTampering. Questi nomi di rimangano in assembly .NET compilati e un utente malintenzionato potrebbe facilmente comprendere l'intento di questi elementi di codice e risolverli. Per risolvere questo problema, Dotfuscator, oltre a inserire controlli, inoltre possibile eseguire offuscamento ridenominazione negli assembly. Per informazioni dettagliate, vedere la protezione PreEmptive-documentazione Dotfuscator Community Edition (bit.ly/2y9oxYX).

Conclusioni

Sono stati introdotti in questo articolo viene verificato dal Runtime e alcuni dei problemi che vengono risolti. Usando un'app LOB, illustrato come una violazione dei dati può verificarsi nel software client e il Runtime controlla può essere configurato per rilevare, report e rispondere a una violazione di sicurezza.

Mentre in questo articolo coperto Dotfuscator Community Edition gratuito, questi stessi concetti possono essere trasferiti a commercialmente con licenza Professional Edition, che include funzionalità aggiuntive per i controlli (bit.ly/2xgEZcs). È anche possibile inserire controlli nelle applicazioni Java e Android con elemento di pari livello prodotto del Dotfuscator, protezione PreEmptive - DashO (bit.ly/2ffHTrN).

---

Joe Sewell* è un tecnico del software e i writer tecniche del team di Dotfuscator presso PreEmptive Solutions.*

Grazie per il seguente esperto tecnico di Microsoft per la revisione dell'articolo: Dustin Campbell

---

Viene illustrato in questo articolo nel forum di MSDN Magazine