I’d love to know what this would actually do.
Edit: Thanks for the responses and lively discussion!!
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.
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
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.
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.
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.
Oh sweet summer child.
First, injection attacks are third on the owasp list, although they do roll xss into it too, which changed the name, since “shit sanitization on input” and “shit escaping before use” are the cause of both.
https://owasp.org/Top10/A03_2021-Injection/
Secondly, SQL injection is freakishly common and easy. I don’t know of any database libraries that prevent you from directly executing an SQL literal, they just encourage parameterized statements.
I have personally run into plenty of systems where people build SQL via string concatenation because for whatever reason they can’t use an orm or “proper” SQL generator.
You can find them in the wild fairly often by just tossing ' or 1=1;-- into fields in forms. If it gets mad in a way that doesn’t make sense or suddenly takes forever, you win!
Don’t do that though, because it’s illegal.
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.
Nothing. For one, it won’t let you enter letters. Two, the table structure to these POS systems are more nuanced than a simple bills table with am amounts field.
It’s amusing and all, but it’s not something you can do.
Source: work with, and develop around, these types of POS systems.
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.
Can’t they trace it back to you since you’re using a card to get that prompt?
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.
Are there still places you can buy those that you wouldn’t be on camera and immediately trackable?
I’m not shitting on the idea, I’m just trying to make it as good as possible.
Maybe. If they can identify which record was the last one changed and the last one changed its directly related to the one that made the change and the ended transaction statement successfully posted a transaction
If the SQL injection crashed that person’s transaction there’s little chance of finding the culprit
Little Bobby Tables says hi.
I laughed a lot at this.
