Esiste un rischio per la sicurezza che esegue app web in debug="true"?

17

Questa è una copia di l'originale domanda su Stack Overflow che non ha avuto molto amore ed è probabilmente più pertinente qui:

Ci sono molti motivi per cui le app non devono essere eseguite in modalità debug="true" ( buon resoconto di Scott Gu ), ma ci sono dei vettori di attacco esposti da questa pratica? Non è una questione di "dovresti o non dovresti", tanto è chiaro, è una questione se introduce qualche vulnerabilità specifica.

Sono incline a pensare che la capacità di rilevarlo da remoto combinato con i noti problemi di prestazioni potrebbe portare a un exploit contro la disponibilità del servizio, ma mi piacerebbe qualcosa di un po 'più definito. Qualcuno sa di un attacco specifico che può essere orchestrato contro un'app che esegue debug="true"?

    
posta Troy Hunt 16.12.2010 - 01:56
fonte

6 risposte

11

Ho avuto alcuni feedback 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 prestazioni (non [direttamente] un problema di sicurezza).

La risposta più convincente è che le costanti di compilazione condizionale (#if DEBUG ...) potrebbero causare comportamenti imprevisti, ma 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 aprire alcuni percorsi ad altri exploit in base all'overhead delle prestazioni che posiziona sull'app e alla capacità di rilevarlo da remoto (rischio di continuità del servizio, forse). Ho scritto le mie conclusioni come parte di OWASP Top 10 per sviluppatori .NET parte 6: Configurazione errata della sicurezza .

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

    
risposta data 21.12.2010 - 23:16
fonte
5

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

Suppongo anche che, poiché debug = true causa l'errore di compilazione piuttosto che il customerror del sito previsto, potresti essere esposto al bug crittografico .net customerror.

link

    
risposta data 16.12.2010 - 03:23
fonte
3

La cosa più importante da tenere a mente quando debug = true è che i simboli ci sono. L'applicazione può essere precompilata con debug = true, ma questo fa parte del processo di distribuzione. Per esempio. lo si genera dal server di build o sul computer locale e si trasferiscono gli assembly. (tutti stanno precompilando le loro applicazioni prima della distribuzione della produzione, giusto ?! :)) Debug ha anche alcune ottimizzazioni del tempo di esecuzione disattivate. Un attacco evidente sarebbe un DoS. Se gli errori personalizzati sono disattivati, puoi trovare ulteriori informazioni sullo stack delle chiamate - più che se gli errori personalizzati sono disattivati e i simboli non sono presenti.

    
risposta data 16.12.2010 - 17:45
fonte
3

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

È 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

    
risposta data 16.12.2010 - 17:54
fonte
2

Questo dipende quasi interamente dall'ambiente linguistico / framework / di distribuzione.

Per python / django, è molto esplicito il caso che DEBUG = True sia un problema di sicurezza. Vedi per es. le note su non mostrare le variabili di configurazione per 'SECRET', 'PASSWORD', 'PROFANITIES' o 'SIGNATURE' - vedi link

    
risposta data 16.12.2010 - 21:37
fonte
2

È negativo dal punto di vista della perdita di informazioni, non c'è bisogno di ripeterlo. Inoltre in modalità debug la richiesta di timeout di esecuzione è di circa 5 ore, quindi è possibile eseguire il debug dell'applicazione senza generare timeout. (Il valore di timeout normale è 110 secondi per impostazione predefinita) Quindi, se gli aggressori trovano un codice che impiega troppo tempo per eseguire questo attacco, potrebbe trasformarsi in una negazione del servizio.

    
risposta data 20.12.2010 - 21:15
fonte

Leggi altre domande sui tag