Options to secure API

[lee-pai-long]

Is your feature request related to a problem? Please describe.
I used graphql-cop to test my graphql API built using Graphene Django and the result is as follows:

[HIGH] Alias Overloading - Alias Overloading with 100+ aliases is allowed (Denial of Service - /graphql)
[HIGH] Directive Overloading - Multiple duplicated directives allowed in a query (Denial of Service - /graphql)
[HIGH] Field Duplication - Queries are allowed with 500 of the same repeated field (Denial of Service - /graphql)
[LOW] Field Suggestions - Field Suggestions are Enabled (Information Leakage - /graphql)
[MEDIUM] GET Method Query Support - GraphQL queries allowed using the GET method (Possible Cross Site Request Forgery (CSRF) - /graphql)
[HIGH] Introspection - Introspection Query Enabled (Information Leakage - /graphql)
[HIGH] Introspection-based Circular Query - Circular-query using Introspection (Denial of Service - /graphql)
[MEDIUM] POST based url-encoded query (possible CSRF) - GraphQL accepts non-JSON queries over POST (Possible Cross Site Request Forgery - /graphql)

I would like to have options for example to disable or limit use of aliases to prevent Alias Overloading but I can't find options to mitigate this or the other attacks.

Describe the solution you'd like
Is it possible to provide options to mitigate those attacks in a futur version of graphene-django ?

Describe alternatives you've considered
...

Additional context
...

[kiendang]

Is this something that could be solved with a custom ValidationRule? You might want to take a look at #1475.

[lee-pai-long]

Hi @kiendang the instrospection can be solve with that yes, but not the rest.

[kiendang]

I think a few of these, Alias Overloading, Directive Overloading and Field Duplication could be solved by writing a custom ValidationRule that analyses the query.

The CSRF issues could be solved by configuring Django if I'm not wrong.

[lee-pai-long]

@kiendang but how to limit the number of aliases, directives and field in a custom validation rule ?

[kiendang]

I guess you could traverse the AST and count the number of occurrences? See Implementing a custom ValudationRule and the Visitor class.

Anw I'm converting this to a discussion which I think is more appropriate.

[lee-pai-long]

I created a feature request because I think security should be a first class citizen in graphene and graphene django. GraphQL is full of holes and I'm not sure I'm qualified to plug those holes correctly.

For example in JS Apollo server has a set of limits that one can easily configure: https://www.apollographql.com/docs/router/configuration/operation-limits/

[kiendang]

@lee-pai-long I agree that security enhancing features are legitimate requests. However this issue in its original state is under-spec-ed for a feature request. Examples of feature requests that are more actionable would be

• Provide a ValidationRule to limit the number of aliases.
• Provide a ValidationRule to disallow multiple duplicated directives.

There is nothing wrong with your original post, it just didn't yet specify specific things to implement in graphene-django. I just think a discussion would be a better place to spec things out before creating a feature request.

[lee-pai-long]

@kiendang thanks for your answer, ok I understand

[kiendang]

@lee-pai-long thanks for providing references to graphql-cop and Apollo. Looks like it could be worth it to implement some of these as ValidationRule, or at least the alias limit one.

@sjdemartini you mentioned you are looking into validation for your GraphQL app? This could be of interest to you.

Also ValidationRule is part of graphql-core, not Graphene. The Strawberry framework also uses graphql-core underneath and has an extension for specifying ValidationRule as well. It might be best to implement these rules in a separate repo/library without Graphene dependency so that it could be used by both frameworks. Pinging @erikwrede here. We could port the existing depth_limit_validator from Graphene to the new library as well.

[lee-pai-long]

HI @kiendang any idea of when this will be implemented ?

[kiendang]

no timeline at the moment

[lee-pai-long]

Hi @kiendang, any news about implementing this ?

[kiendang]

There's no one actively developing new features at the moment. The maintainers are currently only reviewing PRs, bug fixes.