Is there a way to configure a limit on alias overloading to protect against DoS attacks?

[oliemansm]

I couldn't find any documentation on how to configure limits on alias overloading to defend against Denial of Service attack as described here: https://checkmarx.com/blog/alias-and-directive-overloading-in-graphql/.

The closest thing I could find is the instrumentation in this PR, which appears to be providing the necessary functionality. Not sure if this is really limited to alias overloading or if it's actually broader than that?

I've added this for now to our project, since this seems to increase security. Would be nice to have more documentation and built-in security for this in the core library though.

[bbakerman]

graphql-java has quite a few limits you can set. While not "alias" overloading specific, they do aim to prevent this style of attack.

At the parser level we have

graphql.parser.ParserOptions

/**
     * A graphql hacking vector is to send nonsensical queries with large tokens that contain a repeated characters
     * that burn lots of parsing CPU time and burn memory representing a document that won't ever execute.
     * To prevent this for most users, graphql-java sets this value to 1MB.
     * ANTLR parsing time is linear to the number of characters presented.  The more you
     * allow the longer it takes.
     * <p>
     * If you want to allow more, then {@link #setDefaultParserOptions(ParserOptions)} allows you to change this
     * JVM wide.
     */
    public static final int MAX_QUERY_CHARACTERS = 1024 * 1024; // 1 MB

    /**
     * A graphql hacking vector is to send nonsensical queries with lots of tokens that burn lots of parsing CPU time and burn
     * memory representing a document that won't ever execute.  To prevent this for most users, graphql-java
     * sets this value to 15000.  ANTLR parsing time is linear to the number of tokens presented.  The more you
     * allow the longer it takes.
     * <p>
     * If you want to allow more, then {@link #setDefaultParserOptions(ParserOptions)} allows you to change this
     * JVM wide.
     */
    public static final int MAX_QUERY_TOKENS = 15_000;
    /**
     * Another graphql hacking vector is to send large amounts of whitespace in operations that burn lots of parsing CPU time and burn
     * memory representing a document.  Whitespace token processing in ANTLR is 2 orders of magnitude faster than grammar token processing
     * however it still takes some time to happen.
     * <p>
     * If you want to allow more, then {@link #setDefaultParserOptions(ParserOptions)} allows you to change this
     * JVM wide.
     */
    public static final int MAX_WHITESPACE_TOKENS = 200_000;

    /**
     * A graphql hacking vector is to send nonsensical queries that have lots of grammar rule depth to them which
     * can cause stack overflow exceptions during the query parsing.  To prevent this for most users, graphql-java
     * sets this value to 500 grammar rules deep.
     * <p>
     * If you want to allow more, then {@link #setDefaultParserOptions(ParserOptions)} allows you to change this
     * JVM wide.
     */
    public static final int MAX_RULE_DEPTH = 500;

This is the first and most important stage - limit how much work the query parser will do.

You can use graphql.analysis.MaxQueryDepthInstrumentation and graphql.analysis.MaxQueryComplexityInstrumentation to create more specific "depth and complexity" limits.

There is another attack vector that was recently discovered and thats crafted introspection queries that can exploded how how many fields need to be executed.

Some people like to disable introspection in production (I am not a fan but you can)

graphql-java ships with graphql.introspection.GoodFaithIntrospection on by default and it will ensure that the introspection query is such that the "field explosion" trick can not work.

Its also has limits on how deep the introspection query can be (even aide from the field explosion trick)

    /**
     * This is the maximum number of executable fields that can be in a good faith introspection query
     */
    public static final int GOOD_FAITH_MAX_FIELDS_COUNT = 500;
    /**
     * This is the maximum depth a good faith introspection query can be
     */
    public static final int GOOD_FAITH_MAX_DEPTH_COUNT = 20;