Sicurezza del debugger

La possibilità di eseguire il debug di un altro processo offre poteri estremamente ampi che non sarebbero altrimenti disponibili, soprattutto quando si esegue il debug in remoto. Un debugger dannoso potrebbe infliggere danni diffusi al computer sottoposto a debug.

Tuttavia, molti sviluppatori non si rendono conto che la minaccia per la sicurezza può anche fluire nella direzione opposta. È possibile che il codice dannoso nel processo di debug comprometta la sicurezza del computer di debug: esistono diversi exploit di sicurezza che devono essere sorvegliati.

Procedure consigliate per la sicurezza

Esiste una relazione di trust implicita tra il codice di cui si sta eseguendo il debug e il debugger. Se si è disposti a fare il debug di qualcosa, si dovrebbe essere anche disposti a eseguirlo. In sintesi, è necessario poter fidarsi di ciò che si sta debugando. Se non puoi considerarlo attendibile, allora non dovresti eseguirne il debug, o dovresti farlo da un computer che puoi permetterti di compromettere, e in un ambiente isolato.

Per ridurre la superficie di attacco potenziale, il debug deve essere disabilitato nei computer di produzione. Per lo stesso motivo, il debug non deve mai essere abilitato per un periodo illimitato.

Sicurezza del debug gestito

Ecco alcune raccomandazioni generali applicabili a tutto il debug gestito.

• Prestare attenzione quando ci si connette al processo di un utente non attendibile: quando si esegue questa operazione, si presuppone che sia attendibile. Quando si tenta di connettersi al processo di un utente non attendibile, viene visualizzata una finestra di dialogo di avviso di sicurezza che chiede se si vuole collegarsi al processo. Gli "utenti attendibili" includono l'utente e un set di utenti standard comunemente definiti nei computer in cui è installato .NET Framework, ad esempio aspnet, localsystem, networkservice e localservice. Per altre informazioni, vedere Avviso di sicurezza: l'associazione a un processo di proprietà di un utente non attendibile può essere pericolosa. Se le informazioni seguenti sembrano sospette o non si è certi, non connettersi a questo processo.

• Prestare attenzione quando si scarica un progetto da Internet e lo si carica in Visual Studio. Questa operazione è molto rischiosa anche senza eseguire il debug. Quando si esegue questa operazione, si presuppone che il progetto e il codice che contiene siano attendibili.

  Per altre informazioni, vedere Debug di codice gestito.

Sicurezza del debug remoto

Il debug locale è in genere più sicuro rispetto al debug remoto. Il debug remoto aumenta la superficie totale che può essere esaminata.

Il Monitor di Debug Remoto di Visual Studio (msvsmon.exe) viene usato nel debug remoto e ci sono diverse raccomandazioni di sicurezza per la configurazione. Il modo preferito per configurare la modalità di autenticazione è l'autenticazione di Windows, perché nessuna modalità di autenticazione non è sicura.

Quando si usa la modalità di autenticazione di Windows, tenere presente che concedere a un utente non attendibile l'autorizzazione per connettersi a msvsmon è pericoloso, perché all'utente vengono concesse tutte le autorizzazioni nel computer che ospita msvsmon.

Non eseguire il debug di un processo sconosciuto in un computer remoto: esistono potenziali exploit che potrebbero influire sul computer che esegue il debugger o che potrebbero compromettere msvsmon. Se è assolutamente necessario eseguire il debug di un processo sconosciuto, provare a eseguire il debug in locale e usare un firewall per mantenere localizzate eventuali minacce potenziali.

Per informazioni sulla configurazione di msvsmon, vedere Configurare il debugger remoto.

Sicurezza del debug dei servizi Web

È più sicuro eseguire il debug in locale, ma poiché probabilmente Visual Studio non è installato nel server Web, il debug locale potrebbe non essere pratico. In genere, il debug dei servizi Web viene eseguito in modalità remota, tranne durante lo sviluppo, pertanto le raccomandazioni per la sicurezza del debug remoto si applicano anche al debug dei servizi Web. Ecco alcune procedure consigliate aggiuntive. Per altre informazioni, vedere Debug di servizi Web XML.

• Non abilitare il debug in un server Web compromesso.

• Assicurarsi che il server Web sia sicuro prima di eseguire il debug. Se non si è certi che sia sicuro, non eseguirne il debug.

• Prestare particolare attenzione se si esegue il debug di un servizio Web esposto su Internet.

Componenti esterni

Tenere presente lo stato di attendibilità dei componenti esterni con cui il programma interagisce, soprattutto se non è stato scritto il codice. Tenere presente anche i componenti che potrebbero essere usati da Visual Studio o dal debugger.

Simboli e codice sorgente

Di seguito sono riportati due strumenti di Visual Studio che richiedono un'idea della sicurezza:

• Server sorgente, che fornisce le versioni del codice sorgente da un repository di codice sorgente. È utile quando non si dispone della versione corrente del codice sorgente di un programma. Avviso di sicurezza: il debugger deve eseguire un comando non attendibile.

• Server simboli, utilizzato per fornire i simboli di debug necessari per risolvere un crash durante una chiamata di sistema.

  Consulta Specificare i file di simboli (.pdb) e di origine

Contenuti correlati

• Debugger Settings and Preparation (Impostazioni di debug e preparazione)
• Esaminare prima il debugger
• Avviso di sicurezza: l'associazione a un processo di proprietà di un utente non attendibile può essere pericolosa. Se le informazioni di seguito appaiono sospette o non siete certi, non collegatevi a questo processo.
• Avviso di sicurezza: il debugger deve eseguire un comando non attendibile