From 3b23cd5be3f7068962322942d080f5f2fc29e143 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Alvaro=20Mu=C3=B1oz?=
There are different approaches to remediate the issue:
-There are different approaches to remediate the issue:
-- Do not include validated bean properties in the custom error message. -- Use parameterized messages instead of string concatenation. E.g: -``` java +
HibernateConstraintValidatorContext context = constraintValidatorContext.unwrap( HibernateConstraintValidatorContext.class );
context.addMessageParameter( "foo", "bar" );
context.buildConstraintViolationWithTemplate( "My violation message contains a parameter {foo}").addConstraintViolation();
-```
-- Sanitize the validated bean properties to make sure that there are no EL expressions.
- An example of valid sanitization logic can be found here.
-- Disable the EL interpolation and only use `ParameterMessageInterpolator`:
-``` java
+ParameterMessageInterpolator:
+
Validator validator = Validation.byDefaultProvider()
.configure()
.messageInterpolator( new ParameterMessageInterpolator() )
.buildValidatorFactory()
.getValidator();
-```
-- Replace Hibernate-Validator with Apache BVal which in its latest version does not interpolate EL expressions by default.
- Note that this replacement may not be a simple drop-in replacement.
+Bean validation custom constraint error messages support different types of interpolation, +
Custom error messages for constraint validators support different types of interpolation,
including Java EL expressions.
Controlling part of the message template being passed to Custom error messages for constraint validators support different types of interpolation,
including Java EL expressions.
Controlling part of the message template being passed to ConstraintValidatorContext.buildConstraintViolationWithTemplate()
argument will lead to arbitrary Java code execution. Unfortunately, it is common that validated (and therefore, normally
From 9785013c29d071f160250bafd078e5725bc6188c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Alvaro=20Mu=C3=B1oz?= ConstraintValidatorContext.buildConstraintViolationWithTemplate()
-argument will lead to arbitrary Java code execution. Unfortunately, it is common that validated (and therefore, normally
+argument can lead to arbitrary Java code execution. Unfortunately, it is common that validated (and therefore, normally
untrusted) bean properties flow into the custom error message.
There are different approaches to remediate the issue:
HibernateConstraintValidatorContext context = constraintValidatorContext.unwrap( HibernateConstraintValidatorContext.class ); context.addMessageParameter( "foo", "bar" ); From ac116da0dca54ab4d9e3fd7adf7e1e101928c069 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Alvaro=20Mu=C3=B1oz?=Date: Tue, 27 Oct 2020 21:11:48 +0100 Subject: [PATCH 31/34] Update java/ql/src/Security/CWE/CWE-094/InsecureBeanValidation.qhelp Co-authored-by: Shati Patel <42641846+shati-patel@users.noreply.github.com> --- java/ql/src/Security/CWE/CWE-094/InsecureBeanValidation.qhelp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/java/ql/src/Security/CWE/CWE-094/InsecureBeanValidation.qhelp b/java/ql/src/Security/CWE/CWE-094/InsecureBeanValidation.qhelp index aa63af22e4f..451a4f7de3f 100644 --- a/java/ql/src/Security/CWE/CWE-094/InsecureBeanValidation.qhelp +++ b/java/ql/src/Security/CWE/CWE-094/InsecureBeanValidation.qhelp @@ -30,7 +30,7 @@ Validator validator = Validation.byDefaultProvider() .buildValidatorFactory() .getValidator();
The following Validator could result in arbitrary Java code execution:
+The following validator could result in arbitrary Java code execution: