131–140 of 150 posts
(This is a throwaway account but I've been on HN for a decade) I just read this and attempted to delete mine and my partners profile data. The process is currently totally broken in-app. There is no way to proceed past a certain point. There's nothing self-identifying about us in the app but still.... I'm furious.
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.
And do you have any reason at all to believe the backend people didn't know? They wrote a fair amount of code and infrastructure, so they cannot have been blank slates.
This is utterly horrifying, clearly absolutely zero thought was put into security at all. I'm a game developer and we put more effort into keeping our game fair than this company does in keeping it's users safe. They should be sued into oblivion.
Messages and private pictures is another matter.
Earlier quoted context omitted.
The permissions checking is one-by-one checks. It's exactly as hard a mistake to make in GraphQL as it is in REST unless you've got more resolvers than an equivalent REST app would have, which is unlikely and would mean GraphQL wasn't a good choice. I do think that you've got a good point about how the knowledge isn't widespread yet, that it's easier for frontend engineers to write awful expensive queries, and that G…
> The permissions checking is one-by-one checks Not true, authorization can be done in middleware. You can deny requests automatically, even scenarios you never considered.
You can do the equivalent of applying middleware at a routing level in GraphQL by wrapping multiple resolvers, although the semantics will be different because you're not working with a tree of routes and so you'll need to group your resolvers together in some other way. In the Node.js libraries a resolver is just a function, so you can very easily wrap a bunch of them in another function:
// auth.js
export const checkParent = (permission, fn) => (parent, args, ctx) => {
ctx.can(permission, parent); // CASL
return fn(parent, args, ctx);
};
// resolvers.js
import * as auth from './auth';
export const resolvers = {
// could also iterate over all the resolvers within User using Object.entries and apply auth.checkParent if you wanted
User: {
photoURLs: auth.checkParent('read', (parent, _, ctx) => {
return parent.getSignedPhotoURLs();
}),
},
Query: {
user: async (_, { id }, ctx) => {
const user = await ctx.db.users.getById(id);
ctx.can('read', user);
return user;
},
},
};
Yes, this stuff is slightly different, but it's genuinely not that hard to secure a GraphQL API.
Earlier quoted context omitted.
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.
So if someone who can't drive, finds a car with the keys in it, and starts driving it, and causes an accident, who do you blame? And do you have any reason at all to believe the backend people didn't know? They wrote a fair amount of code and infrastructure, so they cannot have been blank slates.
The people who hired the person who can't drive and gave them a job as a driver.
> do you have any reason at all to believe the backend people didn't know?
Well, either they knew and wanted to implement proper auth and were prevented from doing it, or they knew and couldn't be bothered, or they didn't know that their backend system wasn't properly locked down and were too incompetent to have a clue.
Earlier quoted context omitted.
Lots of great points in your post. Real question: Has WhatsApp ever had a security leak that we know about? Example: Someone can break into accounts, or chats were leaked?
> Real question: Has WhatsApp ever had a security leak that we know about? Example: Someone can break into accounts, or chats were leaked? Yes, a bunch of them. I don't remember any of the years, but from the top of my head: - Pegasus was installable via Whatsapp calls that didn't need to be installed, probably the most famous vulnerability with the largest impact - Bunch of multimedia vulnerabilities that allowed at…
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…
I want to blame juniors, the no-code and ai-code crowd, but I'm as lazy as they are and will just shake my head and move on.
Earlier quoted context omitted.
I’ve been conceptualizing one for a few years, but just don’t have the free dopamine to build it alongside my day job. ActivityPub even has the mechanics to facilitate it through publishing Person records. There is MASSIVE space for innovation, especially if you prioritize on non-monogamy, non-heterosexual, non-gender-conforming needs. Dating apps are a REALLY hard space to get into, however. You need a cumulative ma…
Now you've piqued my interest, especially if it could be done in a safe but distributed way, without a focus on profits. How you'd envision it to work, considering the open nature of ActivityPub but the need/want from the users to remain private when using dating applications/protocols?
For messaging, I hadn’t put a much thought into it, but one could establish end to end encryption based on mutual validation signatures. Theoretically. Encryption isn’t my strong suit, but as long as the encoded body is unicode, it’s just as easy to transmit as any other text.
But, like, I also don’t know of any dating site that professes to be encrypting message contents.
Earlier quoted context omitted.
Wouldn't it seem contra to the principles of GraphQL if you treat resolvers like rest endpoints? At this point, it's just RPC, no? It's not really a graph. Why didn't I just use RPC/Rest the whole time?
You don't treat resolvers like RESTful endpoints. You check that the user has permission to access the object (edit: or other value) which the resolver returns. This has nothing to do with RPC and does not stop you using the "graph" part of GraphQL. For the purposes of comparing a REST API, where permissions checking is done for every endpoint, to a GraphQL API, where permissions checking is done for any resolver whi…
Earlier quoted context omitted.
You don't treat resolvers like RESTful endpoints. You check that the user has permission to access the object (edit: or other value) which the resolver returns. This has nothing to do with RPC and does not stop you using the "graph" part of GraphQL. For the purposes of comparing a REST API, where permissions checking is done for every endpoint, to a GraphQL API, where permissions checking is done for any resolver whi…
The problem is the 'graph' nature of the system; you can check the permission for the object that the resolver returns but that object might be linked to another object that you're not checking for. Because anything can just link to anything, you would have to recursively check the permissions of the entire graph.
If the root query lets you query a user of type User, and the User object embeds an array photos of type [Photo], then there are two possibilities: either the resolver for user is loading the photos and letting the default resolver return them, in which case you know about it and can check permissions for them, or there's a resolver defined for photos, in which case you can check permissions in that second resolver.
Think about it. GraphQL won't go retrieve rows from your database without either a) you installing some other library to do the magic, in which case we should talk about that library instead, or b) you telling it to query your database, in which case you know what data you're querying in each resolver you write and can check that the user has permission to see it.