I was hoping that at the end of each section, there would be the actionable items to do / fix, but it seems they're all sort of handled at the end of the article, which was a bit jarring.
I get your point. As I'm solving many issues with the same solution, I thought it would work well to split problems and solutions into two separate sections. I can understand where you're coming from though. Thanks for the feedback!
Well since the “solution” is to simply use their SaaS… then they have to wait to the end of the article in order to maintain maximum tension so their marketing pitch will land.
It’s a good article overall though, and I admit I am tempted by their offer… but it’s still a pitch.
What's wrong with it being a pitch? The article shows how some problems and then offers a solution to those problems. How would you tell someone about your solution without it being a pitch?
It is hard not to interpret the recommendation at the end of this article – which is to wrap your GraphQL API in a locked down JSON-RPC API - as an argument for not using GraphQL at all.
I think the article does a disservice to itself by casually adding in things like "SQL injection" and a few other issues that are really not unique to GraphQL. A more concise article that only touches on the issues that are GraphQL specific would be welcome.
Beyond that, I find the authorization sections unconvincing. As someone who's spent quite a bit of time thinking about authorization in GraphQL APIs, I think that the only viable option for authorization in GraphQL is node level authorization, especially if using the relay convention. You're forced to write every authorization check as a function of the relationship between the user and the subject at hand and it avoids accidentally leaking information (which is also issue with REST APIs that do authorization at the controller level, à la https://news.ycombinator.com/item?id=25728175).
OK, this entire article was just completely bizarre IMO:
1. A bunch of the points at the top had to do with writing your own GraphQL parser. I don't disagree this is a complicated task, or that some libraries have implementation bugs, but GraphQL has certainly been around long enough that there are some hugely popular, battle-tested server implementations available. I'm not arguing those implementations are 100% bug-free, but they certainly have tons of eyes on them and are in widespread active development.
2. Many of the bugs have nothing to do with GraphQL. SQL injection or URL path injection are possible everywhere (hint, use a library like slonik that makes it easy to write SQL that looks like string concatenation but actually makes it virtually impossible to have a SQL injection bug).
3. Many of the other bugs are either standard IDOR-type bugs, again possible in any framework, or that arise from a potentially recursive type definition. Yes, if you have different permissions applied at different levels of a recursive hierarchy, you need to be very careful about how those permissions are applied.
4. In contrast to this article, I find GraphQL to be a dream from a security perspective precisely because it is strongly typed. E.g. I define many custom scalar types that I use for inputs that guarantee that by the time I see a value that it is already validated so it can't cause an injection attack. For example, suppose you know all your identifiers are alphanumeric. Just define an AlphaNumericString custom scalar type and you know then that many types of injection attacks would be impossible.
I was surprised there was no mention of whitelisting.
If I know the queries that client apps are going to be running it would be useful to lock the API down to those. It sacrifices flexibility, but if you control apps and server, e.g. a startup then you still get the benefit of flexibility in development. Just need a system of add to the whitelist before deployment.
I have been looking for a way to achieve this with graphene but looks like there isn't a library for that yet. I'm wonder if other platforms offer this?
I've been wanting this for years and have been tempted to write it myself.
I've imagined a way to create your graphql query in a UI then "bookmark" it.
After that you'd grant permissions to use that bookmark via some authentication system. Possibly via a security team or API team to review the implications of the query. Security, performance, etc.
So you get fast and flexible development but you have a minimal surface area when refactoring, auditing security, and monitoring potential performance issues.
One other thing that's useful is for reaching out to the appropriate team to discuss deprecation, security concerns, and new upcoming features.
The team that needs to improve the database (in some way) can quickly figure out who to talk to instead of needing to ask multiple teams "hey, we're thinking about X, does that affect you?" The other teams are often busy and it takes time to analyze their code to figure out if it would affect them. It can be a miserable and slow process. With a bookmark, it's obvious and straightforward.
If anyone is familiar with something along these lines I'd love to hear about it.
The proposed solution does exactly what you describe in the first part. By turning GraphQL Operations into an RPC endpoint, we've essentially whitelisted the Operation. We've not only whitelisted the Operation but added a whole lot more but obviously I don't want to repeat the article. If you're interested discussing this further, find my contact information at the end of the blogpost.
> If we search the same source for the birth of GraphQL, we can see, it's Sep 2014, around 7 years old.
GraphQL is a little older than that. It was initially developed at Facebook in 2012. It says as much on the graphQL website right on the main page: https://graphql.org
What is meant by operation validation here? (I'm not familiar with graphql)
edit: according to most explanations it's about catching accesses to nonexistent fields, cycles, and other things you'd like a nice error message from - would be interesting to hear some security relevant cases.
16 comments
[ 2.0 ms ] story [ 46.7 ms ] threadLeaves me skeptical, especially since they don't talk about good design or dealing with authorization through the resolving process.
I would expect a "complete guide" to take many hours to read
It’s a good article overall though, and I admit I am tempted by their offer… but it’s still a pitch.
I implemented some of the measures mentioned here - such as execution limits - in my datasette-graphql plugin: https://datasette.io/plugins/datasette-graphql#user-content-...
Beyond that, I find the authorization sections unconvincing. As someone who's spent quite a bit of time thinking about authorization in GraphQL APIs, I think that the only viable option for authorization in GraphQL is node level authorization, especially if using the relay convention. You're forced to write every authorization check as a function of the relationship between the user and the subject at hand and it avoids accidentally leaking information (which is also issue with REST APIs that do authorization at the controller level, à la https://news.ycombinator.com/item?id=25728175).
1. A bunch of the points at the top had to do with writing your own GraphQL parser. I don't disagree this is a complicated task, or that some libraries have implementation bugs, but GraphQL has certainly been around long enough that there are some hugely popular, battle-tested server implementations available. I'm not arguing those implementations are 100% bug-free, but they certainly have tons of eyes on them and are in widespread active development.
2. Many of the bugs have nothing to do with GraphQL. SQL injection or URL path injection are possible everywhere (hint, use a library like slonik that makes it easy to write SQL that looks like string concatenation but actually makes it virtually impossible to have a SQL injection bug).
3. Many of the other bugs are either standard IDOR-type bugs, again possible in any framework, or that arise from a potentially recursive type definition. Yes, if you have different permissions applied at different levels of a recursive hierarchy, you need to be very careful about how those permissions are applied.
4. In contrast to this article, I find GraphQL to be a dream from a security perspective precisely because it is strongly typed. E.g. I define many custom scalar types that I use for inputs that guarantee that by the time I see a value that it is already validated so it can't cause an injection attack. For example, suppose you know all your identifiers are alphanumeric. Just define an AlphaNumericString custom scalar type and you know then that many types of injection attacks would be impossible.
If I know the queries that client apps are going to be running it would be useful to lock the API down to those. It sacrifices flexibility, but if you control apps and server, e.g. a startup then you still get the benefit of flexibility in development. Just need a system of add to the whitelist before deployment.
I have been looking for a way to achieve this with graphene but looks like there isn't a library for that yet. I'm wonder if other platforms offer this?
After that you'd grant permissions to use that bookmark via some authentication system. Possibly via a security team or API team to review the implications of the query. Security, performance, etc.
So you get fast and flexible development but you have a minimal surface area when refactoring, auditing security, and monitoring potential performance issues.
One other thing that's useful is for reaching out to the appropriate team to discuss deprecation, security concerns, and new upcoming features. The team that needs to improve the database (in some way) can quickly figure out who to talk to instead of needing to ask multiple teams "hey, we're thinking about X, does that affect you?" The other teams are often busy and it takes time to analyze their code to figure out if it would affect them. It can be a miserable and slow process. With a bookmark, it's obvious and straightforward.
If anyone is familiar with something along these lines I'd love to hear about it.
GraphQL is a little older than that. It was initially developed at Facebook in 2012. It says as much on the graphQL website right on the main page: https://graphql.org
edit: according to most explanations it's about catching accesses to nonexistent fields, cycles, and other things you'd like a nice error message from - would be interesting to hear some security relevant cases.