Asp. NET program to prevent SQL injection attack method

It is not particularly difficult to prevent the ASP.net application from being hacked into by SQL injection, as long as you filter all the input before using the contents of the form input to construct the SQL command. 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 = '" Because the latter part of such 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. Encrypt the data entered by the user and compare it to the data saved in the database, which is equivalent to the user input

Data is "disinfected", 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.