Original post: hachyderm.io (Mastodon)
var true = false;
var false = true;
this post was submitted on 21 Mar 2025
676 points (100.0% liked)
Programmer Humor
21988 readers
1427 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
So we need to be careful with upper- and lowercase. Meanwhile the docs: > settiings
Yes, the settiings are different than the settings. You also need to be careful with those.
had to use a different spelliings at backend and frontend, otherwise it wouldn't work.
load more comments
(1 replies)
Is the backend Python and the frontend JavaScript? Because then that would happen and just be normal, because Boolean true is True in python.
Probably, but if you're interpreting user inputs as raw code, you've got much much worse problems going on, lol.
[...]®ister=import os; os.system("sudo rm -rf /"); return True
Hey, that's my username too. Or it was going to be, while the site was still up.
What a coincidence!
I guess I'll wait for the site to come back, and see if it's still available...
It's the settiings file... It's probably supposed to only be written by the system admin.
A good place to put persistent malware. That's why when using docker images always mount as ro if at all possible.
It’s you can modify the settings file you sure as hell can put the malware anywhere you want
It’s you can modify the settings file you sure as hell can put the malware anywhere you want
True. (But in case it amuses you or others reading along:) But a code settings file still carries it's own special risk, as an executable file, in a predictable place, that gets run regularly.
An executable settings file is particularly nice for the attacker, as it's a great place to ensure that any injected code gets executed without much effort.
In particular, if an attacker can force a reboot, they know the settings file will get read reasonably early during the start-up process.
So a settings file that's written in code can be useful for an attacker who can write to the disk (like through a poorly secured upload prompt), but doesn't have full shell access yet.
They will typically upload a reverse shell, and use a line added to settings to ensure the reverse shell gets executed and starts listening for connections.
Edit (because it may also amuse anyone reading along): The same attack can be accomplished with a JSON or YAML settings file, but it relies on the JSON or YAML interpreter having a known critical security flaw. Thankfully most of them don't usually have one, most of the time, if they're kept up to date.
load more comments
(1 replies)
Given the warning about capitalization, the best possible case is that they're using ast.literal_eval() rather than throwing untrusted input into eval().
Err, I guess they might be comparing strings to 'True' and are choosing to be really strict about capitalization for some reason.
Yeah. Maybe .to_lower() is really expensive in their environment, lol.
load more comments
(1 replies)
Can't they just convert a "true" input to backend to uppercase
Yep they should use a config file format like JSON or TOML or YAML or what have you, and then decode that into python objects. Using an actual programming language for config is dumb as hell IMO. (inb4 pissed off suckless fans)
load more comments
(4 replies)
load more comments
(1 replies)
The cherry on top is that they didn't even spell settings correctly.
settiings is spelled differently on the backend
load more comments
(1 replies)
Glorious. I remember some hilarious nonsense in an API where the devs I worked with hadn't known they could just use boolean in JSON and had badly implemented it through strings, but this... This is amazing!
A system I work with gives all keys a string value of "Not_set" when the key is intended to be unset. The team decided to put this in because of a connection with a different, legacy system, whose developers (somehow) could not distinguish between a key being missing or being present but with a null value. So now every team that integrates with this system has to deal with these unset values.
Of course, it's up to individual developers to never forget to set a key to "Not_Set". Also, they forgot to standardise capitalisation and such so there are all sorts of variations "NOT_SET", "Not_set", "NotSet", etc. floating around the API responses. Also null is still a possible value you need to handle as well, though what it means is context dependent (usually it means someone fucked up).
At my last job we had a lot of old code, and our supposedly smartest framework people couldn't be bothered learning front end properly. So there was a mix of methods for passing values to the front end, but nobody seemed to think of just passing JSON and parsing it into a single source of truth. There was so much digging for data in hidden columns of nested HTML tables, and you never knew if booleans would be "true", "TRUE", "1", or "Y" strings.
Never mind having to unformat currency strings to check the value then format them back to strings after updating values.
I fixed this stuff when I could, but it was half baked into the custom framework.
And you all complained when in C we used 1 and 0...
We use 0 and not 0...
Akcshually we use 0 and "not equal 0", since "not 0" would be 0xFF..FF, and (at least gcc) gives back a 1 for a true expression. No idea about the spec, probably undefined...
Damn you for correcting me correctly! :D
Hear me out, what about using JSON to store the configuration in the Python backend?
You need to use as many different formats as possible, otherwise you look unprofessional
load more comments
(1 replies)
I’ve always hated case sensitivity. I know that at an ASCII level “variable” != “Variable” but is there really a reason to have a distinction between them?
You stated the reason yourself. Those are different values and matching in a case-insensitive manner is more work under the hood.
We do plenty of stuff for human consumption. Computers work for us, not the other way around. Insensitivity should be the default. It’s okay to give options. I’m not saying take that away.
load more comments
(3 replies)
You are thinking it's easy because you only think of e == E, but I'll let you look up collation and accents and, you know, Unicode and let you think about it.
There is nothing trivial about case sensitivity, except in trivial cases.
That makes me think, perhaps, you might be able to set it to exec("stuff") or True...
Cap in the back, low-key up front. Got it.
view more: next ›