In ASP. NET, how does one prevent SQL injection attacks ?)

This is not my originality, but I still use it as the opening part of this year. this year we may need to start learning and using ASP. NET. I hope the author of this article will not be surprised...

1. What is SQL injection attacks?

The so-called SQL injection attack means that an attacker inserts an SQL command into the input field of a Web form or the query string requested by the page, and deceives the server to execute malicious SQL commands. In some forms, the content entered by users is directly used to construct (or affect) dynamic SQL commands or as input parameters of stored procedures. Such forms are particularly vulnerable to SQL injection attacks. Common SQL injection attacks include:

(1) An ASP. NET Web application has a logon page that controls whether the user has the right to access the application. It requires the user to enter a name and password.

(2) The content entered on the logon page is directly used to construct dynamic SQL commands, or directly used as parameters of stored procedures. The following is an example of constructing a query for an ASP. NET application:

System. Text. StringBuilder query = new System. Text. StringBuilder (

"SELECT * from Users WHERE login = '")

. Append (txtLogin. Text). Append ("'AND password = '")

. Append (txtPassword. Text). Append ("'");

(3) The attacker enters "'or '1' = '1" in the username and password input boxes.

(4) After the content entered by the user is submitted to the server, the server runs the above ASP.. NET code is used to construct the SQL command to query users. However, because the content entered by attackers is very special, the final SQL command obtained is: SELECT * from Users WHERE login = ''or '1' = '1' AND password ='' or '1' = '1 '.

The login server performs queries or stored procedures to compare the user-entered identity information with the identity information stored on the server.

Because SQL commands have been modified by injection attacks and cannot actually authenticate user identities, the system will incorrectly authorize attackers.

If the attacker knows that the application will directly use the content entered in the form for identity authentication queries, he will try to input some special SQL strings to tamper with the query and change its original function, the spoofing system grants access permissions.

The system environment is different, and attackers may cause different damages, which is mainly determined by the security permissions of the application to access the database. If the user's account has administrator or other advanced permissions, attackers may perform various operations on the database table, including adding, deleting, or updating data, you may even directly Delete the table.

2. How to prevent such attacks?

Fortunately, ASP. it is not particularly difficult for a NET application to be intruded by SQL injection attacks. You only need to filter all input content before using the content entered in the form to construct an SQL command. You can filter the input content in multiple ways.

(1) The following technologies can be used to dynamically construct SQL queries:

First, replace the single quotation marks (single quotes) to change all single quotes to two single quotes to prevent attackers from modifying the meaning of SQL commands. Let's take a look at the previous example, "SELECT * from Users WHERE login = '''' or ''1'' = ''1' AND password = '''' or ''1'' = ''1 '" obviously, different results will be obtained from "SELECT * from Users WHERE login ='' or '1' = '1' AND password = ''or '1' = '1.

2. delete all the characters 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, attackers only need to know a valid user logon name and do not need to know the user's password to obtain access permissions.

Third: restrict the permissions of the database account used to execute the query. Query, insert, update, and delete operations with different user accounts. The operations that can be performed by different accounts are isolated, which prevents the places where the SELECT command was originally used to execute the INSERT, UPDATE, or DELETE command.

(2) Use stored procedures to execute all queries. The SQL parameter transmission method prevents attacks by using single quotes and hyphens. In addition, it allows the database permission to be limited to only allow execution of specific stored procedures. All user input must comply with the security context of the called stored procedure, in this way, it is difficult to launch injection attacks again.

(3) restrict the length of form or query string input. If a user's login name can contain a maximum of 10 characters, do not recognize the 10 or more characters entered in the form. This will greatly increase the difficulty for attackers to insert harmful code in SQL commands.

(4) Check the validity of user input and ensure that the input content only contains valid data. Data check should be performed on both the client and the server-the reason for the server-side verification is to make up for the weak security of the client authentication mechanism.

On the client, attackers can obtain the source code of the webpage, modify the script to Verify validity (or directly Delete the script), and submit the illegal content to the server through the modified form. Therefore, to ensure that the verification operation has been performed, the only way is to perform verification on the server. You can use many built-in verification objects, such as RegularExpressionValidator, which can automatically generate client scripts for verification. Of course, you can also insert server-side method calls. If no existing verification object is found, you can create one by yourself through CustomValidator.

Encrypt and save user login names, passwords, and other data. Encrypt the data entered by the user, and then compare it with the data stored in the database. This is equivalent to "disinfecting" the data entered by the user, the data input by the user is no longer of any special significance to the database, thus preventing attackers from injecting SQL commands. The System. Web. Security. FormsAuthentication class has a HashPasswordForStoringInConfigFile, which is very suitable for disinfecting input data.

Explain checks the number of records returned by the query for extracted data. If the program only needs to return one record, but the actual returned record is more than one row, it is treated as an error.