First, what is SQL injection attack?
The so-called SQL injection attack is that the attacker inserts the SQL command into the input domain of the web form or the query string requesting the page request, and the spoofing server performs malicious SQL commands. In some forms, the content entered by the user is directly used to construct (or influence) dynamic SQL commands, or as input parameters of the stored procedure, such forms are particularly susceptible to SQL injection attacks. Common SQL injection attack processes such as:
(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 an 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 ("'");
(3) Attacker Enter "'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.
Second, 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 event of dynamically constructing SQL query, you can use the following technique:
First: Replace single quotation marks, that is, change all individual single quotes to two single quotes to prevent attackers 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 "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 this kind of query The half part has been commented away, no longer valid, the attacker knows if a legal user login name is not required to know the user's password can be successfully accessible.
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. The transmission method of SQL parameters will prevent attackers from using single quotes and hyphens to implement attacks. In addition, it also allows database permissions to limit only allowing specific stored procedures, and all user inputs must follow the security context of the called stored procedure, which is difficult to inject an injection attack.
(3) Restriction form or query the length of the string input. If the user's login name is only 10 characters, do not recognize more than 10 characters entered in the form, which will greatly increase the difficulty of insert harmful code in the SQL command.
⑷ Check the legitimacy of the user input, confident that the input content contains only legal data. Data checks should be implemented in the client and server-side validation, to perform server-side verification, to make up for the vulnerability of the client verification mechanism.
At the client, the attacker is fully likely to obtain the source code of the web page, modify the script that verifies the legitimacy (or directly delete the script), and then submit illegal content to the server through the modified form. Therefore, to ensure that verification is actually implemented, the only way is to perform verification on the server side. You can use many built-in authentication objects, such as RegularExpressionValidator, which can automatically generate client scripts for verification, of course, you can also insert the server-side method call. If you can't find a ready-made verification object, you can create one by customvalidator yourself.
⑸ 加 Save the user login name, password, and other data. Encrypt the data entered by the user, then compare it with the data saved in the database, which is equivalent to "disinfecting" processing on the data input, and the data entered by the user is no longer any special meaning of the database, thereby Prevent an attacker from injecting the SQL command. The System.Web.Security.FormSauthentication class has a HashPasswordforStoringInfigfile, which is ideal for disinfecting the input data.
⑹ Check the number of records returned by the query to extract data. If the program only requires returns a record, the actually returned record exceeds a line, then it is wrong.
