-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Insecure Bean Validation query #3141
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should have mentioned earlier, I was added as a reviewer automatically by the CODEOWNERS
file. However this PR doesn't need a review from the docs team because it's changing the experimental
directory. We've since updated the CODEOWNERS
file to reflect this.
@github/codeql-java what is the status if this issue? I think @adityasharad wrote a more complete and precise query for this one. We should probably add a query for insecure bean validation asap since we have blog posts, workshops and talks about it. Im pretty sure some of our customers have these issues in their codebases |
Looks like status is "fallen through the cracks". Where is this "more complete and precise query"? I could look into reviewing and merging this PR, but just want to know whether there's a different query I ought to be looking at instead? |
I found this on the security_lab slack channel while reviewing it after coming back from the leave:
I assumed its more complete and accurate because its from @adityasharad :D but havent really look into it yet. Lets wait for @adityasharad feedback and move from there |
Yes: the version of the query Alvaro just shared traces the entire flow from the actual remote flow source, through classes/fields and their corresponding validators, and then to the sink within the validation method. It seems to work in its current form (at least for the target codebase), but I expect there are two potential areas of future cleanup:
|
Even though getting the full trace from the real remote source to the sink is great, we may want to keep the source at Also, the
|
import semmle.code.java.dataflow.FlowSources | ||
import DataFlow::PathGraph | ||
|
||
class BeanValidationSource extends RemoteFlowSource { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a remote flow source that ought to apply to all security queries or only this one? Conversely, does this query intend to use all remote flow sources as sources or just the BeanValidationSource
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In theory, the validated bean properties could reach a different sink (eg: a SQLi one) so this source need to be accounted for all security queries. Ideally the source should not be necessary but that would require taint steps like the ones in @adityasharad version of the query. That version of the query missed the new issues so I would stick to this source and treat it as a generic remote source.
@adityasharad are you ok with this? otherwise we can try to debug your query and see why its not working for the new cases.
class ExceptionTaintStep extends TaintTracking::AdditionalTaintStep { | ||
override predicate step(DataFlow::Node n1, DataFlow::Node n2) { | ||
exists(Call call, TryStmt t, CatchClause c, MethodAccess gm | | ||
call.getEnclosingStmt().getEnclosingStmt*() = t.getBlock() and | ||
t.getACatchClause() = c and | ||
( | ||
call.getCallee().getAThrownExceptionType().getASubtype*() = c.getACaughtType() or | ||
c.getACaughtType().getASupertype*() instanceof TypeRuntimeException | ||
) and | ||
c.getVariable().getAnAccess() = gm.getQualifier() and | ||
gm.getMethod().getName().regexpMatch("get(Localized)?Message|toString") and | ||
n1.asExpr() = call.getAnArgument() and | ||
n2.asExpr() = gm | ||
) | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This taint step seems too ad-hoc, please delete.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, will do, but that taintstep was required for the Netflix findings. In some cases, the way to validate a bean property is parsing it and consider it valid if it does not through an exception. Otherwise include the exception message in the bean validation error message. In that case, if the user input is reflected in the exception message, then it will lead to a real issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Taint flow through exceptions definitely is one of our blind spots, so I can understand the need for something like this. I would just like it to be a little more rigorous and then applied to all queries.
java/ql/src/experimental/Security/CWE/CWE-094/InsecureBeanValidation.ql
Outdated
Show resolved
Hide resolved
java/ql/src/experimental/Security/CWE/CWE-094/InsecureBeanValidation.ql
Outdated
Show resolved
Hide resolved
<qhelp> | ||
|
||
<overview> | ||
<p>When building custom constraint violation error messages, it is important to understand that they support different types of interpolation, including [Java EL expressions](https://docs.jboss.org/hibernate/validator/5.1/reference/en-US/html/chapter-message-interpolation.html#section-interpolation-with-message-expressions). Therefore if an attacker can inject arbitrary data in the error message template being passed to `ConstraintValidatorContext.buildConstraintViolationWithTemplate()` argument, he will be able to run arbitrary Java code. Unfortunately, it is common that validated (and therefore, normally untrusted) bean properties flow into the custom error message.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you insert some line breaks? Might as well make the qhelp a bit easier to read here in the diff view.
This could use a qltest. |
<qhelp> | ||
|
||
<overview> | ||
<p>Bean validation custom constraint error messages support different types of interpolation, including [Java EL expressions](https://docs.jboss.org/hibernate/validator/5.1/reference/en-US/html/chapter-message-interpolation.html#section-interpolation-with-message-expressions). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you perhaps apply a maximum line width of 80-120 or something like that for this entire file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should I include the MD links on that limit considering they shouldnt be visible in VSCode?
Missing pieces:
|
@jf205 and/or @shati-patel: could you take a look at the documentation for this query please? We're considering expediting its promotion from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added a few editorial suggestions 📝 😃
Co-authored-by: Shati Patel <42641846+shati-patel@users.noreply.github.com>
Co-authored-by: Shati Patel <42641846+shati-patel@users.noreply.github.com>
Co-authored-by: Shati Patel <42641846+shati-patel@users.noreply.github.com>
Co-authored-by: Shati Patel <42641846+shati-patel@users.noreply.github.com>
Co-authored-by: Shati Patel <42641846+shati-patel@users.noreply.github.com>
Co-authored-by: Shati Patel <42641846+shati-patel@users.noreply.github.com>
Co-authored-by: Shati Patel <42641846+shati-patel@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback @shati-patel
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two more tiny things I missed previously 🙈
Co-authored-by: Shati Patel <42641846+shati-patel@users.noreply.github.com>
No description provided.