strawberry
strawberry copied to clipboard
strawberry-graphql
Malicious full requests lead to server load and even downtime
At present, how to limit the maximum number of pieces of data returned at a time from the global settings, or it is best to indicate the maximum number of returns without paging in the table to reduce the server load. If an attacker knows grqphql how to query in full or steal data in batch, it will be fatal
Query cost complexity and or maximum query depth is how you solve this problem in general. Strawberry has some extensions to help with that. https://strawberry.rocks/docs/extensions/query-depth-limiter
I think you misunderstood me. I have an operating log system. It has about tens of millions of data. The attacker uses GQL to query all logs, resulting in server downtime
I think you have a design flow by allowing clients to requests all the data. The same issue can be replicated with REST web services if they happen to implement no pagination.
Basically, whenever a given collection is unbounded (= it can have "tens of millions of data"), you should add pagination and add a constraint for the maximum limit value (and that depends on your use case).
You have some examples how to approach the pagination in GraphQL and strawberry here: https://strawberry.rocks/docs/guides/pagination
The piece of advice given by @vamshiaruru-virgodesigns refers to another problem that is more GraphQL specific and you should take that into account as well. Considering how GraphQL works, client can potentially create overly nested query or simply ask for all possible relations the given node have.
Query depth limiter is already provided as an extension. Query cost complexity is not yet implemented as far as I know.
我认为你有一个设计流程，允许客户请求所有数据。如果 REST Web 服务碰巧没有实现分页，则可以使用 REST Web 服务复制相同的问题。
基本上，每当给定的集合是无界的（=它可以有“数千万数据”）时，您应该添加分页并为最大值添加约束（这取决于您的用例）。
limit这里有一些如何在 GraphQL 和 strawberry 中进行分页的示例：https://strawberry.rocks/docs/guides/pagination
@vamshiaruru-virgodesigns 给出的建议指的是另一个更特定于 GraphQL 的问题，你也应该考虑到这一点。考虑到 GraphQL 的工作原理，客户端可能会创建过度嵌套的查询，或者只是询问给定节点具有的所有可能的关系。
查询深度限制器已作为扩展提供。据我所知，查询成本复杂性尚未实现。
If I am a hacker or a competitor of your website, I can delete the limit of GQL, steal data and increase the load of your server and shut down instantly
我认为你有一个设计流程，允许客户请求所有数据。如果 REST Web 服务碰巧没有实现分页，则可以使用 REST Web 服务复制相同的问题。 基本上，每当给定的集合是无界的（=它可以有“数千万数据”）时，您应该添加分页并为最大值添加约束（这取决于您的用例）。
limit这里有一些如何在 GraphQL 和 strawberry 中进行分页的示例：https://strawberry.rocks/docs/guides/pagination @vamshiaruru-virgodesigns 给出的建议指的是另一个更特定于 GraphQL 的问题，你也应该考虑到这一点。考虑到 GraphQL 的工作原理，客户端可能会创建过度嵌套的查询，或者只是询问给定节点具有的所有可能的关系。 查询深度限制器已作为扩展提供。据我所知，查询成本复杂性尚未实现。If I am a hacker or a competitor of your website, I can delete the limit of GQL, steal data and increase the load of your server and shut down instantly
I don't understand? Bot the pagination and depth limit, complexity limit validations are done at server side. The only way to change those limits would be to gain access to that server, and if a hacker has gained access to your server, removing pagination limit is the last thin you have to worry about.
These are not client side stuff that can be changed by anyone.
我认为你有一个设计流程，允许客户请求所有数据。如果 REST Web 服务碰巧没有实现分页，则可以使用 REST Web 服务复制相同的问题。 基本上，每当给定的集合是无界的（=它可以有“数千万数据”）时，您应该添加分页并为最大值添加约束（这取决于您的用例）。
limit这里有一些如何在 GraphQL 和 strawberry 中进行分页的示例：https://strawberry.rocks/docs/guides/pagination @vamshiaruru-virgodesigns 给出的建议指的是另一个更特定于 GraphQL 的问题，你也应该考虑到这一点。考虑到 GraphQL 的工作原理，客户端可能会创建过度嵌套的查询，或者只是询问给定节点具有的所有可能的关系。 查询深度限制器已作为扩展提供。据我所知，查询成本复杂性尚未实现。If I am a hacker or a competitor of your website, I can delete the limit of GQL, steal data and increase the load of your server and shut down instantly
I don't understand? Bot the pagination and depth limit, complexity limit validations are done at server side. The only way to change those limits would be to gain access to that server, and if a hacker has gained access to your server, removing pagination limit is the last thin you have to worry about. These are not client side stuff that can be changed by anyone.
I mean simulating query through requests and removing the limit. All data server response resources for one request will be consumed, which is equivalent to CC attack
If you remove the limit from the query request, server should use the default value or refuse to generate any answer. I really cannot see an issue here.
如果从查询请求中删除限制，则服务器应使用默认值或拒绝生成任何答案。我真的看不出这里有问题。
如果从查询请求中删除限制，则服务器应使用默认值或拒绝生成任何答案。我真的看不出这里有问题。
Yes, at present, our team has patched the request without limit, so that it can return the customized number at will. However, at present, the official has not made a limited API interface, and we hope developers can maintain it.
Ensuring that you do not return too much data has always been a developers' responsibility and strawberry has nothing to do with that. Strawberry is similar to, let's say FastAPI, and it's supposed to be a micro framework that's responsible for GraphQL specific parts only.
The problem you described (not enforcing any limit on data queries) has existed for decades and it's not something this project (not GraphQL itself) introduced. I would compare it to complaining that it's strawberry's fault that you killed your server cause you tried to unarchive a zip-bomb.
Although, I can agree that additional protective measures have to be taken when it comes to GraphQL due to the way queries can be constructed (unless you use so called persistent operations) but it's a different story compared to what you're talking about. These problems are related to the fact that GraphQL queries can be (overly) deeply nested, have recursion (so in theory they can have infinite depth) or ask for too many data at once (reference every possible relationship the given node has). All of these issues are GraphQL-related and there's an issue to track this: https://github.com/strawberry-graphql/strawberry/issues/960