Protezione del debugger

Articolo
09/12/2008

Aggiornamento: novembre 2007

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 protezione possono avere effetti opposti. È infatti possibile che il codice dannoso presente nel processo oggetto del debug metta a rischio la protezione del computer in cui è in corso il debug: molti sono gli attacchi da cui è necessario proteggersi.

Procedure di protezione 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 disattivare il debug nei computer di produzione. Per lo stesso motivo non disattivare mai il debug per un tempo indefinito.

Protezione 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 protezione in cui sarà necessario confermare l'operazione. Gli "utenti ritenuti attendibili" includono l'utente e un insieme di utenti standard 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.

Protezione 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 protezione. 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.

Protezione 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 protezione del debug remoto si applicano anche al debug dei servizi Web. Di seguito sono riportate alcune procedure consigliate aggiuntive. Per ulteriori informazioni, vedere Debug dei servizi Web XML.

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 protezione:

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 protezione: 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 un percorso di simboli e Procedura: utilizzare un server di simboli.