Comment by makr17
6 days ago
Years ago I worked for a company that bought another company. Our QA folks were asked to give their site a once-over. What they found is still the butt of jokes in my circle of friends/former coworkers.
* account ids are numeric, and incrementing
* included in the URL after login, e.g. ?account=123456
* no authentication on requests after login
So anybody moderately curious can just increment to account_id=123457 to access another account. And then try 123458. And then enumerate the space to see if there is anything interesting... :face-palm: :cold-sweat:
I did some work ~15 years ago for a consulting company. The company pushes their own custom opensource cms into most projects - built on top of mongodb and written by the ceo. He’s a lovely guy, and good coder. But he’s totally self taught at programming and he has blind spots a mile wide. And he hates having his blind spots pointed out. He came back from a react conference once thinking the react team invented functional programming.
A friend at the company started poking around in the CMS. Turns out the login system worked by giving the user a cookie with the mongodb document id for the user they’re logged in as. Not signed or anything. Just the document id in plain text. Document IDs are (or at least were) mostly sequential, so you could just enumerate document IDs in your cookie to log in as anyone.
The ceo told us it wasn’t actually a security vulnerability. Then insisted we didn’t need to assign a CVE or tell any of our customers and users. He didn’t want to fix the code. Then when pushed he wanted to slip a fix into the next version under the cover of night and not tell anyone. Preferably hidden in a big commit with lots of other stuff.
It’s become a joke between us too. He gives self taught programmers a bad rep. These days whenever I hear a product was architected by someone who’s self taught, I always check how the login system works. It’s often enlightening.
I'm self taught and have worked on several auth systems... I've seen plenty of bad ones from professional programmers with Masters degrees. So it definitely can go both ways.
I've also have spent 10-15 hours a week beyond work assignments on reading/experimenting, etc. in terms of honing my craft/skills over the course of three decades. Most devs don't do that much consistently in general though.
Being self-taught isn't the problem. I've self-taught myself 10x more than I learned in school (and yes I was CS in school).
A person who is like that is rarely called a "lovely person": how does that lovely interaction look like when you point such an egregious flaw out to them?
And tbh, this has nothing to do with being self-taught: by the time I enrolled in CS program, I was arguably self-taught and could spot issues like this myself. But I pride myself in learning from my mistakes and learning fast.
So it's more likely a character thing: if you are willing to admit when you are wrong, you'll learn much faster!
You might as well make them sequential if they're numeric, making them non-sequential just puts more load on your server when the brute force happens.
Agreed, the lack of per request auth, and a single exposed record as a raw cookie for auth are pretty egregious.
I did once have a system that started with a incremental sequence was 17, then the number was passed through a reversible obfuscation to get a 6+ character output ID... it wasn't that bad, was an inspection record for a vehicle entry... meant to be able to be shared and looked up by anyone with the sequence (semi-public), it was desired to be short, and it just moved the guess-ability factor slightly.