Programmer Humor

I've had legacy systems that would encrypt user passwords, but also save the password confirmation field in plain text. There was a multitenent application that would allow front end clients to query across any table for any tenant, if you knew how to change a header. Oh and an API I discovered that would validate using "contains" for a pre-shared secret key. Basically if the secret key was "azh+37ukg", you could send any single individual character like "z" and it would accept the request.

Shits focked out here, mate.

I'm not going to share it here because it's code I've written. I'm hiding in my own shame

Our CFO's social security number, contact info, and just about everything you'd need to impersonate them inside a random shell script that was being passed around like drugs at a party for anyone to use. Oh and it had an API key to our payments processor hard coded into it.

That was the tip of the iceberg of how bad the systems were at the company. All of these are from the same company:

• A fintech based company with no billing team
• An event system that didn't event
• A permissions system that didn't administer permissions
• A local cache for authentication sessions. Which means that requests would intermittently fail auth because the session was only on one replica. If you hit any of the other ones, you'd get an unauthenticated error
• A metrics collection system that silently lost 90% of it's data
• Constant outages due to poorly designed and implemented systems (and lack of metrics... hmmm)
• Everything when I joined was a single gigantic monolith that was so poorly implemented they had to run at least 3 different versions of it in different modes to serve different use cases (why the fuck did you make it a monolith then?!)
• The subscriptions system was something like 20 or 30 database tables. And they were polymorphic. No one could touch the system without it breaking or that person declaring failure, which leads me to ...
• A database schema with over 350 tables, many of which were join tables that should have been on the original table (fuck you scala/java for the limitations to the number of fields you can have in a case class). Yes you read that right. Table A joined to table B just to fill in some extra data that was 1:1 with table A. Repeat that a few dozen times
• History tables. Not separate from the original table, but a table that contained the entire history of a given piece of data. The worst example was with those extraneous join tables I just mentioned. If you went and changed a toggle from true to false to true to false, you'd have 4 records in the same table. One for each of those small changes. You'd have to constantly try to figure out what the 'latest' version of the data was. Now try joining 5 tables together, all of them in this pattern.
• Scala... I could go on a tirade about how bad scala is but needless to say, how many different error handling mechanisms are there? Scala decided to mix all of them together in a blender and use them all together. Scala is just two white paper languages in a trenchcoat. Never use it in a production system
• A dashboard for "specialists" that was so easy to overwhelm that you could do it by breathing on it due to the LACK of events that it needed
• Passwords stored in plain text (admittedly this was in the systems of the company we acquired while I was there). Doesn't matter if they were actually , they were visible in a dashboard accessible by employees. Might as well have been plain text
• A payments system that leaked it's state into a huge part of the rest of the system. The system ended up being bifurcated across two systems, I was brought in to try to clean up some of the mess after only a couple of months. I desperately tried to get some help because I couldn't do it solo. They ended up giving me the worst engineer I've ever worked with in my 15 year career, and I've seen some bad engineers. Looking back, I'm reasonably confident he was shoving our codebase into an AI system (before it was approved/secured, so who knows who had access) and not capable of making changes himself. I could make several posts about this system on its own
• I could go on but I'll cut it off there

Whatever is happening in Monster Hunter Wilds.

I worked for a mid-sized government entity where we handled PII data. Underneath us were local municipalities who were in charge of sending us that PII so that it could be registered at our level. For PII think licenses, IDs, sensitive stuff for sure.

Most of the municipalities were easy to work with, they did an SFTP drop or used a VPN or something.

A couple though were rural. Very rural, and didn't have IT departments. They had Martha who works the counter from 1-4pm. Those places were... horrid. We had a special email where they would email us whatever formats they had. Unencrypted, completely open, we couldn't do anything about it because it was their data and their rules, it was our job to simply accept what they had. We could of course make serious suggestions, point out how horrid this was, but at the end of the day it was their decision. So we had a job to log into an email account every day, check for an email from Martha's hotmail account, and parse the excel file she used to read out private IDs and license numbers which she manually typed into it.

This was 20 years ago now so dear god I hope their laws improved.

It was a single PHP file containing upper tens of thousands of lines of code (i.e. probably 60k+ but I no longer recall the exact amount). And the horrors didn't stop there. Function names and code formatting were haphazard, some functions were descriptive enough to be helpful(ish) like check_if_first_friday_of_month() but most were literally along the lines of function12() with no comments to indicate the purpose. A̸n̶d̷ ̴t̵h̵e̵ ̸h̷o̵r̶r̸o̷r̵s̸ ̸d̷i̸d̵n̷'̷t̶ ̵s̶t̴o̸p̸ ̷t̵h̶e̶r̵e̶.̴ This application was storing sensitive personal information in the database in plain text. And the horrors didn't stop there.

Congrats to the developer, though. This project was the one that finally got him fired and he immediately pivoted into a management position at a big tech company (don't recall which but it might've been Microsoft or IBM) making an order of magnitude more money.

Weather forecasting software that maintains a linked list. When it eventually freed the memory used by the list, it would walk to the end of the list and free the last item. Then it would go back to the beginning of the list and do it again - rinse and repeat. Wonder why it was having performance issues 🙄

Java webapp. Customer facing. E-commerce application, so in PCI scope and dealt with credit card info and such.

There was one specific cookie that stored some site-wide preference for the customer. (Why not just put that preference in the database associated with the user? Because that would make too much sense is why.)

But the way they encoded the data to go into the cookie? Take the data, use the Java serialization framework (which is like Python's "Pickle" or Go's "Gob") to turn that into a string. But that string has binary data in it and raw binary data is kindof weird to put in a cookie, so you base64 encode the result. (The base64 encoding was the only sane step in the whole process.) Then you do the reverse when you receive the cookie back from the browser. (And no, there was no signature check or anything.)

The thing about the Java serialization framework, though is that decoding back into Java objects runs arbitrary object constructors and such. As in, arbitrary code execution. And there's no checking in the deserialization part of the Java serialization framework until your code tries to cast the object to whatever type you're expecting. And by that point, the arbitrary code execution has already happened. In short, this left a gaping vulnerability that could easily have been used to extremely ill effect, like a payment information breach or some such.

So all a malicious user had to do to run arbitrary code on our application server was serialize something, base64 encode it, and then send it to our servers as a cookie value. (Insert nail biting here.)

When we found out that there was a severe vulnerability, I got the task of closing the hole. But the existing cookies had to continue to be honored. The boss wasn't ok with just not honoring the old cookies and developing a new cookie format that didn't involve the Java serialization framework.

So I went and learned enough about the internal workings of how the Java serialization framework turned a Java value into a binary blob to write custom code that worked for only the subset of the Java serialization format that we absolutely needed for this use case and no more. And my custom code did not allow for arbitrary code execution. It was weird and gross and I made sure to leave a great big comment talking about why we'd do such a thing. But it closed the vulnerability while still honoring all the existing cookies, making it so that customers didn't lose the preference they'd set. I was proud of it, even though it was weird and gross.

The value that was serialized to put into the cookie? A single Java int. Not a big POJO of any sort. Just a single solitary integer. They could just as well have "serialized" it using base-10 rather than using the Java serialization framework plus base64.

The encryption thing is definitely weird/crazy and storing the SQL in XML is kinda janky, but sending SQL to a DB server is literally how all SQL implementations work (well, except for sqlite, heh).

ORMs are straight trash and shouldn't be used. Developers should write SQL or something equivalent and learn how to properly use databases. eDSLs in a programming language are fine as long as you still have complete control over the queries and all queries are expressable. ORMs are how you get shit performance and developers who don't have the first clue how databases work (because of leaky/bad abstractions trying to pretend like databases don't require a fundamentally different way of thinking from application programming).

There are a couple that come to mind.

Definitely the worst, a C# .net mvc application with multiple controllers that were 10s of thousands of lines long. I ran sonarqube on this at one point and it reported over 70% code duplication.

This code base actively ignored features in the framework that would have made things easier and instead opted to do things in ways that were both worse, and harder to do. For example, all SQL queries were done using antiquated methods that, as an added benefit, also made them all injectable.

Reading the code itself was like looking at old school PHP, but c#. I know that statement probably doesn't make sense, but neither did the code.

Lastly, there was no auth on any of the endpoints. None. There was a login, but you could supply whatever data you wanted on any call and the system would just accept it.

At the time I was running an internal penetration test team and this app was from a recent acquisition. After two weeks I had to tell my team to stop testing so we could just write up what we had already and schedule another test a couple months down the line.

My university uses ORACLE. To make a payment from a research account, you need to manually input a 15 character chart string. Every time.

A bit of Perl code from the late 90s/early 2000s that worked something like this (working from memory, untested):

my $hits = `grep $search_string $file`;
my @lines = split /\n/, $hits;
my @real_hits;
for( my $i = 0; $i < scalar(@lines); $i++ ) {
    my $line = $lines[0];
    if( $line =~ /$search_string/ ) {
        push @real_hits, $line;
    }
}

Let me explain a bit about what this does. Instead of reading a file line-by-line and using Perl's regex engine to match, it uses backticks to call out to the shell for grep. Those are split up by line. Then go through those lines (in a C-style for loop, not the perfectly good foreach version that Perl has had for a long time) and now we use a regex to match that line. You know, just in case shell grep didn't do its one job.

If anything, I'm probably making this code look better by declaring variables with my and following use strict standards.

This was written by a guy who was the main programmer before I was hired. I was told he was a real piece of shit. He often had some checks in his code that, if not passed, threw messages to the client like "WE HAVE DETECTED YOUR HACKING AND LOGGED YOUR IP ADDRESS WE'RE GOING TO GET YOU". Never met him personally, but his code is a pretty good example of why everyone came to hate Perl.

Another kind of "code" but:

The poll in a excel sheet the office sent via email. You had to fill it out and send it back, so they could type it off in another excel sheet.

That's where i realized that people have fundamentally different approaches in thinking and problem-solving.

My current workmate unironically calls his variables as "cat1", "cat2", etc.

He also didn't knew about git, so before I arrived, he uploaded the code to production with scp.

Finally, my boss told me that he is priority, so if he doesn't underestand git, we won't keep using it. I would underestand if this was about a different language, but it's git vs scp we're talking about.

A data ingestion service that was processing ~15 billion logs each day that was duplicating each of those logs 2-4 times in memory as a part of the filtering logic. No particular reason nor need to do it. When I profiled the system it was BY FAR the largest hog of CPU and memory.

The engineer who wrote it once argued with me about writing comparisons a == b vs b == a because one was technically more efficient ... in a language we weren't using.

It was a Java project and every class was in a separate Maven module.

Disclaimer: this is not really about code, but about using IT in my non-IT workplace and I realized this just yesterday. A rant.

I work in the social sector. Our boss seems to have slipped into position sideways (they did not do our work for a significant amount of time before).

I got zero onboarding when I started working there; everything I know about the organisational ins and outs I learned by asking my colleagues.

The boss seems to actively want to not inform me of things, i.e. even if I ask about something they reply in the most cursory manner or immediately refer me to somebody else. I have no idea why they do it, my guess is that they sense that they're woefully inadequate for the job, plus me being much older triggers insecurities?

For example, when I could not log into an app to see my future shifts, I asked the boss about it first but they immediately refered me to tech support. Calling them, after a while we found out that the boss had mistyped my name. Then I could log in.

Last week I was sick and waited til Sunday noon to check this week's shifts - but again I couldn't log in. The boss answered neither phone nor email. Fair enough I guess, on a sunday. Thankfully tech support was working and after a long while we found out that the app for checking my shifts only allows log-ins from within the workplace network, not the open web.

I almost missed my monday shift because of that. Boss calls me, enraged. I explained the situation. They clearly did not know that the app only allows log-ins from within the workplace network.

All my coleagues tentatively/silently agree that this boss is useless. How do we keep the workplace running, and why is it me who is left in the dark? Turns out they have a Whatsapp group. I don't use Whatsapp. They asked me repeatedly and urgently to join.

tl;dr: this workplace would fall apart if people wouldn't communicate through Whatsapp instead of official channels

I once saw an 'encryption' function where the key had a range of 32. Not 32 bits. I mean there were 32 different keys. And it was prepended as the first byte in the stream, so the decryption function didn't have to go out of the way to find it.

Thankfully I noticed that it got torn out and replaced with real encryption at some point.

It was a huge codebase in c# with a single file in VB.net with a comment at the top "copied from codinghorrors.com/…". I never dared to try understanding what that file was supposed to do and why nobody bothered converting it in c#

This was then sent to the server as pure sql, no orm.

ORMs are overrated.

Whatever im working on 💪