Yesterday I was asked a question by a big cow, why SQL parameterized query can prevent SQL injection, and what is the principle of parameterized query? The result is boring. Before, I only knew that parameterized query can prevent SQL injection, but I didn't delve into its principle. I will find some articles today, learn it, and share it with you.
The following quotes from the answers of the great gods:
The principle is to use the pre-compilation method, first compile the parameter set in the SQL statement that can be controlled by the client, generate the corresponding temporary variable set, and then use the corresponding setting method to assign values to the elements in the temporary variable set. The function setString() will perform mandatory type checking and security checking on the incoming parameters, so SQL injection is avoided.
Recently, I have been studying Java in depth, and I have attached a piece of implementation code. Other languages have encapsulated the processing of assignment functions, making it invisible to users and unable to understand the mechanism.
import java.sql.PreparedStatement;
String sql = "select * from user where username=? and passwd=?";
ps = conn.PreparedStatement(sql);
ps.setString(1, "admin");
ps.setString(2, "123456");
resultSet = ps.executeQuery();
The specific implementation code refers to
Java's PreparedStatement (Java Platform SE 7)
, and other languages can be implemented according to his principles.
Parameter query is a capability provided natively by the database, not provided by data access libraries such as
ado.net , which is just an encapsulation of the former.
The SQL statements and parameter objects we wrote in the programming language are still statements and parameters when they are sent to the database. It is not like some answers think that the values of the parameters are converted and spliced into the statement, and finally the statement is submitted to the database. To say what "preprocessing" the class library does, it is probably just that when the developer does not explicitly specify the type and length of the parameter, the class library will automatically determine the appropriate type and length for it according to the value of the parameter, and that's it. This is easily confirmed with a database statement tracing tool such as SQL Server Profiler. So parameterized queries really don't have much to do with the programming language/class library.
As for how the database handles the statement and parameters after receiving it, my understanding/guess is that the database subsystem responsible for parsing the query statement converts/compiles the statement into some underlying language that the database execution subsystem can execute (such as the C# compiler). Compiling C# into IL and running it to CLR is similar.) In this step, the semantics of this batch of query statements are solidified into a set of behaviors. This set of behaviors is the so-called "execution plan". The execution plan describes something roughly Where to get the data, how to process the data, etc. This is why the table name and field name cannot be parameterized, because if these things are uncertain, the execution plan cannot be generated at all. As for whether the value of the parameter affects the generation of the execution plan, yes, but it affects whether the value can hit a certain index, statistical information and other performance-related things, and if so, a better execution plan will be generated (precise guideline Go to a certain page to fetch data, etc.), otherwise use a stupid method (such as a full table scan), which will not affect the program of the entire plan. This is the reason why parameterization can prevent injection.
To sum up, the reason why parameterization can prevent injection is that the statement is a statement, the parameter is a parameter, and the value of the parameter is not part of the statement. The database only runs according to the semantics of the statement. As for whether to run with an ordinary backpack or a monster, It will not affect the travel route, but the difference between running faster and slower.