38
Root
1y

I'm fixing a security exploit, and it's a goddamn mountain of fuckups.

First, some idiot (read: the legendary dev himself) decided to use a gem to do some basic fucking searching instead of writing a simple fucking query.

Second, security ... didn't just drop the ball, they shit on it and flushed it down the toilet. The gem in question allows users to search by FUCKING EVERYTHING on EVERY FUCKING TABLE IN THE DB using really nice tools, actually, that let you do fancy things like traverse all the internal associations to find the users table, then list all users whose password reset hashes begin with "a" then "ab" then "abc" ... Want to steal an account? Hell, want to automate stealing all accounts? Only takes a few hundred requests apiece! Oooh, there's CC data, too, and its encryption keys!

Third, the gem does actually allow whitelisting associations, methods, etc. but ... well, the documentation actually recommends against it for whatever fucking reason, and that whitelisting is about as fine-grained as a club. You wanna restrict it to accessing the "name" column, but it needs to access both the "site" and "user" tables? Cool, users can now access site.name AND user.name... which is PII and totally leads to hefty fines. Thanks!

Fourth. If the gem can't access something thanks to the whitelist, it doesn't catch the exception and give you a useful error message or anything, no way. It just throws NoMethodErrors because fuck you. Good luck figuring out what they mean, especially if you have no idea you're even using the fucking thing.

Fifth. Thanks to the follower mentality prevalent in this hellhole, this shit is now used in a lot of places (and all indirectly!) so there's no searching for uses. Once I banhammer everything... well, loads of shit is going to break, and I won't have a fucking clue where because very few of these brainless sheep write decent test coverage (or even fucking write view tests), so I'll be doing tons of manual fucking testing. Oh, and I only have a week to finish everything, because fucking of course.

So, in summary. The stupid and lazy (and legendary!) dev fucked up. The stupid gem's author fucked up, and kept fucking up. The stupid devs followed the first fuckup's lead and repeated his fuck up, and fucked up on their own some more. It's fuckups all the fucking way down.

Comments
  • 4
    so.. SNAFU, eh?
  • 0
    Delete it from Sourcecode with the direct notice of security issues.

    If shit Breaks, trigger all hands on Deck to get it globally fixed.
  • 0
  • 1
    @Root oh shit... what a pain...
  • 9
    @Root stop putting up with this "legendary dev" . Publish your findings to the team and mgmt and hammer it on the door like Martin Luther did.
  • 2
    oh deer...
  • 8
    this is why when I design APIs I don't do reusable endpoints. I would rather have 1000 endpoints all made to do one thing and one thing only. Inside their controllers, I write raw DB queries.

    Remember kids, cybersecurity is the field that happens between “what a thing was designed to do” and “what a thing _can_ do”.
  • 0
    Can you just not report it as it is to the company? I mean, it's obviously beyond your responsibility.

    Everyone that used that shit should be responsible for removing it from their codebases.
  • 1
    @Root I shouldn't worry breaking their shit ( If I was on your place... and I've been there although not same situation but actual security breach... ). I'm more amused by their lack of care and the short deadline for such a serious problem
  • 2
    I mean isn't security threats one of the first things a web dev should learn and constantly be aware of? It was when I was moving to the web.
  • 1
    ...or is just me and my passion for safety
  • 2
    @We3D yes
    Still most ppl blindly set .innerHTML to user input and allow SQL injections
    Unless they use libs that are abstracted into oblivion so it's basically impossible to 🤦‍♂️

    I once reported an xss on a website. Instead of fixing the core issue, these clowns add more stupid input filters but the data could be changed from 10 other places without it
    so it's still as vulnerable as before
  • 1
    @devRancid It's puzzling to me b/c it's not like writing new encryption algorithm. It's basic stuff like :

    - restrict the use input to only what is needed ( if possible )
    - always add BE validation ( even if you have FE one for say prevent sumbitting / redirecring )
    - and aways escape before db or displaying

    bonus is if you put few honeypots ( 1 is never enough ) in critical forms to stop the stupid bots and you can sleep good again

    ... And as in Root's case : NEVER trust third party libs to handle your db unless you had tested them and know for sure they are safe to use
  • 2
    @NeatNerdPrime Luther sure did the best shitpost of all times!
  • 2
    Bloody hell I can't believe someone actually purposely created a SQL injection framework in their own codebase.

    I do have a suggestion on how to handle this for you:

    You are not responsible for fixing the usage throughout the company.
    This gaping security hole with the size of a thunder cunt is there for a long time 3 weeks extra doesn't matter.
    So I would suggest a decent open source gem that implements search in a safe way or write one.
    Then security should send out an emergency deprecation notice with a checklist and your exploitation notes. Every Dev in the company should work on fixing this.
  • 0
    @hjk101 The last part should be executed first and if not all devs, the ones that integrated and spread it who knows where should be involved in this if not helping making it how it should be done, at least closing the attack points they know while the solution is cooking and then apply the same when ready. That's too serious problem to leave it to one person, no matter how experienced he/she is
  • 1
    @hjk101 I see a good engineering manager in you. I will hire you someday.
  • 0
    Yeah...

    These people are from Cali. Sense and reason are terrifying to them, and cause them to turn violent.
  • 1
    @Root if only we didn't have this kind of people...
  • 0
    Drink martinis and walk away….
Add Comment