31–40 of 150 posts
interesting read - anyone have pointers to other app pentesting walk throughs like this?
I wrote up finding some of these issues entirely independently: https://mjg59.dreamwidth.org/70061.html
GraphQL allows your front-end to query your data. Which is cool. But from the backend this is all really opaque (and usually implemented by a 3rd party library that has no idea about your access control).
Unless you're going to implement your access control in the database itself (not the worst idea, certainly better than doing it in the front end), then it's very hard to unwrap the GraphQL query in backend code to work out exactly what records should be returned/restricted.
Implementing decent access control in the backend means understanding the query and implementing a whole set of models/classes/functions/whatever that grok the database schema and can make decisions about "if the user_id is XXX then it can/cannot see this image in this context" [0]. They obviously implemented this in the front end because that's a lot easier with GraphQL.
I'm not saying this is a good implementation of GraphQL and that therefore the problem lies with GraphQL exclusively. I'm saying that GraphQL makes this mistake easier to make because it explicitly tries to remove the need for the backend to understand the query and so makes this kind of complex security situation harder.
[0] e.g. a specific image may be publicly accessible from the user's profile, or only available to matches, or only in a chat context (but not group chats), and inaccessible at any time from blocked users, etc. You can easily come up with a bunch of complex edge cases for just this one case.
God damn it. People deserve better than this. Almost inclined to take a pay cut to go and fix this mess.
However little you're willing to take they can hire a less competent person cheaper.
Or at least, a profit driven company would care about scaring away users.
Earlier quoted context omitted.
I wrote up finding some of these issues entirely independently: https://mjg59.dreamwidth.org/70061.html
So the question is -- how many others knew about this and were exploiting it without discussing it? :(
https://www.theguardian.com/technology/article/2024/sep/08/t...
Hot take: this is a problem with GraphQL. GraphQL allows your front-end to query your data. Which is cool. But from the backend this is all really opaque (and usually implemented by a 3rd party library that has no idea about your access control). Unless you're going to implement your access control in the database itself (not the worst idea, certainly better than doing it in the front end), then it's very hard to unw…
You don't need to touch the AST or understand the context of the rest of the query. Just answer the question "can user ABC see the photos of user XYZ?" in the resolver that fetches the photos. If this is inefficient then prefetch some data or use a dataloader.
Now, if you're using some magic library that turns GraphQL into SQL, that's going to be different.
It seems like they implemented permission checks purely in the frontend, and not just on one endpoint, but almost everywhere. While it is conceptually easy to avoid this, I have seen similar mistakes much more frequently than I would like to admit. Edit: the solution "check all permissions on the backend" reminds me of the solution to buffer overflows: "just add bounds checks everywhere". It's clear to the community…
Hot take: this is a problem with GraphQL. GraphQL allows your front-end to query your data. Which is cool. But from the backend this is all really opaque (and usually implemented by a 3rd party library that has no idea about your access control). Unless you're going to implement your access control in the database itself (not the worst idea, certainly better than doing it in the front end), then it's very hard to unw…
It's pretty easy. Treat each resolver that retrieves data like it's a REST endpoint and secure it, and add a query allowlist that you append items to during your CI builds. You don't need to touch the AST or understand the context of the rest of the query. Just answer the question "can user ABC see the photos of user XYZ?" in the resolver that fetches the photos. If this is inefficient then prefetch some data or use…
Earlier quoted context omitted.
You shouldn't be touching the server-side code if you find this hard to keep straight.
Eternal September. Everyone starts somewhere, it’s just all the time now. In ten years, the dev will explain to a junior how bad they messed up, and why they have to validate this way. Well, I don’t know, but that’s what I hope.
Earlier quoted context omitted.
You shouldn't be touching the server-side code if you find this hard to keep straight.
Ultimately, I don't disagree. However, I also try to make it a habit to not blame people for not knowing something. This presents as a structural problem in that company: they needed to hire people who do know how to secure server code and put them into a position to do so. Blame the company and those who decided to save every last penny in personnel cost.