Sicurezza del debugger

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.

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 consigliate per la sicurezza

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 prova a eseguire il collegamento a un processo utente ritenuto non attendibile, viene visualizzata una finestra di dialogo contenente un avviso di sicurezza che chiede di confermare l'operazione. Gli "utenti ritenuti attendibili" includono l'utente corrente e un set di utenti standard comunemente definiti nei computer in cui è installato .NET Framework, ad esempio aspnet, localsystem, networkservicee localservice. Per altre informazioni, vedere avviso di sicurezza: La connessione a un processo appartenente a un utente non attendibile può essere pericolosa. Se le informazioni seguenti sono sospette o non si è certi della loro provenienza e del loro stato, non connettersi al processo.

• Prestare attenzione quando si scarica un progetto da Internet e lo si carica 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 altre informazioni, vedere Debugging Managed Code.

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 usato 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.

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 locale e usare un firewall per contenere eventuali rischi.

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

Sicurezza del debug di 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 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 altre 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. 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 di origine che fornisce le versioni di codice sorgente da un repository di codice sorgente. È utile quando non si dispone della versione corrente del codice sorgente di un programma. Security Warning: Debugger Must Execute Untrusted Command.

• Server di simboli che fornisce i simboli necessari per eseguire il debug di un arresto anomalo durante una chiamata di sistema.

  Vedere Specificare file di simboli (con estensione pdb) e di origine

Contenuto correlato

• Debugger Settings and Preparation (Impostazioni di debug e preparazione)
• Presentazione del debugger
• Avviso di sicurezza: la connessione a un processo appartenente a un utente non attendibile può essere pericolosa. Se le informazioni seguenti sono sospette o non si è certi della loro provenienza e del loro stato, non connettersi al processo
• Security Warning: Debugger Must Execute Untrusted Command