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 a Web form or the query string of a page request, and deceives the server into executing malicious SQL commands. In some forms, user input is used directly to construct (or affect) dynamic SQL commands, or 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 the right to access the application. It requires the user to enter a name and password.
⑵ The content entered in the login page will be directly used to construct dynamic SQL commands, or directly used as parameters of stored procedures. Here is an example of an ASP.NET application constructing a 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 enters something like "' or '1'='1" in the user name and password input boxes.
⑷ After the content input by the user is submitted to the server, the server runs the above ASP.NET code to construct a 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 process 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 the injection attack and cannot truly authenticate the user's identity, the system will incorrectly authorize the attacker.
If an attacker knows that the application will use the content entered in the form directly 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?
Fortunately, it is not particularly difficult to prevent ASP.NET applications from being broken into by SQL injection attacks. All you need to do is filter all the input content before using the form input content to construct the SQL command. Filtering input can be done in a variety of ways.
⑴ For situations where SQL queries are dynamically constructed, the following techniques can be used:
First: Replace single quotes, that is, change all single single quotes into two single quotes to prevent attackers from modifying 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 the user input content to prevent attackers from constructing queries such as "SELECT * from Users WHERE login = 'mas' -- AND password =''", because the suffix of such queries Half of it has been commented out and is no longer valid. The attacker only needs to know a legal user login name and does not need to know the user's password to successfully gain access.
Third: Limit 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.