How to prevent SQL injection attacks in ASP.NET

1. What is a SQL injection attack?

SQL injection attack is when the attacker inserts SQL commands into the input field of a Web form or the query string of a page request, tricking 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 permission 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. The following 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 "' or '1'='1" in the user name and password input boxes. content.

　⑷ 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 the 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 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 function 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. As long as all the input content is filtered before using the content entered in the form to construct the SQL command, That's it. Filtering input can be done in a variety of ways.

⑴ For situations where SQL queries are dynamically constructed, 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: 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 checking 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 the 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.

Encrypt the data entered by the user and then compare it with the data saved in the database. This is equivalent to "sterilizing" the data entered by the user. The data entered by the user no longer has any special effects on the database. meaning, thus preventing 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 extracts 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.

The above is how ASP.NET prevents SQL injection attacks. I hope it will be helpful to everyone's learning.

For more articles on how ASP.NET can prevent SQL injection attacks, please pay attention to the PHP Chinese website!