Skip to content
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

don't reveal internal error details via UI #233

Merged
merged 1 commit into from
Jun 13, 2024

Conversation

Copy link
Member

@kelvin-chappell kelvin-chappell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@johnduffell johnduffell merged commit b73f563 into main Jun 13, 2024
1 check passed
@johnduffell johnduffell deleted the jd-security-improvement branch June 13, 2024 08:17
rtyley added a commit that referenced this pull request Jun 13, 2024
This follows on from #233 -
it turns out the `message` val is now unused, so we can remove it, and simplify
the code a little!

PR #233 removed the exception message text from the error displayed to the end user,
because the error message text is unconstrained and this corresponds to
https://owasp.org/www-community/Improper_Error_Handling .

I was tempted to include the `desc` string in the error message displayed to the user,
as it is just the string "anti-forgery-token-invalid" or the exception class name, which
is more constrained, but re-reading the OWASP doc, this is also discouraged as it's
very similar to an error code. ("internal error messages such as stack traces, database
dumps, and error codes"). When getting error reports in the past, I've found it helpful if
they have received an error with a bit more context in it, as surprisingly the error reports
often don't include the user that saw the error, or when the error occurred, making it harder
to search logs for them! Still, I do appreciate the guidance from OWASP is right.
@rtyley rtyley mentioned this pull request Jun 13, 2024
@@ -136,7 +136,7 @@ trait LoginSupport extends Logging {
case _: Throwable => (e.getClass.getSimpleName, e.getMessage)
}
logWarn(desc, e)
Future.successful(redirectWithError(failureRedirectTarget, message))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

message is now unused so we can get rid of it! Change made in #234

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants