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 be 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 most common security vulnerabilities.
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.
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!
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. 😊
Every modern database library automatically protects against SQL injection, usually be 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 most common security vulnerabilities.
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
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://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.
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!