(1) A registration page with an ASP.NET web application, which controls whether the user has the right to access the application, which requires the user to enter a name and password. (2) The content entered in the login page will be used directly to construct the dynamic SQL command, or directly as the parameters of the stored procedure. Below is an example of the ASP.NET application constructor: system.text.StringBuilder Query = new system.text.StringBuilder (select * from users where login =) .append (txtLogin.text) .append (and password =) .append (txtpassword.text) .append (); () an attacker inputs or 1 = 1 in the user name and password input box. ⑷ After the user entered content submits to the server, the server runs the above ASP.NET code constructs a query user's SQL command, but because the content of the attacker is very special, the final SQL command becomes: SELECT * FROM WHERE Login = OR 1 = 1 and password = or 1 = 1. ⑸ The server performs the query or stored procedure, compares the identity information entered by the user and the identity information saved in the server. ⑹ Since the SQL command has actually been injected to attack modifications, it is no longer able to actually verify the user identity, so the system will be incorrectly authorized to the attacker. If an attacker knows that the application will use the content entered in the form directly to verify the identity query, he will try to enter some special SQL string tapentation queries to change its original function, and spoof the system to grant access. The system environment is different, and the damage that the attacker may have different, which is mainly determined by the security privilege of the application access database. If the user's account has an administrator or other premium permissions, an attacker may perform a variety of operations he want to do, including add, delete, or update data, and may even delete the table directly. How to prevent? Fortunately, it is not a particularly difficult thing to prevent ASP.NET applications, which is not a particularly difficult thing, as long as the SQL command is constructed with the contents of the form input, it is possible. Filtering input can be done in a variety of ways. (1) For the occasion of dynamically constructing SQL queries, you can use the following technique: First: Replace the single quotation mark, that is, change all individual single quotes to two single quotes to prevent the attacker from modifying the meaning of the SQL command. Let's see the previous example, "SELECT * from users where login = or 1 = 1 and password = or 1 = 1" obviously got with "SELECT * from users where login = or 1 = 1 and password = or 1 = 1" Different results. Second: Delete all the characters in the user input content, prevent the attacker from constructing a query such as "Select * from users where login = mas - and password =", because the second half of this kind of query has been Note, no longer valid, the attacker knows if an legitimate user login name is not required to obtain access to the user's password. Third: Limit its permissions for database accounts used to perform queries. Execute queries, insert, update, delete operations with different user accounts. Due to the isolation of different accounts executable, it also prevents the place originally used to execute the select command but is used to perform the INSERT, UPDATE, or DELETE commands. (2) Perform all queries with a storage process.
