Hacker News Reader

Comment by Cu3PO42 | Hacker News Reader

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.

View on HN

> 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).

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.

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.

right*

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.

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!

People getting paid to create software should know better then these basic mistakes.

than

> 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.

u are wise and right

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.

> who do you blame?

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.

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?

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.

How do you think people should get skilled up?

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

> 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".

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

I don't see how that statement follows mine. Can you connect them at all?

I thought you were making the comparison that a pentester is like a missile shot at a bridge whereas the internet is the army walking over the bridge.

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.

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!

Seems like a solid development cycle.

Junior tries something -> hit production

I do not see multiple issues with this.

Hey, it worked on my machine

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.

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.

Are you my manager

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

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

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.

They didn't ;)

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 feel bad now I'm sorry to the person I replied to lol. I didn't mean 'you' I meant a generalized third party person.

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.

This can happen very easily I think if one uses "automatic db APIs" on the backend. I'm thinking of some automatic graphql setups for example.

I flag it whenever I see it, but it is very worrying how little thought is sometimes put into the scope of client APIs.

This is unfortunately quite common in mobile apps, because "why would a user look closer in a mobile app".

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.

Reply on news.ycombinator.com