-
Notifications
You must be signed in to change notification settings - Fork 37.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
StompSubProtocolHandler logs failed authentication with error stack trace #26026
Comments
We could refine the logging, I presume you mean here. Those are errors from sending the message through the inbound channel, which does not include actually handling them, so it's mostly the channel interceptors which likely include some logging themselves. One option would be to log only a message without a stacktrace at ERROR but include the stacktrace at DEBUG. Would that work? |
It would be an improvement, but the real solution would be to add a catch handler for failed authorization exceptions before the catch-all handler and inside only call For spring websocket security, the exception seems to be |
Oh, I forgot: if you don't want to add a refeernce to spring-security-core just to catch the exception, you could perheps detect it by full class name or add a configuration option for users to decide which errors to handle without logging. |
We could only really make it configurable for custom exception classes, not refer to Spring Security exceptions there - not by reference and not by class name either. @rstoyanchev a fine-tuning of our default logging, like the stacktrace only at debug level as you suggested, would be worth backporting to 5.2.x and 5.1.x as well. |
Avoid a full stacktrace at ERROR level for a client message that could not be sent to a MessageChannel. See gh-26026
Avoid a full stacktrace at ERROR level for a client message that could not be sent to a MessageChannel. See gh-26026
For 5.2 and 5.1, I've refined the logging along the lines I suggested earlier. For 5.3.1 I've taken it further by not logging at all at ERROR level for rejected CONNECT messages which are failures before the session is even established, likely authentication failures, and therefore handled a bit differently. In such cases, where errors can only come from interceptors, it could be reasonably expected that interceptors themselves should decide what is appropriate to log in case of a rejection. Hopefully this works for you @icokk. |
It will work, thank you. |
StompSubProtocolHandler logs every exception, including failed authentication errors from spring-security-messaging, with error stack trace. This fills logs with garbage. It also allows simple DOS attacks by attempting unauthorized connection to websocket until the server disk is full.
Solution - allow authentication exceptions (for spring-security-messaging, it seems to be AccessDeniedException) to be returned to client as errors without logging anything.
The text was updated successfully, but these errors were encountered: