Home/ Questions/Q 7097815
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T10:58:57+00:00

I don’t normally deal in databases (I’ve managed a few small ones for web

  • 0

I don’t normally deal in databases (I’ve managed a few small ones for web apps I wrote for me and my friends) So I’m going to verify that I understand how everything works, before asking my question.

  1. SQL is a program that “does” databases. It manages all the tables and the schemes and the links, and it does most everything in response to commands it receives. You could type these commands in by hand, or have a script you write with commands in them, or have another program send these commands to SQL, but the commands haven’t really changed.

  2. SQL Injection occurs when a web application Takes input received from the user, and sends it to SQL without cleaning it up first. If the end-user is wiley enough, SQL will see commands that it was supposed to see as Data to be stored in a table somewhere, resulting in travesty.

  3. Typical SQL injection prevention involves sanitizing your user input, that is, stripping out any characters that would make SQL think a command was being sent, instead of data.

Now, My question:

Why does SQL not handle this for us? Why does SQL, on each command, not look for the first “, and the last “, and ignore any “s in between? (I don’t think “‘s are a part of standard SQL command syntax, it’s been a while, but if not, change could happen) It would, of course, prevent you from sending multiple commands simultaneously (as the 2nd/3rd commands would be ignored) but on a “I send 1 command at a time” rule, this pretty much ignores any shenanigans the end-user might try to pull.

I’m sure someone else has thought of this, and dismissed it as not working for some reason or another. But I don’t know enough to understand why, and I’d like to.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    “SQL” doesn’t handle it for us because “SQL” isn’t a program, it’s a language: Structured Query Language. The applications we build to interface with databases use the language SQL as a means to retrieve information from the database.

    The applications we build also use some sort of API (application programmer’s interface) to talk to the database and that API passes the SQL in to the database. (Actually to the RDBMS or Relational Database Management System, which is the “program” you might be thinking of like MySQL, Oracle, MS SQL Server, or PostgreSQL)

    There are some smarter APIs which do in fact handle the parameter sanitizing on their own, if the API offers access to prepared statements or stored procedure execution.

    Potential trouble with SQL injection comes when the API doesn’t use prepared statements or parameterized queries (or the developer elects not to use them) and instead directly constructs statements in the SQL language to pass to the database. The API’s job in this instance is simple: Just take the string handed from the application and pass it to the database. Because the SQL statement itself takes no input (remember, it is just a string), it has to be up to the developer to make sure it doesn’t contain harmful information.

    More sophisticated APIs which offer prepared statements or parameterized queries do take input and translate the input values into placeholders in the SQL statement, either passing the information natively to the RDBMS to process the parameters and prepared statement, or emulating that action in the application code, before passing a plain SQL string to the RDBMS; part of that translation usually involves sanitizing the values against harmful characters.

    • 0