Vulnerabilities in the Feeld dating app • Hacker News Board

Re: Vulnerabilities in the Feeld dating app

#91

Post by tirpen » Thu, Sep 12, 2024, 9:10 AM UTC

itake wrote: post #13

Incipient wrote: post #5

Earlier quoted context omitted.

I think the timeline is the more damaging part too. Not only was their design woefully inadequate, they don't seem to care.

The problem is they probably don’t have full time developers. They probably built the app once years ago via a dev shop and then never updated it again. The talent moved on and updating it is expensive now.

They (or someone they hired) actually rewrote their whole app about a year ago, I remember seeing lots of people complaining about how much worse and buggier it got after the rewrite.

I have no idea if the back end was also replaced then or if the vulnerabilities were present in the previous version as well.

Re: Vulnerabilities in the Feeld dating app

#92

Post by XenophileJKO » Thu, Sep 12, 2024, 9:14 AM UTC

intelVISA wrote: post #73

bugtodiffer wrote: post #49

Earlier quoted context omitted.

Seems like a solid development cycle. Junior tries something -> hit production I do not see multiple issues with this.

9 out of 10 PMs love this one hack to boost velocity they were probably thinking what a 10x engineer they'd found to be so rapid at delivery...

This is so true. I've seen this so many times. The darling of product, who can deliver so fast. They leave a trail of smoking rubble and half working features behind them.

Re: Vulnerabilities in the Feeld dating app

#93

Post by robbie-c » Thu, Sep 12, 2024, 9:15 AM UTC

Cu3PO42 wrote: post #17

dfedbeef wrote: post #15

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.

Sexual preferences and such are special category data, and if you are an engineer dealing with this stuff you should treat it as though data breaches could get someone killed.

Sure, part of the responsibility of this is on management, but it's absolutely on the engineers too.

Re: Vulnerabilities in the Feeld dating app

#94

Post by energy123 » Thu, Sep 12, 2024, 9:16 AM UTC

INTPenis wrote: post #74

wasma wrote: post #68

Who do you trust? Would tinder and bumble have the same mindset?

The for-profit dating scene is a quagmire. Sure it can work, I've seen it work, but at what cost? We desperately need a new platform owned and operated by the people, for the people.

The Tokyo government is trying that: https://www.cnbc.com/2024/06/07/japan-pushes-citizens-toward...

Re: Vulnerabilities in the Feeld dating app

#95

Post by pistoleer » Thu, Sep 12, 2024, 9:23 AM UTC

robertlagrant wrote: post #86

pistoleer wrote: post #70

Earlier quoted context omitted.

That's hiring a pen tester, and there is a market for it, but companies don't do it as much as they should because it costs money while the app already "works" and brings in revenue. Of the 3 I've worked at, only one had yearly pen tests done.

No one hires someone to test what happens when a bridge is shot with a missile from 6000 miles away. The bridge "works" in the same way that the software "works".

A software penetration tester has the same techniques and suite of tools for pwning as "the internet".

Re: Vulnerabilities in the Feeld dating app

#96

Post by floating-io » Thu, Sep 12, 2024, 9:33 AM UTC

jfoutz wrote: post #44

ifdefdebug wrote: post #39

Earlier quoted context omitted.

yeah now imagine another engineer go "my first bridge just fell apart the first time a real truck tried to cross over it lol" or "man my first plane crashed so hard"...

Ya know, the Roman tradition was, you gotta stand under the bridge while the army marches over it. If it collapses, you die too. Maybe there's something to having nudes of that dev. 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 co…

> Maybe there's something to having nudes of that dev.

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! =)

Re: Vulnerabilities in the Feeld dating app

#97

Post by pistoleer » Thu, Sep 12, 2024, 9:37 AM UTC

strken wrote: post #36

marcus_holmes wrote: post #32

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…

How do you guys bridge the abstraction gap/wall between resolvers to prevent N+1 queries? I have the suspicion that GraphQL is great for exposing a really generic API, useful when you have no idea what shape the front end will take (how often is that?). But it comes at a heavy price; genericity is always the opposite of specialization. And optimization can only occur during specialization.

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?

Re: Vulnerabilities in the Feeld dating app

#98

Post by Klonoar » Thu, Sep 12, 2024, 9:42 AM UTC

Anybody who's ever used this app is probably not surprised to hear this. It's been a shitshow since day one, one of the buggiest apps I think I've ever used.

Even with a full redesign/rebuild over the past year it still is nothing but glitchy software.

Re: Vulnerabilities in the Feeld dating app

#99

Post by elric » Thu, Sep 12, 2024, 9:56 AM UTC

The online dating space (I use the term liberally) is a huge fucking mess. There's only 2 or 3 companies with an offering that is anywhere near useful, and they're either evil, incompetent, or both.

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.

Re: Vulnerabilities in the Feeld dating app

#100

Post by poincaredisk » Thu, Sep 12, 2024, 9:58 AM UTC

dfedbeef wrote: post #15

Cu3PO42 wrote: post #7

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…

You shouldn't be touching the server-side code if you find this hard to keep straight.

I work in security and I don't trust myself to tie my shoes correctly every day.

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.