Ecco il contesto:ambiente di produzione - pagina di errore http 500 - no stacktrace per favore
Io lavoro per un'impresa molto grande. Qui, abbiamo molti cluster di WebSphere Application Server, ognuno con molte applicazioni Web Java EE. La maggior parte (ma non tutte) di queste applicazioni contengono direttive speciali nel loro web.xml per visualizzare una pagina di errore personalizzata quando si verifica un'eccezione imprevista. Ecco un esempio:
<error-page>
<error-code>500</error-code>
<location>/500.jsp</location>
</error-page>
Facendo questo, naturalmente, ci proponiamo di mostrare una pagina di errore amichevole per i nostri clienti, ma inoltre, abbiamo principalmente proponiamo di nascondere i stacktraces che di solito sono inclusi nelle pagine di errore standard http 500 .
Come dovresti sapere, questi stacktraces includono molti dati sensibili come i nomi dei pacchetti, i nomi delle classi e persino i nomi dei metodi. Peggio, a volte, questi stacktrace contengono eccezioni SQL, che spesso rivelano quale database viene utilizzato il software server. Ancora peggio, a volte queste stacktrace contengono percorsi di file e cartelle che, a loro volta, possono rivelare su quale famiglia di sistemi operativi viene eseguito il nostro WebSphere Application Server.
Devo menzionare tutti gli altri dati ancora più sensibili che possono essere rivelati da questi stacktraces? (Nome utente, numeri di porta, indirizzi IP, nomi di computer/server, nomi di oggetti JNDI ...)
Quindi, nessuna grande sorpresa qui, ogni grande impresa ha bisogno di nascondere questi stacktraces ai propri clienti.
Ma, ecco il nostro problema:
A volte, anche con una pagina di errore personalizzata ben configurato nel file web.xml, WebSphere invia la pagina di errore di base al browser web dei clienti. Capisco molto bene perché WebSphere lo faccia. Ad esempio, so che quando le intestazioni della risposta http sono già state commesse, WebSphere non può resettare il proprio buffer per inviare la pagina di errore personalizzata, e quindi non può fare di meglio che inviare una pagina di errore di base.
Ecco la mia domanda:
(1) E 'possibile configurare WebSphere in modo che mai e poi mai include qualsiasi stacktrace nella sua pagina di errore di base? In questo modo, anche quando, per qualche motivo tecnico, WebSphere non può inviare la nostra pagina di errore personalizzata, almeno la pagina di errore di base non includerà alcun dato sensibile.
Come possiamo fare questo?
Grazie,
Non può rispondere alla tua domanda specifica sulla disabilitazione l'analisi dello stack, ma non si dispone di un server web o proxy parte di WebSphere dove puoi impostare una pagina di errore lì? – dbreaux
Quando ottieni la pagina di errore predefinita stai usando un server web di fronte a WAS e passando attraverso il plugin http? – ams
Utilizziamo Microsoft Internet Information Server davanti ai nostri server WebSphere e utilizziamo il plug-in WebSphere (un filtro ISAPI) per inoltrare le richieste HTTP ai nostri server WebSphere. Inoltre, usiamo la console di amministrazione di WebSphere per generare i nostri file "plugin-cfg.xml". Non possiamo modificare questi file (perché se li modifichiamo per modificarli, li reeditiamo costantemente per mantenere le nostre modifiche). Pertanto, se sono necessarie alcune modifiche in questi file, la console di gestione di WebSphere includerà queste modifiche durante la generazione dei file "plugin-cfg.xml". – closingBrace