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 at large what needs to be done, but getting everyone to apply this consistently is... not so easy.
> 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.
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).
Junior developer probably opened a Jira ticket, saw a UI of a permission dialog, and did exactly that task with nobody senior enough to know better. That's how you reproduce the bugs that were in-fashion 15 - 20 years ago in my experience!
There two new front end guys in the team, understaffed backend, but manageable, nothing as dramatic, but I constantly have to remind the benefits of doing as much things as possible in the backend and keep the logics high level on the front is aggravating.
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
As a long time engineering manager, I have significantly benifited from this: leveling me up in WCAG/ADA, strcmp timing attacks, performance timing. Many managers start younger than we maybe should, and the burnout that I had in my early years pulled me out of my passion to learn more about comp sci. It was the random enthusiasm of younger folk that, in those times, was my exposure to topics I hadn't dived in to yet.
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.
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.
Why can't you be more like darling of product over there.
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.
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.
> I also try to make it a habit to not blame people for not knowing something
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.
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.
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.
Yeah, the people who put those people into the position to touch server side code are to blame. But then the OP is right: the people having made these code changes should really not have touched anything server side or even anything security relevant in the beginning.
They shouldn't have to - the architecture should be made in such a way that permission checks are done without you specifically having to call them every time. This is the entire reason middleware exists!
Well, but apparently they let people create the architecture who just shouldn't have touched the backend code. That's the whole point. Since it was not just a single endpoint or so - it was everywhere!
I agree they should just quit but that requires experience to understand too. By the time they've learned that, they have also learned that client-side access controls are decorative.
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.
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 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.
> 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! =)
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.
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".
Oh, I see. No, the missile is a hacker attacking your software remotely. Bridges are just accepted that they will collapse if deliberately attacked by a determined attacker. Software is held to a higher standard, not a lower one.
Yet after decades of this messaging, we still have these people touching the server-side code. Is it likely another few years of the same messaging will fix it?
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.
I once caught a webdev doing frontend authentification with a plain javascript dialog. Yes, simple! Put the password in the JS, and do a simple comparison. Why did I notice? Because the owner of the lamp account contacted me that all their data was suddenly gone. Checked the logs, and yep, Google Bot clicked all the "Delete" links in their internal management view. Simply because JavaScript is opt-in :-) Called the developer and educated him on what he just did. I lost a lot of trust in web people that day.
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.