Sicurezza del debugger

Articolo
02/19/2013

La possibilità di eseguire il debug di un altro processo offre grandi potenzialità che altrimenti non si avrebbero, in particolare nel debug remoto.Un debugger dannoso potrebbe causare gravi danni al computer oggetto del debug.Questo è il motivo per cui non tutti possono eseguire il debug.Per ulteriori informazioni, vedere Remote Debugging Permissions.

Molti sviluppatori, tuttavia, non considerano il fatto che i rischi di sicurezza possono avere effetti opposti.È infatti possibile che il codice dannoso presente nel processo oggetto del debug metta a rischio la sicurezza del computer in cui è in corso il debug: molti sono gli attacchi da cui è necessario proteggersi.

Procedure di sicurezza consigliate

Esiste una relazione di trust implicita tra il codice di cui è in corso il debug e il debugger.Se si è disposti a eseguire il debug di un qualche oggetto si deve essere disposti anche a eseguirlo.Il fatto è che l'oggetto del debug deve essere ritenuto attendibile.Se non è possibile accertarne l'attendibilità, è consigliabile non eseguire il debug oppure eseguirlo da un computer per il quale si è disposti a correre dei rischi e che si trovi in un ambiente isolato.

Per ridurre le vulnerabilità potenziali, è consigliabile disabilitare il debug nei computer di produzione.Per lo stesso motivo non disabilitare mai il debug per un tempo indefinito.

Sicurezza del debug gestito

Di seguito sono riportati alcuni consigli generali che riguardano il debug gestito.

Prestare attenzione a eseguire il collegamento a un processo utente ritenuto non attendibile; così facendo, infatti, si presuppone che sia attendibile.Quando si tenta di eseguire il collegamento a un processo utente ritenuto non attendibile, verrà visualizzata una finestra di dialogo contenente un avviso di sicurezza in cui sarà necessario confermare l'operazione. Gli "utenti ritenuti 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 ulteriori informazioni, vedere Avviso di sicurezza: può essere pericoloso connettersi a un processo appartenente a un account utente non attendibile. Se le seguenti sottostanti risultano sospette o non sicure, non stabilire la connessione al processo..
Prestare attenzione nell'eseguire il download di un progetto da Internet e nel caricarlo in Visual Studio.Si tratta di un'operazione molto rischiosa anche senza debug.Così facendo si presuppone che il progetto e il codice in esso contenuto siano attendibili.

Per ulteriori informazioni, vedere Debug del codice gestito.

Sicurezza del debug remoto

Il debug locale è in genere più sicuro del debug remoto.Con il debug remoto aumentano i rischi di intrusione.

Nel debug remoto viene utilizzato Visual Studio Remote Debugging Monitor (msvsmon.exe) e per configurarlo sono disponibili numerosi consigli di sicurezza.Il modo migliore per configurare la modalità di autenticazione è Autenticazione di Windows, perché la modalità Nessuna autenticazione non è protetta.

Finestra di dialogo Errore

Quando si utilizza la modalità di autenticazione di Windows, tenere presente che concede un'autorizzazione utente non attendibile per la connessione a msvsmon è pericoloso, perché l'utente viene concesso a tutte le autorizzazioni nel computer..

Non eseguire il debug di un processo sconosciuto in un computer remoto: numerosi sono gli attacchi che potrebbero mettere a rischio il computer in cui è in esecuzione il debugger o che potrebbero compromettere Visual Studio Remote Debugging Monitor.Se è assolutamente necessario eseguire il debug di un processo sconosciuto, provare a eseguire il debug locale e utilizzare un firewall per contenere eventuali rischi.

Per ulteriori informazioni, vedere Installazione del debug remoto.

Sicurezza del debug di servizi Web

Il debug locale è più sicuro, ma poiché è probabile che Visual Studio non sia installato nel server, non è sempre pratico.In genere, il debug dei servizi Web viene eseguito in remoto, tranne durante lo sviluppo, pertanto le procedure consigliate relative alla sicurezza del debug remoto si applicano anche al debug dei servizi Web.Di seguito sono riportate alcune procedure consigliate aggiuntive.Per ulteriori informazioni, vedere Debugging XML Web Services.

Non attivare il debug in un server Web compromesso.
Prima di eseguire il debug assicurarsi che il server Web sia protetto.In caso di dubbi non procedere con il debug.
Prestare particolare attenzione nell'eseguire il debug di un servizio Web esposto su Internet.

Componenti esterni

Assicurarsi che i componenti esterni con cui il programma interagisce siano attendibili, soprattutto se il codice è stato scritto da altri.Verificare anche i componenti che Visual Studio o il debugger potrebbe utilizzare.