Java: automodel application mode: use endpoint class like in framework mode #13886
Conversation
kaeluka
force-pushed
the
kaeluka/java-automodel-variadic-args
branch
from
57cd4c1
to
d31e48d
Compare
…rely on normal argument node for nicer extracted examples
kaeluka
force-pushed
the
kaeluka/java-automodel-variadic-args
branch
from
6f746c7
to
e1a5eba
Compare
…responding to a varargs array
kaeluka
force-pushed
the
kaeluka/java-automodel-variadic-args
branch
from
4906015
to
3433437
Compare
|
@jcogs33, are you able to take a look? CI Checks are |
Sure, I'll try to take a look sometime tomorrow (2023/08/09). |
There was a problem hiding this comment.
I added a couple minor questions, otherwise looks reasonable to me. You might want a second pair of
For varargs arguments, we only use the first argument passed as endpoint (example). This is easy and avoids redundancy. We're not forced to do it that way, but it makes sense to me. Otherwise, we'd push complexity to the the classification script (eg., it might decide to use competing classifications for a given MaD model) and to the triage tooling. Do you agree?
I agree that just using the the first varargs argument as endpoint sounds like the best solution.
java/ql/src/Telemetry/AutomodelApplicationModeExtractCandidates.ql
Outdated
Show resolved
Hide resolved
| @@ -63,11 +64,13 @@ where | |||
| characteristic2.hasImplications(positiveType, true, confidence2) | |||
| ) and | |||
| message = characteristic | |||
| select endpoint, message + "\nrelated locations: $@." + "\nmetadata: $@, $@, $@, $@, $@, $@.", // | |||
| select endpoint.asNode(), | |||
| message + "\nrelated locations: $@." + "\nmetadata: $@, $@, $@, $@, $@, $@.", // | |||
There was a problem hiding this comment.
Same question about whether there should be another $@ for DollarAtString isVarargsArray?
| CharacteristicsImpl::isKnownSink(endpoint, sinkType) and | ||
| exists(CharacteristicsImpl::getRelatedLocationOrCandidate(endpoint, CallContext())) | ||
| select endpoint.asNode(), | ||
| sinkType + "\nrelated locations: $@." + "\nmetadata: $@, $@, $@, $@, $@, $@.", // |
There was a problem hiding this comment.
Same question about whether there should be another $@ for DollarAtString isVarargsArray?
| @@ -1,2 +1,3 @@ | |||
| | Test.java:16:3:16:11 | reference | command-injection, path-injection, request-forgery, sql-injection\nrelated locations: $@.\nmetadata: $@, $@, $@, $@, $@, $@. | Test.java:16:3:16:24 | set(...) | CallContext | file://java.util.concurrent.atomic:1:1:1:1 | java.util.concurrent.atomic | package | file://AtomicReference:1:1:1:1 | AtomicReference | type | file://false:1:1:1:1 | false | subtypes | file://set:1:1:1:1 | set | name | file://(String):1:1:1:1 | (String) | signature | file://Argument[this]:1:1:1:1 | Argument[this] | input | | |||
| | Test.java:21:3:21:10 | supplier | command-injection, path-injection, request-forgery, sql-injection\nrelated locations: $@.\nmetadata: $@, $@, $@, $@, $@, $@. | Test.java:21:3:21:16 | get(...) | CallContext | file://java.util.function:1:1:1:1 | java.util.function | package | file://Supplier:1:1:1:1 | Supplier | type | file://true:1:1:1:1 | true | subtypes | file://get:1:1:1:1 | get | name | file://():1:1:1:1 | () | signature | file://Argument[this]:1:1:1:1 | Argument[this] | input | | |||
| | Test.java:16:3:16:11 | reference | command-injection, path-injection, request-forgery, sql-injection\nrelated locations: $@.\nmetadata: $@, $@, $@, $@, $@, $@. | Test.java:16:3:16:11 | reference | CallContext | file://java.util.concurrent.atomic:1:1:1:1 | java.util.concurrent.atomic | package | file://AtomicReference:1:1:1:1 | AtomicReference | type | file://false:1:1:1:1 | false | subtypes | file://set:1:1:1:1 | set | name | file://(String):1:1:1:1 | (String) | signature | file://Argument[this]:1:1:1:1 | Argument[this] | input | file://false:1:1:1:1 | false | isVarargsArray | | |||
There was a problem hiding this comment.
Is it intentional that the CallContext for this has become just the reference argument instead of set(...)?
Similar question for the other test cases where the call context changed to just the argument.
Co-authored-by: Jami <57204504+jcogs33@users.noreply.github.com>
There now is a new endpoint class in application mode that mirrors the one we recently added to framework mode. The new class additionally has proper support for vararg arrays.
You'll find some documentation of how the class behaves in the qll file.
The test case in Test.java shows how varargs are treated.
Questions for Reviewers
fyi, @jhelie