Sicurezza del debugger

Articolo
08/11/2011

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 Autorizzazioni di debug remoto.

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: la connessione a un processo di proprietà di un utente non attendibile può essere pericolosa. Se non si è certi o si diffida delle informazioni seguenti, non connettersi 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. Quando si utilizza la modalità Autenticazione di Windows, ricordare che è pericoloso concedere a un utente ritenuto non attendibile l'autorizzazione a eseguire il collegamento a msvsmon, come indicato da una finestra di dialogo di avviso.

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.

Simboli e codice sorgente

Di seguito sono riportati due strumenti di Visual Studio che richiedono alcune riflessioni sulla 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. Per ulteriori informazioni, vedere Procedura: ottenere codice sorgente mediante il server di origine e Avviso di sicurezza: il debugger deve eseguire un comando non attendibile.
Server di simboli che fornisce i simboli necessari per eseguire il debug di un arresto anomalo durante una chiamata di sistema. Per ulteriori informazioni, vedere Procedura: specificare percorsi di simboli e comportamento di caricamento e Procedura: utilizzare un server di simboli.