81–90 of 150 posts
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.
I'm not terribly surprised. I use it but would describe it as incompetently put together as my bank app? maybe worse, it barley functions at all. I dont know how they managed it.
It was so bad when I used it, if it wasn't bizarre memory leak or privacy issues it was extremely poorly executed UX. Between it and Fetlife there's some huge issues with those communities just sticking with the first app that emerges regardless of quality
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...
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…
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.
Earlier quoted context omitted.
That's an interesting idea. Bridge builders and flight sims are used in industry to test to see if a bridge design will fail or if a plane will crash. They're not limited to oversimplified and fun video games. 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.
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.
Earlier quoted context omitted.
It was so bad when I used it, if it wasn't bizarre memory leak or privacy issues it was extremely poorly executed UX. Between it and Fetlife there's some huge issues with those communities just sticking with the first app that emerges regardless of quality
Given the overlap between those communities and OSS people I’m amazed no one has created a B Corp that does this stuff right.
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.
People getting paid to create software should know better then these basic mistakes.
Earlier quoted context omitted.
Also no review or planning anywhere in that process. 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
I should add this works best if you hire with some diversity, such as one Junior with a preference for security topics. 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.
Earlier quoted context omitted.
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…
Still I think this type of thing is much more likely to happen with GraphQL including various N + 1 and even worse performance issues. 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.