“framework”, found your problem. Frameworks save time by ignoring how code works. Folks taught upon a Framework have no real idea what its produced code does.
Typically the security conscious webdev still needs to define an API to their database. It’s bad practice to let users hit the DB directly.
Now, if you hack the API then sure you can start hacking the database, but first you have to hack the API to the database which raises the costs of cyberwar
All observations support it. All reviewed generated bloatware supports it. I’ll stand by my, assumptions, until there is any direct evidence against them discovered.
You have a database driver that takes care of communicating with the database.
In the bad old days (pre-early 2000s) the only way they knew how to do that was plain old SQL strings so you passed a string that contained both the data and the instructions on what to do with it.
Now you SHOULD be writing prepared statements that contain the instructions then passing the data separately to fill in the placeholders in the prepared statement via the driver (NOT via modifying the string).
// DO NOT DO THISexecute("INSERT INTO foo VALUES ('a', 'b', 'c')")
vs
// DO THISexecutePrepared("INSERT INTO foo VALUES (?,?,?)", "a", "b", "c")
It’s a common problem for the same reason that it’s a common problem for people to have precision errors when doing math with currencies… People write the wrong code because they don’t know any better (in that case using float or double/floating point math instead of a BigDecimal type).
Not filtering out characters that could be part of URL has no bearing on whether or not the site is properly protected from SQL injection. I’m much more often worried about sites that explicitly filter out certain characters because it likely means they don’t understand what they’re doing (similar to sites that insist on annual password changes).
The fact that people are arguing about this shows how much of an issue we have with education on this topic.
Because it’s literally impossible for SQL injection to occur if you do this. The database has already compiled the operation. There’s nothing to escape, there’s no more logic that can be added, you’re free to insert arbitrary gook just like you can into any old array.
If it doesn’t exclude a URL it likely doesn’t block SQL either.
Time for the ol XKCD Little Bobby Tables attack
These days you have to actively work against whatever framework you are using to get SQL injection to work.
“framework”, found your problem. Frameworks save time by ignoring how code works. Folks taught upon a Framework have no real idea what its produced code does.
Typically the security conscious webdev still needs to define an API to their database. It’s bad practice to let users hit the DB directly.
Now, if you hack the API then sure you can start hacking the database, but first you have to hack the API to the database which raises the costs of cyberwar
A whole lot of assumptions there, buddy.
All observations support it. All reviewed generated bloatware supports it. I’ll stand by my, assumptions, until there is any direct evidence against them discovered.
Okay, just spare us from your opinions.
no
Do you work as a Software Engineer or in Tech in general?
If so, I’m genuinely curious what the biggest project you created without the use of frameworks.
Now if it’s VSC’ed and on the web, that would be even better.
That’s not how this works.
You have a database driver that takes care of communicating with the database.
In the bad old days (pre-early 2000s) the only way they knew how to do that was plain old SQL strings so you passed a string that contained both the data and the instructions on what to do with it.
Now you SHOULD be writing prepared statements that contain the instructions then passing the data separately to fill in the placeholders in the prepared statement via the driver (NOT via modifying the string).
// DO NOT DO THIS execute("INSERT INTO foo VALUES ('a', 'b', 'c')")vs
// DO THIS executePrepared("INSERT INTO foo VALUES (?,?,?)", "a", "b", "c")And yet injection is still #3 in the OWASP Top 10
Okay?
You make it sound as if it’s a thing of the past when it is still a common problem.
It’s a common problem for the same reason that it’s a common problem for people to have precision errors when doing math with currencies… People write the wrong code because they don’t know any better (in that case using float or double/floating point math instead of a BigDecimal type).
Not filtering out characters that could be part of URL has no bearing on whether or not the site is properly protected from SQL injection. I’m much more often worried about sites that explicitly filter out certain characters because it likely means they don’t understand what they’re doing (similar to sites that insist on annual password changes).
The fact that people are arguing about this shows how much of an issue we have with education on this topic.
Please explain how you remain confident of that “SHOULD” when they are not sanitizing the HTML out?
Because it’s literally impossible for SQL injection to occur if you do this. The database has already compiled the operation. There’s nothing to escape, there’s no more logic that can be added, you’re free to insert arbitrary gook just like you can into any old array.
“if” caring a lot of water on this here frog’s back mr. scorpion.