È una vulnerabilità mostrare messaggi di eccezione in una pagina di errore?

18

La nostra applicazione web ha una pagina di errore che mostra il percorso URL assoluto e la query della pagina in cui si è verificato l'errore, la data / ora dell'errore e il messaggio di eccezione. (Non visualizziamo la traccia dello stack. Questa è un'evidente vulnerabilità.)

È una vulnerabilità visualizzare messaggi di eccezione in una pagina di errore?

Per la massima sicurezza, cosa dovremmo visualizzare in una pagina di errore? Cosa non dovremmo visualizzare?

EDIT: La mia impressione è che è una vulnerabilità, ma voglio sentire un'opinione di un esperto.

    
posta Matthew Rodatus 09.06.2011 - 16:12
fonte

3 risposte

18

In alcuni casi, i messaggi di errore inducono vulnerabilità. Nell'area della crittografia, il riempimento di oracle attack può recuperare una chiave segreta inviando messaggi crittografati alterati e utilizzando un "oracolo" "che distingue tra due tipi di errore (" padding was wrong "vs" c'era un padding valido, ma i dati risultanti erano senza senso "). Messaggi di errore dettagliati hanno un strong potenziale per essere un tale oracolo. In una visione più generale e concettuale, gli aggressori cercheranno di scoprire le debolezze sollecitando il sistema e osservando cosa succede, e più dati possono solo aiutarli. Il messaggio di eccezione non è qualitativamente diverso dalla traccia dello stack, a tale riguardo; quindi se la traccia dello stack è una vulnerabilità "ovvia", deve essere anche il messaggio di eccezione.

    
risposta data 09.06.2011 - 16:27
fonte
9

La divulgazione del percorso / perdita di percorso può anche essere utilizzata per improntare le app e i relativi server sottostanti, oltre a fornire l'enumerazione della superficie di attacco. Quasi tutte le applicazioni web che utilizzano pagine dinamiche perderanno percorsi di server web locali, a volte contenenti nomi utente e ovviamente directory vulnerabili.

Possono anche essere sfruttati durante l'inclusione dei file o gli attacchi di inclusione degli script. È necessario prestare particolare attenzione per i file PHP / CTP, ASP / ASPX e JSP / JSPX al fine di impedire che i messaggi di divulgazione dei percorsi vengano trasformati facilmente in un attacco di inclusione dei file, che può (ad esempio) leggere i file locali.

    
risposta data 09.06.2011 - 19:11
fonte
2

Non lo chiamerei necessariamente una vulnerabilità di per sé. L'eccezione da sola probabilmente non è sufficiente per violare la sicurezza del tuo server.

Ma è una debolezza che potrebbe rivelare informazioni che aiutano gli attaccanti o dà loro un piede nella porta. Ad esempio, potrebbe rivelare informazioni sul codice o sulla versione del software. Potrebbe essere più facile per gli aggressori provare gli attacchi e imparare come modificarli per farli funzionare.

Inoltre, a volte gli aggressori sono in grado di mettere insieme diversi punti deboli e combinarli per costruire un completo exploit. Nessuno dei punti deboli è di per sé una vulnerabilità, cioè nessuna debolezza da sola consentirebbe agli aggressori di violare la sicurezza del proprio sistema. Ma quando gli aggressori li combinano in modo intelligente, a volte forniscono abbastanza pietre miliari per consentire una vera e propria violazione della sicurezza.

Per queste ragioni, sarei incline a essere cauto riguardo a questo tipo di "debolezze". Sembra più sicuro cercare di evitarli, se puoi.

    
risposta data 10.06.2011 - 06:18
fonte

Leggi altre domande sui tag