You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have verified that there is a certain situation where cross site scripting can occur due to user input appearing in a field validation error. This can occur when the error code does not resolve to any i18n message property. In this scenario, the defaultMessage on the FieldError can get rendered as HTML. This must be escaped because I have verified at least one case where the user input string ends up in this defaultMessage.
I won't publicly go into exactly how to reproduce this because of the sensitivity of the security flaw, but I'm willing to share more detail on how to reproduce it in private conversation with Fields plugin maintainers or Grails maintainers if they wish to discuss it with me further.
I've opened pull request #322 to patch this issue. This pull request escapes the defaultMessage. Tests have been added.
In my opinion, if this pull is accepted, a release should be done since this is a security related fix.
The text was updated successfully, but these errors were encountered:
* master:
If field validation error codes are unresolved and fallback to the defaultMessage on the error, this defaultMessage must be escaped due to the possibility of user input being in the error message. Fixes issue gpc#323.
Update readme.md
respect defaultNullable() of Validateable classes (issue gpc#218)
fix warning "Accessing config through dot notation is deprecated"
Added Action: Stale issues and pr's
Back to snapshot
Release 3.0.0.RC1
Use release versions of dependencies
Update dependencies
Bump up serverlet api version to 4.0.1
Bump up Groovy to 2.5.5
# Conflicts:
# build.gradle
# gradle.properties
I have verified that there is a certain situation where cross site scripting can occur due to user input appearing in a field validation error. This can occur when the error code does not resolve to any i18n message property. In this scenario, the
defaultMessage
on theFieldError
can get rendered as HTML. This must be escaped because I have verified at least one case where the user input string ends up in thisdefaultMessage
.I won't publicly go into exactly how to reproduce this because of the sensitivity of the security flaw, but I'm willing to share more detail on how to reproduce it in private conversation with Fields plugin maintainers or Grails maintainers if they wish to discuss it with me further.
I've opened pull request #322 to patch this issue. This pull request escapes the
defaultMessage
. Tests have been added.In my opinion, if this pull is accepted, a release should be done since this is a security related fix.
The text was updated successfully, but these errors were encountered: