production environment - http 500 error page - no stacktrace please

Question

Here’s the context:

I work for a very large enterprise. Here, we have many WebSphere Application Server clusters, each running many Java EE web applications. Most (but not all) of these applications contain special directives in their web.xml to display custom error page when an unexpected exception occurs. Here’s an example:

<error-page>
    <error-code>500</error-code>
    <location>/500.jsp</location>
</error-page>

By doing that, of course, we aim to show a friendly error page to our customers, but furthermore, we mainly aim to hide the stacktraces which are usually included in standard http 500 error pages.

As you should know, these stacktraces include a lot of sensitive data such as packages’ names, classes’ names and even methods’ names. Worst, sometimes, these stacktraces contain SQL exceptions, which often reveal which databases server software is used. Even worst, sometime, these stacktraces contain file and folder paths, which, in turn, can reveal on which operating systems’ family our WebSphere Application Server runs.

Do I need to mention all the other even more sensitive data which can be revealed by these stacktraces? (Usernames, port numbers, IP addresses, computer/server names, JNDI objects’ names…)

So, no big surprise(s) here, every large enterprise needs to hide these stacktraces to their customers.

But, here’s our problem:

Sometime, even with a custom error page well configured in the web.xml file, WebSphere sends the basic error page to the customers’ web browser. I understand very well why WebSphere do that. As example, I know that when the http response’s headers are already committed, WebSphere cannot reset its buffer to send the custom error page, and then cannot do better than sending a basic error page.

Here is my question:

(1) Is it possible to configure WebSphere so it never ever includes any stacktrace in its basic error page? This way, even when, for some technical reason, WebSphere cannot send our custom error page, at least the basic error page won't include any sensitive data.

How can we do this?

Thanks,

Fibro

Can't answer your specific question about disabling the stack trace, but do you have a web server or proxy in front of WebSphere where you can set an error page there? – Spline

When you get the default error page are using a web server infront of WAS and going through the http plugin? – Qadi

We use Microsoft Internet Information Server in front of our WebSphere servers and we use the WebSphere plugin (an ISAPI filter) to forward the HTTP requests to our WebSphere servers. Also, we use the WebSphere administration console to generate our "plugin-cfg.xml" files. We can not edit these files (because if we edit them to tweak them, we would constantly reedit them to keep our tweaks). So, if some modifications are required in these files, the WebSphere administration console shall include these modifications while generating the "plugin-cfg.xml" files. – Fibro

So we MUST use the WebSphere administration console to configure this, unless we find a way to configure Internet Information Server to retreive a custom error page (even if the error came from WebSphere, not from IIS). – Fibro

Answer 1

Do you have access to the WAS's configuration settings? If so you should be able to set a new default basic error page in the ErrorDocument directive in the httpd.conf.

Malayoindonesian

As far as I know,"httpd.conf" is Apache / IHS (IBM HTTP Server) related... We use Microsoft Information Server as Web Server in front of our WebSphere servers. Do you know if this file (httpd.conf) is involved even when WebSphere is behind Internet Information Server? – Fibro

Answer 2

As closingBrace said you should prevent printing stacktrace by configuring your Websphere application server.

Try this:
com.ibm.ws.webcontainer.suppressHtmlRecursiveErrorOutput is web container custom property to suppress the HTML output of the error text, without changing the internal logging of the message.

You can set this custom property to true to disable the HTML output of the error message to the user and present the user with blank page with a 500 error code.

Custom parameters should be placed in: Application servers>server_name>Web Container>Custom properties>

Sorosis