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.
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.
Also, by dividing by a number between 0 and 1, you increase the amount it looks like it billed. So income will look like it’s higher than outgoing funds, which will raise suspicions of embezzlement. And if someone actually is embezzling, whatever accounting tricks they’ve been using to hide it might just stop working because everything might need to be examined with a fine tooth comb. “Oh, the billing numbers aren’t right, and also it turns out the invoice numbers aren’t right either. Billing issue was tracked to a hack, but what’s going on with these invoices?”
if you’re trying to be malicious, wouldn’t it be better to multiply by Rand() instead of divide by Rand()?
assuming there are a decent number of recorded sales, you’d end up seeing many of the calls to Rand() returning values very close to 0. so, if you’re dividing by those values, you’d end see lots of sales records reporting values in the thousands, millions, or even billions of dollars. i feel like that screams “software bug” more than anything. on the other hand, seeing lots of values multiplied by values close to 0 would certainly look weird, but it wouldn’t be as immediately suspicious.
(of course a better thing would just be to use Rand() on a range other than [0,1])
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
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.
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.
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.
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 ' or1=1;-- into fields in forms. If it gets mad in a way that doesn’t make sense or suddenly takes forever, you win!
That one was a treat when I check under critical, since it’s an injection attack that can bypass parameterized query protections for the database driver, which is why “defense in depth” and “always sanitize your fucking inputs” are such key things to remember.
I hope that provided what you’re looking for, and maybe increases your awareness of SQL injection. 😊
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.
Bad developers will do bad things, but most DB framework documentation points people towards the right way to do things, which is why I said it’s not common any more.
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.
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. INSERTINTO"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.
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.
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.
Satan?
Also, by dividing by a number between 0 and 1, you increase the amount it looks like it billed. So income will look like it’s higher than outgoing funds, which will raise suspicions of embezzlement. And if someone actually is embezzling, whatever accounting tricks they’ve been using to hide it might just stop working because everything might need to be examined with a fine tooth comb. “Oh, the billing numbers aren’t right, and also it turns out the invoice numbers aren’t right either. Billing issue was tracked to a hack, but what’s going on with these invoices?”
if you’re trying to be malicious, wouldn’t it be better to multiply by
Rand()instead of divide byRand()?assuming there are a decent number of recorded sales, you’d end up seeing many of the calls to
Rand()returning values very close to0. so, if you’re dividing by those values, you’d end see lots of sales records reporting values in the thousands, millions, or even billions of dollars. i feel like that screams “software bug” more than anything. on the other hand, seeing lots of values multiplied by values close to 0 would certainly look weird, but it wouldn’t be as immediately suspicious.(of course a better thing would just be to use
Rand()on a range other than[0,1])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
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.
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.
No it would change the value of all past bills, future bills would still be correct.
And anyone who looks at a past bill would see half price tenders.
No. The bill given to the customer would still show the correct amount.
And if anyone looked at previous bills from the backend, they would see normally priced chicken tenders. The total for the bill would be wrong though.
Bill
2x orders chicken tenders $10 =20
Bill total $10 - 20/2 = 10…
Huh… I wonder what the issue is……
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.
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.
Do you have any recent examples of major SQL injection holes?
https://www.securityweek.com/millions-of-user-records-stolen-from-65-websites-via-sql-injection-attacks/
https://www.darkreading.com/remote-workforce/critical-security-flaw-wordpress-sql-injection
https://www.tenable.com/blog/cve-2023-48788-critical-fortinet-forticlientems-sql-injection-vulnerability
https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-158a
https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&cwe_id=CWE-89&isCpeNameSearch=false
You can fiddle with the nvd search settings to find whatever severity score you like, or filter by execution parameters.
https://nvd.nist.gov/vuln/detail/CVE-2024-1597
That one was a treat when I check under critical, since it’s an injection attack that can bypass parameterized query protections for the database driver, which is why “defense in depth” and “always sanitize your fucking inputs” are such key things to remember.
I hope that provided what you’re looking for, and maybe increases your awareness of SQL injection. 😊
Great comment. Thanks!
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=sql+injection
And without giving away specifics, I’ve personally found SQLi vulns in the wild within the last 5ish years.
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.
Bad developers will do bad things, but most DB framework documentation points people towards the right way to do things, which is why I said it’s not common any more.
Bad developers are common though. And good documentation won’t stop a bad developer from doing a bad thing.
I agree that SQLi isn’t as common as it once was, but it still very much exists.
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.
Practically every dev learnt SQL and it’s really easy to put hands crafted SQL in code so it’s an easy mistake to make
EOM recon will be a bitch.
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.
Further: xkcd.com/327
Is that Bobby?
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.
deleted by creator