Ho ricevuto alcuni commenti interessanti su questa domanda sia qui che su Stack Overflow. Ci sono state molte risposte relative alle tracce dello stack (un problema di errori personalizzati, non un problema di debug) e alle prestazioni (non [direttamente] un problema di sicurezza).

La risposta più convincente è che le costanti di compilazione condizionale ( #se DEBUG ...) potrebbe causare un comportamento imprevisto, ma anche questo è più un rischio di funzionalità (codice non intenzionale eseguito in un ambiente live), che un rischio per la sicurezza.

Sospetto che la modalità di debug possa aprirsi alcuni percorsi verso altri exploit basati sul sovraccarico di prestazioni che pone sull'app e sulla capacità di rilevarlo da remoto (forse rischio di continuità del servizio). Ho scritto le mie conclusioni come parte della OWASP Top 10 per sviluppatori .NET, parte 6: Configurazione errata della sicurezza.

Quindi, per completezza, la risposta sembra essere questa non esiste un chiaro rischio per la sicurezza derivante dall'esecuzione in modalità di debug, ma certamente non è una buona idea per le app di produzione dati i fattori sopra menzionati.

Consentendo ai potenziali aggressori l'accesso potenziale al codice sorgente, alle tracce dello stack, ecc., certamente consente loro di focalizzare / restringere un attacco al sistema.

Suppongo anche (sebbene non abbia testato it) che poiché debug = true causa l'errore di compilazione piuttosto che il customerror del sito previsto, potresti essere esposto al bug crypto .net customerror.

http://blogs.technet.com/ b / srd / archive / 2010/09/17 / comprensione-della-asp-net-vulnerability.aspx

La cosa più importante da tenere a mente quando debug = true è che i simboli sono lì. L'applicazione può essere precompilata con debug = true, ma questo fa parte del processo di distribuzione. Per esempio. lo fai compilare dal server di compilazione o sulla tua macchina locale e trasferisci gli assembly. (tutti stanno precompilando le proprie applicazioni prima della distribuzione in produzione, giusto ?! :)) Debug ha anche alcune ottimizzazioni di runtime disattivate. Un attacco ovvio sarebbe un DoS. Se gli errori personalizzati sono disattivati, puoi anche trovare ulteriori informazioni sullo stack di chiamate, più che se gli errori personalizzati sono disattivati ​​e i simboli non sono presenti.

Penserei che se customErrors = off e debug = true, a un utente malintenzionato verrebbero inviate ancora più informazioni.

È più sicuro dire customErrors = on o customErrors = RemoteOnly. In questo modo un utente remoto riceverà sempre la pagina di errore ASP.NET generica. Ulteriori informazioni su MSDN

Questo dipende quasi interamente dal linguaggio / framework / ambiente di distribuzione.

Per python / django, è molto esplicitamente il caso che DEBUG = True sia un problema di sicurezza. Vedi ad es. le note sulla mancata visualizzazione delle variabili di configurazione per "SECRET", "PASSWORD", "PROFANITIES" o "SIGNATURE" - vedere http://docs.djangoproject.com/en/dev/ref/settings/#debug

È negativo dal punto di vista della fuga di informazioni, non è necessario ripeterlo. Inoltre, in modalità debug, il timeout di esecuzione della richiesta è di circa 5 ore, quindi puoi eseguire il debug dell'applicazione senza ottenere timeout. (Il valore di timeout normale è 110 secondi per impostazione predefinita) Quindi, se gli aggressori trovano un codice che impiega troppo tempo per eseguire, l'attacco potrebbe trasformarsi in un Denial of Service.