Add support for GraphQL

[fzipi]

Summary

While we have support for JSON, there is no explicit support for GraphQL as a content type we can parse.

I think there is enough interest in the community to bring protection to GraphQL, and Coraza should lead this.

References:

• https://graphql.org/
• https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html

Motivation

• Enhanced API protection

Solutions

In this case the solution should focus more on defining first what we think protecting GraphQL means.

There is an existing graphql "armor" solution for nodejs, and this basically implements plugins with protections like https://escape.tech/graphql-armor/docs/category/plugins. Some of the plugins will apply in the request, but others apply at the response level.

This means that whatever we provide, it should come from making variables available in the rule language, so they can be checked with simple "seclang" rules. Or we can follow a different approach. Let's see first what we want to protect users from.

Suggested protections from documentation

• Limiting complexity:

  Depth Limits: Use tools like graphql-depth-limit to specify the maximum depth of queries. For example, you might set a depth limit of 10 to prevent excessively nested queries.

  Complexity Analysis: Calculate the complexity of each query by assigning scores to different operations. For instance, fetching a list of items might have a higher complexity score than fetching a single item. Tools like graphql-query-complexity can help automate this process.

  Cost Analysis: Implement a cost analysis system to evaluate the resource consumption of each query. This involves assigning costs to different types of operations and rejecting queries that exceed a predefined cost threshold.

• Introspection: if introspection is enabled, can we disable its use or we don't have all the information for this?

• Batching Attacks. Can we prevent them?

• Don't Return Excessive Errors. I think this can be done using a simple output rule. Will push this to the CRS community instead.

Let's hear your thoughts first on what should be prevented, then we can think the how.

[fzipi]

@corazawaf/core-developers Thoughts/ideas?

[jptosso]

This is a MUST, there are many articles claiming the reach of GraphQL https://thenewstack.io/graphql-growth-explodes-but-so-do-problems-federated-graphs-solve/
https://github.com/wundergraph/graphql-go-tools This package can be used to unmarshal into an interface, after that we must flatten it into ARGS variables, just as we do with JSON.
Cases to consider:

• Attributes inside query data, what is the syntax?
• Should we automatically push variables into fields? Meaning replace $ID with the ID value