1. What is a SQL injection attack?
The so-called SQL injection attack means that the attacker inserts SQL commands into the input field of the Web form or the query string of the page request to trick the server into executing malicious SQL command. In some forms, the content entered by the user is directly used to construct (or affect) dynamic SQL commands, or is used as input parameters for stored procedures. Such forms are particularly vulnerable to SQL injection attacks. Common SQL injection attack processes include:
⑴ An ASP.NET web application has a login page. This login page controls whether the user has permission to access the application. It requires the user to enter a name and password.
⑵ The content entered on the login page will be directly used to construct dynamic SQL commands, or directly used as parameters of stored procedures. The following is an example of an ASP.NET application construction query:
System.Text.StringBuilder query = new System.Text.StringBuilder(
"SELECT * from Users WHERE login = '")
. Append(txtLogin.Text).Append("' AND password='")
.Append(txtPassword.Text).Append("'");
⑶ The attacker is in the user name And enter something like "' or '1'='1" in the password input box.
⑷ After the content input by the user is submitted to the server, the server runs the above ASP.NET code to construct an SQL command to query the user. However, because the content input by the attacker is very special, the final SQL command becomes :SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'.
⑸ The server executes a query or stored procedure to compare the identity information entered by the user with the identity information saved in the server.
⑹ Since the SQL command has actually been modified by an injection attack, the user's identity cannot be truly verified, so the system will incorrectly authorize the attacker.
If an attacker knows that the application will directly use the content entered in the form for identity verification queries, he will try to enter some special SQL strings to tamper with the query to change its original functionality and trick the system into granting access. permissions.
Depending on the system environment, the damage that an attacker may cause is also different, which is mainly determined by the security permissions of the application to access the database. If the user's account has administrator or other relatively advanced rights, the attacker may perform various operations on the database tables that he wants to do, including adding, deleting or updating data, or even directly deleting the table.
2. How to prevent it?
Fortunately, it is not particularly difficult to prevent ASP.NET applications from being invaded by SQL injection attacks. As long as you use the content entered in the form to construct SQL Before issuing the command, just filter all the input content. Filtering input can be done in a variety of ways.
⑴ For dynamically constructing SQL queries, the following technology can be used:
First: Replace single quotes, that is, change all single quotes that appear alone into two single quotes to prevent The attacker modifies the meaning of SQL commands. Looking at the previous example again, "SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'" will obviously get the same "SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'" different results.
Second: Remove all hyphens in user input to prevent attackers from constructing queries such as "SELECT * from Users WHERE login = 'mas' -- AND password =''". Because the second half of this type of query has been commented out and is no longer valid, the attacker only needs to know a legitimate user login name and does not need to know the user's password to successfully gain access.
Third: Restrict the permissions of the database account used to execute queries. Use different user accounts to perform query, insert, update, and delete operations. By isolating the operations that can be performed by different accounts, it prevents the place originally used to execute the SELECT command from being used to execute the INSERT, UPDATE or DELETE command.
⑵ Use stored procedures to execute all queries. The way SQL parameters are passed will prevent attackers from using single quotes and hyphens to carry out attacks. In addition, it also allows database permissions to be restricted to only allow specific stored procedures to execute. All user input must comply with the security context of the called stored procedure, so that injection attacks are difficult to occur.
⑶ Limit the length of form or query string input. If the user's login name only has a maximum of 10 characters, do not accept more than 10 characters entered in the form. This will greatly increase the difficulty for attackers to insert harmful code into SQL commands.
⑷ Check the legality of user input and make sure that the input content only contains legal data. Data inspection should be performed on both the client and server sides - server-side validation is performed to compensate for the fragile security of the client-side validation mechanism.
On the client side, it is entirely possible for an attacker to obtain the source code of the web page, modify the script that verifies legality (or delete the script directly), and then submit the illegal content to the server through the modified form. Therefore, the only way to ensure that the verification operation has actually been performed is to perform verification on the server side as well. You can use many of the built-in validation objects, such as RegularExpressionValidator, which can automatically generate client-side scripts for validation, and of course you can also insert server-side method calls. If you can't find a ready-made validation object, you can create one yourself through CustomValidator.
⑸ Encrypt and save user login name, password and other data. Encrypting the data entered by the user and then comparing it with the data saved in the database is equivalent to "sterilizing" the data entered by the user. The data entered by the user no longer has any special meaning to the database, so it Prevents attackers from injecting SQL commands. The System.Web.Security.FormsAuthentication class has a HashPasswordForStoringInConfigFile, which is very suitable for sanitizing input data.
⑹ Check the number of records returned by the query that extracted the data. If the program only requires one record to be returned, but the actual returned record is more than one row, it will be treated as an error.