On Tue, Nov 19, 2019 at 3:38 PM Ashera Silva <[email protected]> wrote:
> Hi all,
>
> GraphQL gave rise to complex security implications as the server is no
> longer in control, the client is, and this flexibility comes at a cost. To
> overcome this hardship, the query needs to be analyzed before execution.
> Without any protection to the backend, we'll be vulnerable to DoS attacks
> (due to excessive load to the server, database or network), which are
> caused by the execution of malicious and complex queries that are passed
> either intentionally or unintentionally. Given below are the solutions put
> forward for static query analysis within the API Manager.
>
> My project is to add fine-grained access control to GraphQL APIs. After
> the initial project discussion, the main features suggested for the static
> query analysis part is:
> 1. Query depth limitation
> 2. Query complexity limitation
>
> *1. QUERY DEPTH LIMITATION*
> Through this feature, we try to avoid nested queries that grow
> exponentially. This is simply done by limiting the number of nested loops a
> query can have. When this maximum query depth is reached the request will
> be blocked.
>
> After the initial plan, the idea was to maintain a max_depth value which
> indicates the maximum depth a given query can reach. Once the request is
> analyzed, we can obtain the depth of the query, if this depth exceeds the
> max_depth value, the query will be blocked and will never reach the
> backend. On the other hand, if the depth is not exceeded the request will
> not be blocked.
>
> Although this was the initial idea, where every role/user gets the same
> depth limitation so as to prevent complex queries reaching the GraphQL
> backend, having the same depth limitation for all user role types (admin,
> Internal/publisher, etc.) is not fair. Each role should not be treated
> equally as some should have the ability to query more complex queries than
> the rest. As a result, a suggestion was made to "*add role-specific max
> depth limitation*". Here a local entry would contain these details given
> below.
>
>
>
>
>
>
> *{ max_depth { admin_role: 10, subscriber_role: 5 }}*
>
> For this to be the case, we needed a way to access the user who is
> invoking the GraphQL API, so that we would know that user's associated role
> at the gateway level. There onwards, we can use the local entry mapping to
> know the depth limitation value for that particular request. A suggestion
> was put forward to add a scope like property so that we can assign that to
> any role and at the time of access token generation, we can assign these
> scope like properties. From this approach, we would be able to use the
> scope to role mapping and the role to max_depth mapping(from local entry
> policy) so as to have a max_depth value in order to block malicious
> queries. This approach was suggested as we did not have the role of the
> user who is invoking the API within the GraphQLAPIHandler.
>
> But after the latest meeting we had, the proposed solution to include
> scopes to do the fine-grained access control was rejected. The conclusion
> was to add a new handler only for GraphQL APIs after the
> APIAuthenticationHandler so that we would have access to the roles of the
> user who is invoking the API. So now, we can easily get the max_depth value
> for any given request by accessing the roles and thereby getting the
> relevant max_depth values and picking the maximum out of all allocated
> max_depth values. Once the max_depth value is known we can block malicious
> queries. And this was a simpler solution when compared with the scope
> related approach.
>
@Ashera Silva <[email protected]> I think we will need to explain why we
cannot use scopes here because most common question everyone asks is why we
cannot use scope. As i remember requirement of attaching scope to resource
is one reason(but in this case access control need to apply in API level).
Thanks,
sanjeewa.
>
> *2. QUERY COMPLEXITY LIMITATION*
>
> Here we analyze the query complexity before execution. Each field is given
> a score based on the individual complexity factor (default is 1), where the
> summation of all scores will lead to the complexity value of that
> particular query. If the query complexity is higher than the previously
> provided maximum, the query will be rejected. These complexity values which
> are allocated per field are to be maintained within the same local entry as
> shown below.
>
>
>
>
>
>
>
>
>
>
>
>
>
> *{ complexity { max_complexity: 1000,
> custom_complexity_values { type1: { field1:
> 1, field2: 5 }, type2:
> { field1: 2, field2: 2 }*
> * }*
> * }*
> *}*
>
> Here we would maintain these depth-related and complexity-related values
> per API. These policy related details will be appended to the existing
> local entry which is maintained per API after encoding with base64. Then at
> the gateway level, we can read these API level policies and analyze the
> query and thereby block malicious queries.
>
> Thanks
> Ashera
>
> On Tue, Nov 19, 2019 at 12:32 PM Hiranya Abeyrathne <[email protected]>
> wrote:
>
>> On Tue, Nov 19, 2019 at 12:21 PM Hiranya Abeyrathne <[email protected]>
>> wrote:
>>
>>> Hi Ashera,
>>>
>>> Agreed with @Sanjeewa Malalgoda <[email protected]> and @Uvindra Dias
>>> Jayasinha <[email protected]> Suggestions.
>>>
>>> @Ashera Silva <[email protected]>, Please update the ticket [1]
>>> including the approach that we are going to follow. IMO, also it is better
>>> to use scope approach instead of the roles as one scope can be attached to
>>> multiple roles,
>>> then the management of the policies becomes easy for API developers. We
>>> can do something like @Sanjeewa <[email protected]> explained at the
>>> API level using the swagger that we have stored for Graphql APIs.
>>>
>>
>> But due to its complexities we discussed at the meeting, we moved to a
>> role-based approach, @Ashera Silva <[email protected]> please add those
>> details here clearly that you mentioned in the meeting notes and open this
>> discussion to the public.
>>
>>
>>> [1] https://github.com/wso2/product-apim/issues/5432
>>>
>>> Thanks!
>>> Hiranya Abeyrathne
>>> Software Engineer,
>>>
>>> *WSO2, Inc. *
>>>
>>> lean. enterprise. middleware
>>> Mob: +94 70210 8657
>>> LinkedIn: https://www.linkedin.com/in/hiranya-kavishani/
>>>
>>> <http://wso2.com/signature>
>>>
>>>
>>> On Tue, Nov 19, 2019 at 11:36 AM Uvindra Dias Jayasinha <
>>> [email protected]> wrote:
>>>
>>>> @Ashera Silva <[email protected]>
>>>> , noticed that this thread is private. We need to discuss this on
>>>> [email protected] so that we can get wider feedback from the
>>>> community. Since we cannot share google docs on public threads, better to
>>>> give an inline overview of the design in the body of the mail itself.
>>>> <[email protected]>
>>>>
>>>> Might be a good idea to link to this[1] as well. There was a lot of
>>>> interest shown by the community regarding this so we should be able to get
>>>> some good feedback.
>>>>
>>>> [1] https://github.com/wso2/product-apim/issues/3184
>>>>
>>>> On Mon, 4 Nov 2019 at 11:56, Sanjeewa Malalgoda <[email protected]>
>>>> wrote:
>>>>
>>>>> I feel its good to define policies outside API definition and link
>>>>> them with scopes. It will work in JWT and OAuth scenarios without issue.
>>>>> However when it comes to basic auth there will be small issue as no direct
>>>>> scope information comes from that. But we can check resource scopes(roles)
>>>>> and cross check them with user roles. Then if role matching worked then
>>>>> consider scopes to retrieve policies for graphQL. Main reason behind this
>>>>> is usually roles reside outside API Management system. If we are to define
>>>>> something global for all resources within API then we can have something
>>>>> like API level scope which is attribute of API. Then we can pass that to
>>>>> handler while publishing API. Thoughts?
>>>>>
>>>>> Thanks,
>>>>> sanjeewa.
>>>>>
>>>>> On Fri, Nov 1, 2019 at 5:31 PM Ashera Silva <[email protected]> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> My project is to add fine-grained access control to GraphQL APIs.
>>>>>> After the initial project discussion, the main features suggested for the
>>>>>> static query analysis part is:
>>>>>> 1. query depth limitation
>>>>>> 2. query complexity limitation
>>>>>>
>>>>>> When considering the "query depth limitation", my implementation so
>>>>>> far provides a maximum query depth value. When the query from the GraphQL
>>>>>> request exceeds this limit, the query is blocked, thereby malicious
>>>>>> queries
>>>>>> can be identified before they hit the GraphQL server. But this value is
>>>>>> common for all users. This is not fair, as different roles should be
>>>>>> given
>>>>>> different limitations. The suggestion that is proposed is to give a
>>>>>> role-specific maximum depth limitation.
>>>>>>
>>>>>> Please refer to the google doc attached herewith for reference in
>>>>>> detail.
>>>>>>
>>>>>> https://docs.google.com/document/d/1lsO-c9ajHs7Ru3bjApLUwrJNv4eaVZ-yVJUZNMG-ADU/edit?usp=sharing
>>>>>>
>>>>>> Your feedback with this regard is highly appreciated.
>>>>>>
>>>>>> --
>>>>>> *Ashera Silva* | Engineering - Intern | WSO2 Inc.
>>>>>> Mobile : +94702547925 | Email : [email protected]
>>>>>>
>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Sanjeewa Malalgoda*
>>>>> Software Architect | Associate Director, Engineering - WSO2 Inc.
>>>>> (m) +94 712933253 | (e) [email protected] | (b) Blogger
>>>>> <http://sanjeewamalalgoda.blogspot.com>, Medium
>>>>> <https://medium.com/@sanjeewa190>
>>>>>
>>>>> GET INTEGRATION AGILE <https://wso2.com/signature>
>>>>> Integration Agility for Digitally Driven Business
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Uvindra
>>>>
>>>> Mobile: 777733962
>>>>
>>>
>
> --
> *Ashera Silva* | Engineering - Intern | WSO2 Inc.
> Mobile : +94702547925 | Email : [email protected]
>
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>
--
*Sanjeewa Malalgoda*
Software Architect | Associate Director, Engineering - WSO2 Inc.
(m) +94 712933253 | (e) [email protected] | (b) Blogger
<http://sanjeewamalalgoda.blogspot.com>, Medium
<https://medium.com/@sanjeewa190>
GET INTEGRATION AGILE <https://wso2.com/signature>
Integration Agility for Digitally Driven Business
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
