Shulou(Shulou.com)05/31 Report--

This article introduces you how to carry out GraphQL analysis, the content is very detailed, interested friends can refer to, hope to be helpful to you.

Say what you said before.

The following divides the content according to some conceptual features in GraphQL that are easy for beginners to confuse or misunderstand with typical Web API (for ease of understanding, the following takes the popular RESTful API as an example). From a security point of view, I put forward several security issues that GraphQL should pay attention to, while @ Tounan will give more of his best practices summarized in practical use from the perspective of development.

In addition, it needs to be announced in advance that the back-end development language I use in this article is Go,@ Tounan using Node.js, and the front end is unified as React (GraphQL client is Apollo). Please digest it yourself.

Let's Go!

Introduction to GraphQL

Have some students never heard of this thing at all? Let's first take a look at the big customers who are using it:

Is it worth taking us a few minutes to get a simple understanding of it? XD

What is GraphQL?

To put it simply, GraphQL is a query language for API created and open source by Facebook.

Then quote the official copywriter to help you understand the characteristics of GraphQL:

1. Ask for the data you want, no more, no less.

Send a GraphQL request to your API to get exactly the data you want, no more, no less. GraphQL queries always return predictable results. Applications that use GraphQL can work quickly and steadily because it is the application, not the server, that controls the data.

two。 Get multiple resources with only one request

GraphQL query can not only obtain the attributes of resources, but also further query along the references between resources. Typical RESTful API requests multiple resources to load multiple URL, while GraphQL can get all the data you need for your application with a single request.

3. Describe all possibilities, type systems

GraphQL is organized based on types and fields, not entry endpoints. You can get all your data capabilities through a single entry endpoint. GraphQL uses types to ensure that the application requests only the possible data and provides clear auxiliary error messages.

Core components of GraphQL

1.Type

There are two abstract data models used to describe interfaces: Scalar (scalar) and Object (object). Object is made up of Field, while Field has its own Type.

2.Schema

Used to describe the logic used by the interface to get data, analogous to each individual resource URI in RESTful.

3.Query

There are three types of queries used to describe interfaces: Query (query), Mutation (change), and Subscription (subscription).

4.Resolver

Used to describe the parsing logic of each Query in the interface, some GraphQL engines also provide fine-grained Resolver of Field (for students who want to know more, please read the official GraphQL documentation).

GraphQL VS. RESTful

GraphQL does not rely too much on the HTTP protocol and has its own parsing engine to help the front and back end use GraphQL query syntax. At the same time, it is a single-route form, and the query content depends entirely on the front-end request objects and fields, and the front and back ends are separated obviously.

Compare it with a picture:

Improper identity authentication and authority control

@ gyyyy:

As mentioned earlier, GraphQL adds an intermediate layer to perform syntax parsing and other operations on the query language it defines. Unlike RESTful, which makes full use of the characteristics of the HTTP protocol to complete the declaration, various definitions such as Schema and Resolver will make developers more aware of its existence and indirectly increase the complexity of understanding it, plus its own single routing form. It is easy to cause developers to mistakenly implement or even ignore the authorization and authentication behavior when calling API without fully understanding its features and internal running mechanism.

In the official description, GraphQL, like RESTful API, recommends that developers delegate authorization logic to the business logic layer:

If the Query and Mutation in GraphQL are not authenticated properly, attackers may illegally request to some unexpected interfaces to perform high-risk operations, such as querying the details of all users:

Query GetAllUsers {users {_ id username password idCard mobilePhone email}}

This is almost a security problem that can not be avoided by using any API technology, because it does not have much to do with the function of API itself, API does not need to bear the burden, but the complications caused by this problem should not be underestimated.

Information disclosure

For this kind of unauthorized or unauthorized access vulnerability mining and exploitation, we must be very clear, in general, we will expect to get as much API as possible for further analysis. In RESTful API, we may need to crawl API through proxy, crawler and other technologies. With the arrival of the era of Web 2.0, various powerful front-end frameworks, runtime DOM event updates and other technologies are used more frequently, which makes us have to use technologies such as Headless to improve the access coverage of API.

But unlike RESTful API, GraphQL comes with a powerful introspection and self-test mechanism, which can directly obtain all the interface information defined by the backend. For example, query all available objects through _ _ schema:

{_ _ schema {types {name}

Query all fields of the specified object through _ _ type:

{_ _ type (name: "User") {name fields {name type {name}}

Here, through the source code of graphql-go/graphql, I will briefly analyze the parsing execution process and introspection mechanism of GraphQL to help you deepen your understanding:

After getting the request parameters of HTTP, the 1.GraphQL routing node creates a Params object and calls Do () to complete the parsing and execute the operation to return the result:

Params: = graphql.Params {Schema: * h.Schema, RequestString: opts.Query, VariableValues: opts.Variables, OperationName: opts.OperationName, Context: ctx,} result: = graphql.Do (params)

two。 After calling Parser () to convert params.RequestString into an AST document of GraphQL, give AST and Schema together to ValidateDocument () for verification (mainly to verify whether it conforms to the parameters, fields, types, etc., defined by Schema).

3. Replace the AST to re-encapsulate the ExecuteParams object and pass it into Execute () to start the execution of the current GraphQL statement.

The specific implementation details will not be carried out, but where is the introspection that we are concerned about? Originally, when the GraphQL engine initialized, three meta-fields with the default Resolver were defined:

SchemaMetaFieldDef = & FieldDefinition {/ / _ _ schema: query the schema of the current type definition No parameter Name: "_ schema", Type: NewNonNull (SchemaType), Description: "Access the current type schema of this server.", Args: [] * Argument {}, Resolve: func (p ResolveParams) (interface {}, error) {return p.Info.Schema, nil} } TypeMetaFieldDef = & FieldDefinition {/ / _ _ type: query the details of the specified type String type parameters name Name: "_ _ type", Type: TypeType, Description: "Request the type information of a single type.", Args: [] * Argument {{PrivateName: "name", Type: NewNonNull (String),},} Resolve: func (p ResolveParams) (interface {}, error) {name, ok: = p.Args ["name"]. (string) if! ok {return nil, nil} return p.Info.Schema.Type (name), nil},} TypeNameMetaFieldDef = & FieldDefinition {/ / _ typename: query the current object type name No parameter Name: "_ typename", Type: NewNonNull (String), Description: "The name of the current Object type at runtime.", Args: [] * Argument {}, Resolve: func (p ResolveParams) (interface {}, error) {return p.Info.ParentType.Name (), nil},}

When resolveField () resolves to a meta field, its default Resolver is called, triggering GraphQL's introspection logic.

Automatic binding (unexpected and obsolete fields)

In order to consider the downward compatibility of interfaces during version evolution, GraphQL also has a more friendly feature for application development: "API evolution does not need to be versioned."

Since GraphQL sends back data based on the fields requested by the frontend, the response of the backend Resolver contains the corresponding fields, so the expansion of backend fields has no effect on the frontend, and the query fields in the frontend only need to be within the range of fields defined by the backend. At the same time, GraphQL also provides an "obsolete" scheme for field deletion, such as the DeprecationReason attribute added to the field by Go's graphql package, the @ deprecated logo of Apollo, and so on.

This feature is very convenient to separate the front and back end, but if the developer's own security awareness is not strong enough, the design of the API is not reasonable, it will bury a lot of security risks. Let's recreate the requirements scenarios that we may often encounter in the development project.

Suppose Xiaoming has defined the API to query the basic information of the user in the application:

Graphql.Field {Type: graphql.NewObject (graphql.ObjectConfig {Name: "User", Description: "user Information", Fields: graphql.Fields {"_ id": & graphql.Field {Type: graphql.Int}, "username": & graphql.Field {Type: graphql.String}) "email": & graphql.Field {Type: graphql.String},},}), Args: graphql.FieldConfigArgument {"username": & graphql.ArgumentConfig {Type: graphql.String},}, Resolve: func (params graphql.ResolveParams) (result interface {}, err error) {/ /.},}

Xiaoming gets a new description of the requirements. "the administrator can query the details of the specified user". For convenience (and often for convenience), several fields have been added to the original interface:

Graphql.Field {Type: graphql.NewObject (graphql.ObjectConfig {Name: "User", Description: "user Information", Fields: graphql.Fields {"_ id": & graphql.Field {Type: graphql.Int}, "username": & graphql.Field {Type: graphql.String}) "password": & graphql.Field {Type: graphql.String}, / / add user password field "idCard": & graphql.Field {Type: graphql.String}, / / add user ID number field "mobilePhone": & graphql.Field {Type: graphql.String} / / add the field "email": & graphql.Field {Type: graphql.String},},}), Args: graphql.FieldConfigArgument {"username": & graphql.ArgumentConfig {Type: graphql.String},}, Resolve: func (params graphql.ResolveParams) (result interface {}) Err error) {/ /...},}

If Xiao Ming does not control the fine granularity of the fields at this time (and ignores other permission issues for the time being), attackers can easily find these fields that should not be seen by ordinary users through introspection, and construct a request for query (some test fields are often left behind in actual development, which is undoubtedly very dangerous in front of GraphQL's powerful introspection mechanism. If you are familiar with Spring auto-binding vulnerabilities, you will also find some similarities between them.

The story goes on, when Xiaoming finds that this is not the right thing to do, he decides to abandon these fields:

/ /... "password": & graphql.Field {Type: graphql.String, DeprecationReason: "Security issues"}, "idCard": & graphql.Field {Type: graphql.String, DeprecationReason: "Security issues"}, "mobilePhone": & graphql.Field {Type: graphql.String, DeprecationReason: "Security issues"}, / /.

Then, he used the above _ _ type to do introspection. Good, the discarded field could not be found, the front end was notified to roll back the query statement, the problem was solved, and he went home from work (the advantage of GraphQL was immediately highlighted).

Students who are familiar with security attack and defense routines know that many attacks (especially in Web security) take advantage of the knowledge blind spots of development, testing, and operation and maintenance (if you want to ask the cause of these blind spots, I can only say that they are not used at all under normal circumstances, so they will not be deliberately concerned without in-depth research). If developers do not read the GraphQL official documentation carefully, especially the introspection section, they may not know that obsolete fields can still be exposed by specifying the includeDeprecated parameter to true,__type:

{_ _ type (name: "User") {name fields (includeDeprecated: true) {name isDeprecated type {name}}

And because Xiao Ming did not change the Resolver, the discarded fields can still participate in the query normally (the disaster caused by compatibility), and the story ends.

As p Niu said, "GraphQL is a technology that comes with its own documentation." But this also makes the security risk of the application behind GraphQL much greater than that of typical Web API if there is a mistake in authorization and authentication.

@ Tunan:

GraphQL does not stipulate any authentication and permission control, which is a good thing, because we can be more flexible in the application to achieve various granularity of authentication and permissions. However, in the process of my development, I found that beginners often ignore the authentication of GraphQL and write some streaking interfaces or interfaces with invalid authentication. Then I will talk about the authentication method of GraphQL in detail here.

Independent authentication terminal (RESTful)

If the backend supports RESTful or has a dedicated authentication server, you can authenticate the GraphQL interface by modifying a small amount of code. This kind of authentication is the most general and officially recommended.

Take JWT authentication as an example, add the entire GraphQL route to JWT authentication, and open two RESTful interfaces for login and registration. The specific logic of login and registration is no longer described. Return JWT Token after login:

After the setting is completed, the request GraphQL API needs to be logged in first, and then the authentication request header is configured at the frontend to access the GraphQL API, and the curl is used instead of the frontend request to log in to the RESTful API:

Curl-X POST http://localhost:4000/login-H 'cache-control: no-cache'-H 'content-type: application/x-www-form-urlencoded'-d'username=user1&password=123456' {"message": "login succeeded", "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkYXRhIjp7Il9pZCI6IjViNWU1NDcwN2YyZGIzMDI0YWJmOTY1NiIsInVzZXJuYW1lIjoidXNlcjEiLCJwYXNzd29yZCI6IiQyYSQwNSRqekROOGFQbEloRzJlT1A1ZW9JcVFPRzg1MWdBbWY0NG5iaXJaM0Y4NUdLZ3pVL3lVNmNFYSJ9LCJleHAiOjE1MzI5MTIyOTEsImlhdCI6MTUzMjkwODY5MX0.Uhd_EkKUEDkI9cdnYlOC7wSYZdYLQLFCb01WhSBeTpY"}

To replace the frontend request GraphQL API with GraphiQL (GraphQL developer debugging tool, which is included with most GraphQL engines and enabled by default), you need to set the authentication request header:

Authentication within GraphQL

If the GraphQL backend can only support GraphQL but not RESTful, or if all requests need to use GraphQL, you can also use GraphQL to construct the login interface to provide Token.

As in the following example, the Query Schema of login is constructed, and the Token is carried in the return value:

Type Query {login (username: String! Password: String!): LoginMsg} type LoginMsg {message: String token: String}

Provide login logic in Resolver:

Import bcrypt from 'bcryptjs'; import jsonwebtoken from' jsonwebtoken'; export const login = async (_, args, context) = > {const db = await context.getDb (); const {username, password} = args; const user = await db.collection ('User'). FindOne ({username: username}) If (await bcrypt.compare (password, user.password)) {return {message: 'Login success', token: jsonwebtoken.sign ({user: user, exp: Math.floor (Date.now () / 1000) + (60 * 60), / / 60 seconds * 60 minutes = 1 hour} 'your secret'),} }}

After the login is successful, we continue to set the Token in the request header and request other interfaces of the GraphQL. At this point, we need to configure ApolloServer as follows:

Const server = new ApolloServer ({typeDefs: schemaText, resolvers: resolverMap, context: ({ctx}) = > {const token = ctx.req.headers.authorization | |'; const user = getUser (token); return {. User,... ctx,... app.context} },)

Implement the getUser function:

Const getUser = (token) = > {let user = null; const parts = token.split (''); if (parts.length = 2) {const scheme = parts [0]; const credentials = parts [1]; if (/ ^ Bearer$/i.test (scheme)) {token = credentials Try {user = jwt.verify (token, JWT_SECRET); console.log (user);} catch (e) {console.log (e);} return user}

Once ApolloServer is configured, verify user in Resolver:

Import {ApolloError, ForbiddenError, AuthenticationError} from 'apollo-server'; export const blogs = async (_, args, context) = > {const db = await context.getDb (); const user = context.user; if (! user) {throw new AuthenticationError ("You must be logged in to see blogs");} const {blogId} = args; const cursor = {} If (blogId) {cursor ['_ id'] = blogId;} const blogs = await db .collection ('blogs') .find (cursor) .sort ({publishedAt:-1}) .toArray (); return blogs;}

In this way, we have completed the main code that has passed the GraphQL certification. Continue to use GraphiQL instead of the front-end request GraphQL login interface:

After you get the Token, set the Token to the request header to complete the subsequent operation. If the request header fails, you will not get the data:

Authority control

During the authentication process, we simply identify whether the request is initiated by a legitimate user. Permission control allows us to assign different view and operation permissions to the user. As mentioned above, we have put user into the context of GraphQL Sever. The content of context is controllable, so the user in context can be either {loggedIn: true} or {user: {_ id: 12345, roles: ['user',' admin']}}. You should know how to implement permission control in Resolver. Let's give a simple example:

Users: (root, args, context) = > {if (! context.user | |! context.user.roles.includes ('admin')) throw ForbiddenError ("You must be an administrator to see all Users"); return User.getAll ();} GraphQL injection

@ gyyyy:

Where there is grammar, there will be parsing, where there is parsing, there will be structure and order, and if there is structure and order, there will be injection.

The front end uses variables to build query statements with parameters:

Const id = props.match.params.id; const queryUser = gql` {user (_ id: ${id}) {_ id username email}} `

The value of name is concatenated into the complete GraphQL statement before the GraphQL query request is issued. An attacker injects malicious statements into name:

-1) 7B_id%7Dhack%3Auser (username%3A "admin") 7Bpassword%23

Maybe the structure of the GraphQL statement has been changed:

{user (_ id:-1) {_ id} hack: user (username: "admin") {password #) {_ id username email}}

Therefore, the parameterized query must ensure that when the back-end GraphQL engine parses, the structure of the original statement remains unchanged, and the parameter values are passed in the form of variables, which are assigned and parsed by the parser in real time.

@ Tunan:

Fortunately, GraphQL provides both "parameters" and "variables" for our use. We can transfer the stitching process of parameter values to the back-end GraphQL engine, and the front end is like a parameterized query.

For example, we define a Query with variables:

Type Query {user (username: String!): User}

Pass in variables when requesting:

Query GetUser ($name: String!) {user (username: $name) {_ id username email}} / / variable {"name": "some username"} denial of service

@ gyyyy:

Students who have done code debugging may have noticed that when there are interrelated objects in the observed variables, you can expand them infinitely (such as some Request-Response pairs of Web frameworks). If the association is not a reference but a value, it is possible that problems such as OOM may lead to a decline in computing performance or even an interruption in application operation. By the same token, this kind of problem exists in some dynamic evaluation logic, such as XXE's denial of service.

Nesting relationships between objects including combinations are also allowed in GraphQL, and if the nesting depth is not limited, it will be exploited by attackers to carry out denial of service attacks.

@ Tunan:

In development, we may often encounter such requirements:

1. Query all articles and return content containing author information

two。 Query the author information and return all the articles written by this author.

Of course, these two interfaces must be used separately in the front end we developed, but attackers can use their inclusion relationships to make nested queries.

As an example below, we define Blog and Author:

Type Blog {_ id: String! Type: BlogType avatar: String title: String content: [String] author: Author #...} type Author {_ id: String! Name: String blog: [Blog]}

Build their own Query:

Extend type Query {blogs (blogId: ID systemType: String!): [Blog]} extend type Query {author (_ id: String!): Author}

We can construct the following query, which can be looped indefinitely and may cause a denial of service attack:

Query GetBlogs ($blogId: ID, $systemType: String!) {blogs (blogId: $blogId) SystemType: $systemType) {_ id title type content author {name blog {author {name blog {author { Name blog {author {name blog {author { Name blog {author {name Blog {author {name blog { Author {name # and so on... }} }}} } title createdAt publishedAt}} publishedAt}}

To avoid this problem, we need to limit the query depth on the GraphQL server and try to avoid such problems when designing the GraphQL interface. Still take Node.js as an example, graphql-depth-limit can solve this problem.

/ /... Import depthLimit from 'graphql-depth-limit'; / /... Const server = new ApolloServer ({typeDefs: schemaText, resolvers: resolverMap, context: ({ctx}) = > {const token = ctx.req.headers.authorization |'; const user = getUser (token) Console.log ('user',user) return {... user,... ctx,... app.context};}, validationRules: [depthLimit (10)]}); / /.

After adding the limit, if the request depth is too deep, you will see the following error message:

It's just an interface.

@ gyyyy:

As a member of Web API, GraphQL, like RESTful API, may be affected by attackers to backend applications by injecting malicious data into parameters, resulting in security problems such as XSS, SQL injection, RCE and so on. In addition, many features of GraphQL have also been mentioned above, which can be used by attackers to optimize the attack process or even enhance the attack effect in some special scenarios. For example, the introspection mechanism mentioned earlier and the GraphiQL debugging tool enabled by default, and it supports both GET and POST request methods, which will provide more convenience for the exploitation of these vulnerabilities in CSRF.

Of course, some features also provide partial protection, but only "partially".

@ Tunan:

GraphQL's type system is a natural barrier to injection, but if developers do not handle it correctly, there will still be exceptions.

For example, in the following example, the parameter type is a string:

Query GetAllUsers ($filter: String!) {users (filter: $filter) {_ id username email}}

If the backend does not perform any security check on the value of filter, directly query the database and pass in a SQL statement string, which may constitute SQL injection:

{"filter": "'or''='"}

Or the JSON string forms the NoSQL injection:

{"filter": "{\" $ne\ ": null}"}

GraphQL is really just an API technology that provides a new and convenient solution for the front and back end of API connections. In any case, the authentication should be done on the authentication, the verification data must be verified.

This is the end of the analysis on how to carry out GraphQL. I hope the above content can be helpful to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.