Now if I could only bypass the float only input field…
this post was submitted on 04 Apr 2024
972 points (97.5% liked)
Programmer Humor
19537 readers
390 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 1 year ago
MODERATORS
F12 lol. The only issue with a dev console helping would be serverside checking
How do you press F12 on a touchscreen interface?
load more comments
(2 replies)
I laughed a lot at this.
Can't they trace it back to you since you're using a card to get that prompt?
Prepaid VISA gift card purchased with cash.
In my country, we can buy pre-paid credit cards in the supermarket using cash. I guess that is still traceable using supermarket security cameras and facial recognition, but if you're attempting this, I'd make it as difficult as possible.
load more comments
(1 replies)
load more comments
(2 replies)
Jokes on you. Restaurant owner too rich, behavior is within normal range for IRS AI.
Though the AI is interested on how your bank account is higher than it’s supposed to be.
load more comments
(3 replies)
I'd love to know what this would actually do.
Edit: Thanks for the responses and lively discussion!!
its an sql injection attack.
its rather unlikely that it works in a modern app.
assuming this would work,
it injects a command in the sql database.
it is assumed that the app runs a sql querry with the input field as a parameter e.g.
INSERT INTO "bills" (item, ammount, tip) VALUES ("steak", "20,00 $", "content of the custom tip goes here");
the semicolon indicates the end of the querry,
so the the text would cause the app to run an unfinished querry, and then start a new querry that messes up the content of the bills table.
Assuming the accounting system this thing links with both does not protect from SQL injection attacks (many don't, despite it being easy to protect against) and also has a table named "Bills" with a field named "amount"; what this would do is go through every single Bills record and half the value in the amount field. This would completely fuck the system, particularly when it came to billing and tax filing as the numbers for accounts billing and receivable wouldn't even come close to matching each other. The accounting department would have a hell of a time fixing the damage.
does not protect from SQL injection attacks (many don't, despite it being easy to protect against)
Every modern database library automatically protects against SQL injection, usually by using prepared statements (where the query with placeholders, and the placeholder values, are sent as two separate things). so a system would have to be written extremely poorly to be vulnerable to it.
This post is just a joke as developers should hopefully be aware of the OWASP top 10 security vulnerabilities.
Edit: Bad developers will do bad things, but any reasonable developer should be well aware of these risks.
Every modern database library automatically protects against SQL injection,
No. Every modern library allows using prepared statements, but very few (of any) force using them. If the developer doesn't use them the libraries won't do shit to protect you.
What I meant is that not many people write raw SQL in product code any more, other than for analytical purposes (which are often in a system like Apache Airflow rather than in product code). ORM systems have mostly taken over except for cases where you really need raw SQL for whatever reason.
load more comments
(1 replies)
Well no. If the programmer uses prepared statements, they are protected. If they use a prepared statement but actually just put their own unsanitized statement in there and execute it, it's not protected.
Now, I'd like to say it is 2024 and everyone should be using AT LEAST prepared statements for security. I've seen people doing some scary things in my time, and that includes quite recently.
load more comments
(2 replies)
load more comments
(5 replies)
Couldn't they just *2 all the bills from before this was ran and straighten it out?
I imagine they could if they knew exactly what you did and when, but if it doesn't get discovered until later and nobody knows what happened, it would probably be a bitch to figure out
Pretty sure it would be obvious to anyone working there that chicken tenders are $10 not $5. Even a quick glance at any single bill would show the issue.
load more comments
(5 replies)
It seems like it would be fairly easy to find. All you need to do is find out where the price drops massively, and work backwards from there, since it doesn't change the code going forward.
Need to throw a rand() in there to make it less easy to unfuck
In the amount/2 term?
Yup. Rand() chooses a random float value for each entry. By default I believe it’s anywhere between 0 and 1. So it may divide the first bill by .76, then the second by .23, then the third by 0.63, etc… So you’d end up with a completely garbage database because you can’t even undo it by multiplying all of the numbers by a set value.
load more comments
(3 replies)
EOM recon will be a bitch.
load more comments
(2 replies)