Stack Overflow (Criteria.parse) with JsonPath about dgs-framework HOT 8 CLOSED

from dgs-framework.

Correct me if I'm wrong, but as far as I understand the issue wouldn't be exposed through DGS. We don't take user input directly that goes through JsonPath. It's only when using the DgsQueryExecutor, for example in tests, where a developer uses the APIs backed by jsonpath.

Once there is a patch for the library we'll update it, but I don't think there's any action to take now.

from dgs-framework.

That's good to hear. I did notice however, that after fully excluding the dependency it does cause NoClassDefFoundError: com/jayway/jsonpath/Configuration, so it used outside of tests too.

java.lang.NoClassDefFoundError: com/jayway/jsonpath/Configuration
	at com.netflix.graphql.dgs.client.GraphQLResponse.<clinit>(GraphQLResponse.kt:131)
	at com.netflix.graphql.dgs.client.WebClientGraphQLClient.handleResponse(WebClientGraphQLClient.kt:146)
	at com.netflix.graphql.dgs.client.WebClientGraphQLClient.access$handleResponse(WebClientGraphQLClient.kt:42)
	at com.netflix.graphql.dgs.client.WebClientGraphQLClient$reactiveExecuteQuery$3.invoke(WebClientGraphQLClient.kt:136)
	at com.netflix.graphql.dgs.client.WebClientGraphQLClient$reactiveExecuteQuery$3.invoke(WebClientGraphQLClient.kt:136)
	at com.netflix.graphql.dgs.client.WebClientGraphQLClient.reactiveExecuteQuery$lambda$3(WebClientGraphQLClient.kt:136)
	...
Caused by: java.lang.ClassNotFoundException: com.jayway.jsonpath.Configuration
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:525)

But I agree, looking at what's happening in GraphQLResponse, this is not the same as seen in that issue.

I'll convey the message as I was just forwarding the question from client.

from dgs-framework.

If it's only used for test, why is the dependency not scoped for test in maven/gradle? I think if that can still be done, it should not be flagged anymore by Nexus IQ.

from dgs-framework.

@ntenherkel But it isn't used only in test as my stack trace showed. The dependency is used in production code too. Maybe the path to that issue as stated in JsonPath isn't used in production code, but JsonPath itself is used outside test.

from dgs-framework.

Yes let me rephrase my suggestion. @paulbakker is it possible for the netflix developers to scope this dependency to test? Based on Martin's comment that would also mean some adjustments in the dgs-framework java/kotlin logic.

My feeling is that json-path is not playing an important role in the dgs-framework. The end result having a dependency less (that is poorly maintained, CVE already open for weeks with no sight on a fix) in the jar, is also worth the attempt if you ask me.

from dgs-framework.

I do fully agree with that. If that would be possible, that would be a nice solution.

from dgs-framework.

JsonPath is used in two places:

1. DgsQueryExecutor - to parse out parts of a query from the result. This is typically used for testing. However it's part of the main API, so it should not be a test only dependency. I'm not too worried about it though, because there is no way for an outside user (someone sending a query) to specify the json path.
2. The DGS client that you use to call other GraphQL services. That's the stacktrace @martinvisser posted. This could be a problem if you would take user input and pass that on directly as the jsonpath argument.

Like SQL injection, this issue is only a problem if user input is used directly to form the jsonpath argument, which we don't do in the framework itself. We can't make JsonPath a a test-only dependency, but I don't see how the CVE would affect a DGS in general.

from dgs-framework.