Asp. How to prevent SQL injection attacks in net

Asp.net| attack

One, what is SQL injection-type attack?
A SQL injection attack is an attacker who inserts a SQL command into the input field of a Web form or a query string for a page request, tricking the server into executing a malicious SQL command. In some forms, user-entered content is used directly to construct (or affect) dynamic SQL commands, or as input parameters for stored procedures, which are particularly vulnerable to SQL injection attacks. Common SQL injection-type attack process classes such as:

⑴ a asp.net Web application has a login page that controls whether the user has access to the application, which requires the user to enter a name and password.

The content entered in the ⑵ login page will be used directly to construct a dynamic SQL command, or directly as a parameter to a stored procedure. The following is an example of the ASP.net application construct query:
Program code
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 to enter "' or ' 1 ' = ' 1" in the user's name and password input box.

⑷ user-entered content is submitted to the server
, the server runs the above asp.net code to construct the SQL command to query the user, but because the attacker's input is very special, the resulting SQL command becomes: SELECT * from Users WHERE login = ' or ' 1 ' = ' 1 ' and passwo rd = ' or ' 1 ' = ' 1 '.

The ⑸ server executes a query or stored procedure that compares the identity information entered by the user to the identity information stored in the server.

⑹ because the SQL command has actually been modified by a injected attack and cannot really authenticate the user, the system is incorrectly authorized to the attacker.

If an attacker knew that the application would direct the content entered in the form to the authenticated query, he would try to enter some special SQL string tampering query to change its original function and deceive the system to grant access.

The system environment is different and the attacker may cause different damage, which is determined primarily by the security permissions that the application accesses the database. If the user's account has an administrator or other higher-level permissions, the attacker might perform various actions that he wants to do on the table of the database, including adding, deleting, or updating data, and possibly even deleting the table directly.

Second, how to prevent?

The good news is that it's not particularly difficult to prevent asp.net applications from being hacked into SQL, so just filter all the input before you construct the SQL command with what the form enters. Filter input can be done in a variety of ways.

⑴ for dynamically constructing SQL queries, you can use the following techniques:

First: Replace single quotes, that is, to change all individual single quotes into two single quotes, to prevent the attacker from modifying the meaning of the SQL command. To take a look at the previous example, "SELECT * from users WHERE login = '" ' or ' 1 ' = ' 1 ' and password = ' ' or ' 1 ' = ' 1 ' "will obviously get with" select * from Users WHERE login = ' or ' 1 ' = ' 1 ' and password = ' or ' 1 ' = ' 1 ' ' different result.

Second: Delete all hyphens in user input to prevent attackers from constructing queries such as "SELECT * from Users where login = ' mas '--and Password = '", since the latter part of such a query has been commented out and no longer valid, attacking Anyone who knows a legitimate user login name does not need to know the user's password to gain access.

Third: Restrict permissions for the database account used to execute the query. Perform query, insert, UPDATE, delete operations with different user accounts. By isolating the operations that can be performed by different accounts, it prevents the original use of the Select command from being used to execute the INSERT, UPDATE, or delete commands.

⑵ uses stored procedures to execute all queries. The way SQL parameters are passed will prevent attackers from using single quotes and hyphens to implement the attack. In addition, it allows database permissions to be restricted to only specific stored procedure execution, and all user input must conform to the security context of the invoked stored procedure, making it difficult to inject attacks again.

⑶ limits the length of the form or query string input. If the user's logon name is at most 10 characters, do not endorse more than 10 characters entered in the form, which will greatly increase the difficulty of inserting unwanted code into the SQL command.

⑷ checks the legality of user input to make sure that the input contains only legitimate data. Data checking should be performed on both the client and server side-the reason for server-side validation is to make up for the fragile security of the client authentication mechanism.

On the client side, it is entirely possible for an attacker to obtain the source code of the Web page, modify the validation script (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 a validation operation is actually performed is to perform validation on the server side as well. You can use a number of built-in validation objects, such as RegularExpressionValidator, that automatically generate the client script for validation, but you can also insert a server-side method call. If you can't find a ready-made validation object, you can create one yourself by CustomValidator.

⑸ the user login name, password and other data encryption to save. Encrypting the data entered by the user and comparing it to the data stored in the database is equivalent to "sanitizing" the data entered by the user, and the data entered by the user no longer has any special meaning to the database, thus preventing an attacker from injecting SQL commands. The System.Web.Security.FormsAuthentication class has a hashpasswordforstoringinconfigfile that is ideal for disinfection of input data.

⑹ Check the number of records returned by the query that extracted the data. If the program only asks to return one record, but actually returns more records than a row, it is treated as an error.