NoHandlerFoundException message should not contain all headers [SPR-12984]

[spring-projects-issues]

Lukas Krecan opened SPR-12984 and commented

If DispetcherServlet throwExceptionIfNoHandlerFound is set to true, NoHandlerFoundException is thrown. Unfortunately its message contains headers and thus cookies, which may be a security risk.

In our scenario we serialize the exception to JSON which is returned to the user. Malicious script (for example injected by XSS) can call nonexisting resource and it will get sensitive cookies in the error message.

We have fixed it by overriding noHandlerFound and by throwing custom exception but I am afraid that other users may get to similar situation.

---

Affects: 4.1.6

[spring-projects-issues]

Juergen Hoeller commented

"throwExceptionIfNoHandlerFound" is an opt-in feature that we've introduced in 4.0, so 3.2.x isn't affected to begin with. And by default, we simply send a 404, not revealing any headers at all.

Also, "throwExceptionIfNoHandlerFound" is primarily meant to allow for catching the exception in exception resolvers or exception handler methods. It isn't really meant to be propagated to the client...

Juergen

[spring-projects-issues]

Rossen Stoyanchev commented

Indeed the option was meant to allow handling 404s with the HandlerExceptionResolver mechansim. Furthermore, letting it go unhandled would also change the status from 404 to 500.

Lukas Krecan can you provide some more details? I presume you're actually handling the exception?

[spring-projects-issues]

Lukas Krecan commented

Yes, we are handling the exception and we are propagating it to the client. So the error is mostly on our side. I am just afraid that it's not so uncommon. Imagine you are using Spring MVC for implementing REST API. How would you implement error handling? It makes sense to throw an exception in case of error and use exception handler to serialize the error message (response). It's natural to include the exception message which, in this case, contains sensitive data.

[spring-projects-issues]

Juergen Hoeller commented

I'm turning this into an improvement request since this is really a combination of opt-in steps and not default behavior with an inherent vulnerability per se.

That said, point taken that the exception shouldn't necessarily render out all those details when stringified. We're revisiting that part for 4.2.

Juergen

[spring-projects-issues]

Rossen Stoyanchev commented

One more point is that DefaultHandlerExceptionResolver does handle the exception out of the box turning it into a 404.