Hier ist der Kontext:Produktionsumgebung - http 500 Fehlerseite - keine Stacktrace bitte
Ich arbeite für ein sehr großes Unternehmen. Hier haben wir viele WebSphere Application Server-Cluster, von denen jeder viele Java EE-Webanwendungen ausführt. Die meisten (aber nicht alle) dieser Anwendungen enthalten spezielle Anweisungen in ihrer Datei "web.xml", um eine benutzerdefinierte Fehlerseite anzuzeigen, wenn eine unerwartete Ausnahme auftritt. Hier ein Beispiel:
<error-page>
<error-code>500</error-code>
<location>/500.jsp</location>
</error-page>
Dadurch, dass natürlich wollen wir eine freundliche Fehlerseite zu unseren Kunden zeigen, aber darüber hinaus haben wir vor allem darauf abzielen, die stacktraces zu verstecken, die in der Regel in Standard-HTTP 500-Fehlerseiten enthalten sind, .
Wie Sie wissen sollten, enthalten diese Stacktraces viele sensible Daten wie Paketnamen, Klassennamen und sogar Methodennamen. Am schlimmsten ist, dass diese Stacktraces manchmal SQL-Ausnahmen enthalten, die oft aufzeigen, welche Datenbankserver-Software verwendet wird. Diese Stacktraces enthalten manchmal auch Datei- und Ordnerpfade, die wiederum zeigen, auf welcher Betriebssystemfamilie unser WebSphere Application Server ausgeführt wird.
Muss ich alle anderen noch sensibleren Daten erwähnen, die von diesen Stacktraces aufgedeckt werden können? (Benutzernamen, Portnummern, IP-Adressen, Computer-/Servernamen, Namen von JNDI-Objekten ...)
Also, keine große Überraschung (en) hier muss jedes große Unternehmen diese Stacktraces für seine Kunden verstecken.
Aber hier ist unser Problem:
Irgendwann, auch mit einer benutzerdefinierten Fehlerseite auch in der Datei web.xml konfiguriert, WebSphere sendet die Basisfehlerseite an den Webbrowser des Kunden. Ich verstehe sehr gut, warum WebSphere das tut. Als Beispiel weiß ich, dass WebSphere, wenn die Header der HTTP-Antwort bereits festgeschrieben sind, seinen Puffer nicht zurücksetzen kann, um die benutzerdefinierte Fehlerseite zu senden, und dann nicht besser ist, als eine grundlegende Fehlerseite zu senden.
Hier ist meine Frage:
(1) Ist es möglich, WebSphere zu konfigurieren, so dass es nie jemals einen Stacktrace in seiner Grundfehlerseite enthält? Auch wenn aus technischen Gründen WebSphere unsere benutzerdefinierte Fehlerseite nicht senden kann, enthält die Basisfehlerseite keine vertraulichen Daten.
Wie können wir das tun?
Danke,
Kann nicht Ihre Frage beantworten über den Stack-Trace zu deaktivieren, aber Sie haben einen Web-Server oder Proxy-in vor WebSphere, wo Sie dort eine Fehlerseite setzen können? – dbreaux
Wenn Sie die Standardfehlerseite erhalten, verwenden Sie einen Webserver vor WAS und gehen Sie durch das http-Plugin? – ams
Wir verwenden Microsoft Internet Information Server vor unseren WebSphere-Servern und verwenden das WebSphere-Plugin (einen ISAPI-Filter), um die HTTP-Anfragen an unsere WebSphere-Server weiterzuleiten. Außerdem verwenden wir die WebSphere-Administrationskonsole, um unsere Dateien "plugin-cfg.xml" zu generieren. Wir können diese Dateien nicht bearbeiten (denn wenn wir sie bearbeiten, um sie zu optimieren, würden wir sie ständig umstellen, um unsere Verbesserungen zu behalten). Wenn in diesen Dateien einige Änderungen erforderlich sind, muss die WebSphere-Administrationskonsole diese Änderungen enthalten, während die Dateien "plugin-cfg.xml" generiert werden. – closingBrace