Allow custom ErrorReportValve to be used with Tomcat and provide whitelabel version

[patst]

During a penetration test one finding was the information disclosure of using a Tomcat webserver.

If a request with an invalid URL (e.g. http://localhost:8080/[test ) is executed the configured custom error pages are not used.
Instead the embedded Tomcats ErrorReportValve is used and presents a default Tomcat Error page.

It is possible to configure it to some extends using

• server.error.whitelabel.enabled=false
• server.error.include-stacktrace=never

But the default HTTP Status 400 page is always returned.

It is possible to create a custom ErrorReportValve and set the properties like errorCode.400 to create a custom page, but this configuration is not possible with an application.properties file.

(At least as far as I can see)
See an example project at https://github.com/patst/tomcat-errorvalve

Maybe it would be a good idea to expose the properties for configuration.

The ErrorReportValve is created at

spring-boot/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/web/embedded/TomcatWebServerFactoryCustomizer.java

Line 295 in 7671561

private void customizeErrorReportValve(ErrorProperties error, ConfigurableTomcatWebServerFactory factory) {

What do you think?

[philwebb]

We're probably not going to be able to customize the ErrorReportValve because valve.setProperty requires a file and that won't work with fat jars.

We'd like to investigate a little more to find out why the ErrorReportValve is being used and the DispatcherServlet isn't being called at all.

[gaurav-91]

Hi,
I would like to work on this request.

Thanks

[philwebb]

@gaurav-91 Thanks for the offer to help, but would you mind not commenting on multiple issues. It sends email notifications to everyone watching the issue tracker.

If you're new to the project and looking to help, I've just flagged #21531 as a first-timers-only issue so you might want to claim that.

[wilkinsona]

This also occurs for a request with an illegal HTTP header:

$ curl -H '(request): test'  http://localhost:8080/person

[wilkinsona]

We'd like to investigate a little more to find out why the ErrorReportValve is being used and the DispatcherServlet isn't being called at all.

This happens when the failure occurs before the request has been matched to a particular context. An illegal HTTP header or a malformed URL will both cause such a failure.

[wilkinsona]

With Jetty, a request with an illegal HTTP header produces the following response:

HTTP/1.1 400 Illegal character VCHAR='('
Content-Type: text/html;charset=iso-8859-1
Content-Length: 70
Connection: close

<h1>Bad Message 400</h1><pre>reason: Illegal character VCHAR='('</pre>

Undertow produces the following response:

HTTP/1.1 400 Bad Request
Content-Length: 0
Connection: close

If we can't route into the app and its error pages, Undertow's response seems like the best alternative as there's nothing in it that could be used to identify the server that is producing the response.

[wilkinsona]

The response body can be suppressed when using Jetty by configuring the Server with a custom ErrorHandler:

@Bean
JettyServerCustomizer serverCustomizer() {
    return (server) -> {
        server.setErrorHandler(new ErrorHandler() {

            @Override
            public ByteBuffer badMessageError(int status, String reason, HttpFields fields) {
                return null;
            }
            
        });
    };
}

We can't do anything about the reason in the status line as the logic that generates it isn't pluggable.