For example, you might want the response to contain only the names of available mutations. Like regular queries, you can specify the fields and structure of the response you want to be returned when running an introspection query. This field is available on the root type of all queries. To use introspection to discover schema information, query the _schema field. It can also disclose potentially sensitive data, such as description fields. Introspection helps you to understand how you can interact with a GraphQL API. Introspection is a built-in GraphQL function that enables you to query a server for information about the schema. The best way to do this is to use introspection queries. The next step in testing the API is to piece together information about the underlying schema.
Product ID 3 is missing from the list, possibly because it has been delisted.īy querying the ID of the missing product, we can get its details, even though it is not listed on the shop and was not returned by the original product query. The product list returned contains only listed products.įrom this information, we can infer the following: For further information on IDORs, see Insecure direct object references (IDOR).įor example, the query below requests a product list for an online shop:. For a general explanation of GraphQL arguments, see Arguments. This is sometimes known as an insecure direct object reference (IDOR). A user could potentially access information they should not have simply by supplying an argument that corresponds to that information. If the API uses arguments to access objects directly, it may be vulnerable to access control vulnerabilities. Testing query arguments is a good place to start. If the endpoint is powering a website, try exploring the web interface in Burp's browser and use the HTTP history to examine the queries that are sent.Īt this point, you can start to look for vulnerabilities. Once you have discovered the endpoint, you can send some test requests to understand a little more about how it works. If you can't find the GraphQL endpoint by sending POST requests to common endpoints, try resending the universal query using alternative HTTP methods. However, some endpoints may accept alternative methods, such as GET requests or POST requests that use a content-type of x-www-form-urlencoded. It is best practice for production GraphQL endpoints to only accept POST requests that have a content-type of application/json, as this helps to protect against CSRF vulnerabilities. The next step in trying to find GraphQL endpoints is to test using different request methods. You should bear this in mind when testing for GraphQL endpoints. GraphQL services will often respond to any non-GraphQL request with a "query not present" or similar error. If these common endpoints don't return a GraphQL response, you could also try appending /v1 to the path. When testing for GraphQL endpoints, you should look to send universal queries to the following locations: GraphQL services often use similar endpoint suffixes. The query works because every GraphQL endpoint has a reserved field called _typename that returns the queried object's type as a string. This is known as a universal query, and is a useful tool in probing whether a URL corresponds to a GraphQL service. If you send query somewhere in its response. 
It raises a "GraphQL endpoint found" issue if any such endpoints are discovered. However, Burp Scanner can automatically test for GraphQL endpoints as part of its scans.
GRAPHQL FRAGMENTS HOW TO
This section explains how to probe for GraphQL endpoints manually.
0 kommentar(er)
