Vulnerabilities in the Feeld dating app
fortbridge.co.uk
fortbridge.co.uk
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 at large what needs to be done, but getting everyone to apply this consistently is... not so easy.
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.
There’s a point where critical thinking skills come into play, I’ve seen people walked off the premises for doing stuff like this with customer data. Actual seniors who have never been blamed for anything are suddenly intolerable threats to the company because they didn’t bother to check what they were doing and forced the company to disclose a breach.
Sure, part of the responsibility of this is on management, but it's absolutely on the engineers too.
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.
Real engineering is expensive. And hard. moving atoms around is tough. I've never cut stone, but I've melted and cast copper and aluminum. That's real and dangerous work.
Computation is cheap and plentiful. And I kinda like having full control of "stuff". But maybe we do need licensing or personal liability. If I could wave a magic wand, and make that exist, I don't really know what rules I'd put in place.
How do you think people should get skilled up?
You didn't ask me but I can give you my answer: not on prod and with a lot of reviews!
Most users of these sorts of app don't pay enough attention to security to care. Do you really think that most developers are any better?
Most developers are just normal people who happen to be able to write a bit of code and convinced someone to employ them. Just like anyone else, far too many live under the delusion that "it can't happen to me."
Translation: making them eat their own dogfood and risk their own embarrassment won't help; they would have to know better, first! =)
I wonder if there's a market for a "write a CRUD app and let it loose on the Internet and watch it get pwned" simulator/game.
Junior tries something -> hit production
I do not see multiple issues with this.
they were probably thinking what a 10x engineer they'd found to be so rapid at delivery...
What do you even do around here; all you seem to ever do is take darling of products code and make a few changes (which I don't understand) and committing it as your own work. It appears you are either trying to take credit for darling of product or are sabotaging their amazing 10x work.
I'm semi-confident that if a Junior were to talk to another Junior before starting about things to look out for, and then the code was reviewed by say a third Junior, they would not have this bug.
Call me naive, but I don't think Juniors are as oblivious as they are made out to be
If you go up to the counter and yell "10 React devs please", don't be surprised
I have witnessed hiring, listening, and supporting early-career enthusiasm has significantly improved every startup I've had the joy to be a part of.
OPs comparison is great. Bounds checks are easy. There are many overconfident C++ programmers that say they would never introduce a vulnerability like that. But it still happens, because in this class if vulnerabilities it's often enough to forget one check.
I don't see those as the same. Buffer overflow checks are a very specific implementation (and language) detail and can happen absolutely anywhere in a codebase. Permission checks happen at a specific boundary and are related to how you design your application.
Whenever I had any say on how a project was developed, I'd always insist on a clear separation between the development of the backend API and the frontend client code. In my experience, it makes things like this much easier to avoid (and test for). You also get a developer API for "free" (which to be honest, is the main reason I prefer to do it that way).
I flag it whenever I see it, but it is very worrying how little thought is sometimes put into the scope of client APIs.
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.
And while this dating app isn’t well known, it caters to people with different tastes (such as bdsm and group sex) and queer people. Needless to say that this is very sensitive in many parts of the world.
https://www.theguardian.com/technology/article/2024/sep/08/t...
The costs involved with maintaining garbage are infinitely more than maintaining something well built.
This is why software is so lucrative.. because the true cost of the software isn't how much you pay for it .. it's "how much is it going to cost you to change to something else?"
unfortunately trash is cheaper and faster, and it takes a certain kind of genius insanity to sell something well built that doesn't exist yet.
1. Desperate men come in hordes. 2. You will probably get bought out by match group for millions.
Of course there are moral qualms and also it may not be actually just as easy as that.
I have no idea if the back end was also replaced then or if the vulnerabilities were present in the previous version as well.
Of course, the incentives shouldn't promote coverups.
Maybe it's time for an open source federated dating service or something. Or at least something that doesn't sell your data, doesn't leak your nudes, or doesn't get you beaten up/raped/murdered. Probably easier said than done.
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 mass of users in a given area before they’re useful, and monetizing it inevitably means making the app less useful. There’s a reason okcupid went to shit after it stopped being a non-profit.
And then there’s the moderation problem…
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.
This is something that young people especially don't take into account; the potential and probable long term ramifications and embarrassment. Providing such a facility is merely inviting such negative effects.
That, and a bit of embarrassment isn't really all that bad. The problem is that the leaked stuff keeps on circulating :-(
I have a pet theory that seeing more "real" people in the nude is good for your body image. There's a lot less nudity than there was 30 years ago (from movies to locker rooms and everything in between), there's a lot more shame, and everyone is wistfully staring at Instagram garbage.
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.
Before I realised the app was a buggy mess I was very surprised to see it had an interests section that provided no context for the interests. For example: virtually everyone had Domination or Submission as one of their interests but no context whatsoever of which role they wanted. To not realise how fundamentally wrong this is for that scene implies they're clueless across the board.
Messages and private pictures is another matter.
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.
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.
Like if you imagine having junior engs they will be much more likely to make the mistake with GraphQL than otherwise and it is harder to review as well.
The permissions checking becomes a real spaghetti and difficult to understand in practice compared to just one by one checks.
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 GraphQL is very hard to secure against DoS unless you lock it down with query hashes.
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?
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 which loads data, it is necessary to compare the number of permissions checks you would need across the two services. This does not mean resolvers are in any way equivalent to RESTful endpoints except for comparing how many times you'd need to write `ctx.can('read', photo);` across the two, and even then the numbers will almost certainly be different because the APIs will be different.
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.
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.
Having worked with it for a bit over a year now, it really feels like GraphQL is just a different protocol for writing the same old REST CRUD, while introducing a huge framework with lots of annoying magic and language level reflection that isn't amendable to extension or modification according to the needs of the developers.
Is that all worth it, just to reduce the amount of HTTP requests? Is it that much of a sacrilege to add specialized REST HTTP endpoints to remedy that otherwise?
I agree that genericity is often the opposite of specialisation. I disagree that it's a heavy price. REST is pretty general. To my mind specialist APIs are things like streaming video, file uploads, anything that relies on caching in an intermediate layer, etc. and these are all examples of where you'd follow the established standards and add some RESTful routes/services. I don't think it's sacrilege to upload files in a different way to how you load your user dashboard or your interface for editing project permissions.
[1] https://www.apollographql.com/docs/apollo-server/security/au...
[2] https://docs.graphene-python.org/projects/django/en/latest/a...
Between it and Fetlife there's some huge issues with those communities just sticking with the first app that emerges regardless of quality
Or at least, a profit driven company would care about scaring away users.
Is it education problem? If so if there was training budget a day or two running against some simple capture the flag exercise might do a lot...
The Guardian article: https://www.theguardian.com/business/2024/sep/17/dating-app-...
We desperately need a new platform owned and operated by the people, for the people.
Chats? The only IM apps with functional E2EE are: Signal, iMessage, WhatsApp; and even those have trade-offs. Treat everything else as readable by some third party, and dating apps by design need to be able to look into people's chats to be able to handle harassment cases.
That of course is no excuse for having gaping security/privacy holes, but you're trading off quite a bit of privacy by design; it's like meeting in a public space where you can feel a little bit safer with someone you don't know yet.
I'd say if you're concerned with any of that, go meet new people IRL, but there are 100% legitimate cases where this is not the most effective strategy (e.g. Feeld's primary target audience).
Real question: Has WhatsApp ever had a security leak that we know about? Example: Someone can break into accounts, or chats were leaked?
I don't know of any, but I distrust anything Meta/FB/MZ does, out of principle.
I have more trust in iMessage, but it's incredibly tightly tied to Apple's devices (as far as I can tell, part of its security architecture relies on the hardware/SEP).
Signal (as a non-profit org) could have been a neutral third party everyone could feel safe to trust, but they've lost my confidence when they introduced support for cryptocurrencies - I can no longer trust their motives. It also does not offer any choice over some security/usability trade-offs (like syncing your chat history to a new device); I understand this is critical for e.g. whistleblowers, but a deal-breaker for many of the rest of us.
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 attackers remote execution
- At least one huge database dump was released at some point
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.
Pretty sure I flagged something or another as a security issue but can't recall what it was
There are sone public pentests out there. For example https://www.opentech.fund/impact/security-safety-audits/
If you want to read some really hard core security vuln hunting, see https://googleprojectzero.blogspot.com/
Off the top of my head, DoyenSec has some good reports in there targeting web apps
Even with a full redesign/rebuild over the past year it still is nothing but glitchy software.
"BRB going to slaughter everyone my wife has chatted to"
Hard to believe the levels of incompetence here
They have investor funding ... how come no due diligence was done ?
I didn't realise the problems were this bad. They've had massive issues with their tech stack from a user POV. I've multiple times had my phone running incredibly hot while using it.
(Ask me how I know)