Some common solutions to prevent SQL injection, Web site security

--------------------------------------------------------
Filter some special characters in the URL, and the dynamic SQL statement uses preparestatement.
------Solution--------------------------------------------------------
The way to inject is to add SQL strings to the query criteria. You can check to see if the query parameter in the submission contains SQL, but this is usually useless.

The best way is not to use splicing SQL string, you can use Preparestatement, parameters are filled with the Set method
------ Solution--------------------------------------------------------
SQL injection form: ... where name= "+name+", such SQL statements are easy SQL injection , you can do this:
jdbctemplate.update ("Delete from userinfo where id=?"). And userid=? ", New Object[]{userinfo.getid (), Userinfo.getuserid ()});
Some of my code, look useful!
------Solution--------------------------------------------------------
SQL Injection Vulnerability attack: such as 1 ' or ' 1 ' = ' 1
using parameterized queries to avoid
cmd.commandtext= "SELECT COUNT (*) from table name where [ Email protected] and [email  Protected] ";
Cmd.parameters.Add (New SqlParameter ("a", ".."));
Cmd.parameters.Add (New SqlParameter ("B", ".."));
------Solution--------------------------------------------------------
Well, use the framework, with the JPA Pojo. There's no such thing.

How can SQL injection be prevented in the SSH2 architecture? And how do you design other related security issues?
The current security, just encrypt the user password, the foreground jquery authentication.
How to prevent injection attacks and my page some hidden fields save information such as the current logged-on user's information.
The user can view the page source code to see it.
Is there a good solution? What other places to pay attention to?
STRUTS2 hibernate3 Spring 3.0
SQL Server SP4

------Solution--------------------------------------------------------
1: Purchase certificate from CA, communicate with HTTPS to ensure security during network transmission
2: Avoid XSS injection (page echo input text, input hidden filter <, >, "," characters, etc.)
3: Use random keyboard or security control to prevent the keyboard Trojan record user's input
4: To write data in a cookie, use the HttpOnly attribute of the cookie as much as possible
5: In response set up some HTTP headers such as X-frame-options, X-xss-protection and other high-version browser support
6: Regardless of whether the client has done the data check, the server must have the data check (length, format, is required, etc.)
7:sql statement using PreparedStatement fill parameters, strictly prohibit the use of string stitching SQL or HQL statements

Six recommended prevention of SQL injection attacks
2009-04-01 14:38
SQL injection attacks are a great danger. Before explaining its prevention, it is important for database administrators to understand the rationale behind their attacks. This helps the administrator to take targeted prevention and control measures.
A simple example of a SQL injection attack.
Statement: = "SELECT * from Users WHERE value=" + a_variable + "
The above statement is a very common SQL statement, his main function is to let the user enter an employee number and then query the information of this employee. But if the statement is modified by a wrongful attacker, it could be the Black Hand that destroys the data. If the attacker enters the variable, enter the following SA001 ';d ROP table C_order--。 So the above SQL statement becomes a SELECT * from the Users where value= ' SA001 ';d ROP table C_order at the time of execution--。
What does this statement mean? ' A semicolon after the SA001 ' indicates the end of one query and the beginning of another statement. The double hyphen behind the C_order indicates that the remainder of the current line is just a comment and should be ignored. If the modified code is syntactically correct, the server executes the code. When the system is processing this statement, the query statement is executed first, and the user information of user number SA001 is found. The data then deletes the table C_order (the delete operation succeeds if there are no related constraints such as other primary keys). As long as the injected SQL code is syntactically correct, it is not possible to programmatically detect tampering. Therefore, you must validate all user input and carefully examine the code that executes the constructed SQL command on the server that you are using.
Second, the SQL injection attack principle.
It can be seen that SQL injection attacks are very harmful. Before explaining its prevention, it is important for database administrators to understand the rationale behind their attacks. This helps the administrator to take targeted prevention and control measures.
SQL injection is one of the most common attack methods for database. In this attack pattern, the attacker inserts some malicious code into the string. The string is then passed to an instance of the SQL Server database for analysis and execution through various means. As long as this malicious code conforms to the rules of the SQL statement, it will not be discovered by the system when the code is compiled and executed.
There are two primary forms of SQL injection attacks. One is to insert the code directly into a user input variable that is concatenated with the SQL command and makes it executable. The above example is the use of this method. Because of its direct binding with SQL statements, it is also known as direct injection attack method. The second is an indirect attack method that injects malicious code into a string to be stored in a table or stored as the original book. The stored string is connected to a dynamic SQL command to execute some malicious SQL code.
The injection process works by terminating the text string prematurely, and then appending a new command. As an example of a direct injection attack. is to use a semicolon to end the current statement when the user enters the variable. Then insert a malicious SQL statement. Because the inserted command may append additional strings before execution, the attacker often flags "-" with comments to terminate the injected string. When executed, the system will assume that the following statement is commented, so the subsequent text will be ignored, not compiled and executed.
Third, the prevention and control of SQL injection type attack.

Since SQL injection attacks are so harmful, how can we prevent them? The following recommendations may help database administrators prevent SQL injection attacks.
1, the ordinary user and the system administrator user's permission to have the strict distinction.
If an ordinary user embeds another drop TABLE statement with a query statement, is it allowed to execute? Because the drop statement is related to the base object of the database, the user must have permission to manipulate the statement. In the authority design, for the end user, that is, the application software users, there is no need to give them the database object creation, deletion and other permissions. So even when they use SQL statements with embedded malicious code, the code will not be executed due to restrictions on user permissions. Therefore, in the design of the application, it is best to distinguish between the user of the system administrator and the ordinary user. This minimizes the harm to the database caused by injection attacks.
2, forcing the use of parameterized statements.
If you are writing an SQL statement, the variables entered by the user are not embedded directly into the SQL statement. Instead of passing this variable through parameters, it is possible to effectively prevent SQL injection attacks. That is, the user's input must not be directly embedded in the SQL statement. In contrast, the user's input must be filtered, or a parameterized statement is used to pass a user-entered variable. Parameterized statements use parameters instead of embedding user input variables into SQL statements. With this approach, most SQL injection attacks can be eliminated. Unfortunately, there are not many database engines that support parameterized statements. However, the database engineer should use parameterized statements when developing products.
3, strengthen the validation of user input.
In general, the prevention and control of SQL injection attacks can be used in two ways, one is to strengthen the user input content inspection and validation, and the second is to force the use of parameterized statements to pass user input content. In SQL Server database, there are more user input content validation tools that can help administrators to deal with SQL injection attacks. Tests the contents of a string variable, accepting only the desired value. Rejects input that contains binary data, escape sequences, and comment characters. This helps prevent script injection and prevents certain buffer overflow attacks. Test the size and data type of the user input and enforce appropriate restrictions and conversions. This helps to prevent intentional buffer overflow, which is more effective in preventing injection attacks.
If you can use a stored procedure to validate the user's input. A stored procedure enables filtering of user input variables, such as rejecting some special symbols. As in the malicious code above, as long as the stored procedure to filter out the semicolon, then this malicious code will be useless. Before executing the SQL statement, some special symbols can be rejected through the database's stored procedures. Without affecting the database application, you should let the database reject input that contains the following characters. such as the semicolon delimiter, it is the primary accomplice of a SQL injection attack. such as the comment delimiter. Annotations are only used when the data is designed. The general user's query statement is not necessary to comment on the content, it can be directly rejected, and usually do so without accidental loss. By rejecting these special symbols, they will be useless even if the malicious code is embedded in the SQL statement.
The user input is always validated by testing the type, length, format, and range to filter what the user has entered. This is a common and effective measure to prevent SQL injection attacks.
4. Use the security parameters that are available from the SQL Server database.
To reduce the negative impact of injection attacks on SQL Server databases, a relatively secure SQL parameter has been specifically designed in the SQL Servers database. In the database design process, engineers should try to use these parameters to eliminate malicious SQL injection attacks.
The parameters collection is provided in the SQL Server database. This collection provides the ability to type check and length validation. If the administrator takes the Parameters collection, the user input is treated as a character value rather than as an executable code. Even if the user enters content that contains executable code, the database is filtered out. Because at this point the database only treats it as a normal character. Another advantage of using the Parameters collection is that you can enforce type and length checks, and values outside the range will trigger an exception. If the user enters a value that does not conform to the specified type and length constraints, an exception occurs and is reported to the administrator. In this case, if the employee number defines the data type as a string, the length is 10 characters. The user input is a character-type data, but it has a length of 20 characters. An exception is thrown at this point because the user enters content that is longer than the database field length limit.
5, multi-layered environment How to prevent SQL injection attack?
In a multi-tier application environment, all data entered by the user should be validated before being allowed into the trusted zone. Data that does not pass the validation process should be rejected by the database and an error message is returned up one level. Implement multilayer validation. Precautions taken against rogue malicious users may be ineffective against a determined attacker. A better approach is to validate the input at the user interface and at subsequent points across all cross-trust boundaries. Validating data in a client application can prevent simple script injection. However, if the next layer believes its input has passed validation, any malicious user who can bypass the client can access the system without restrictions. Therefore, in the multi-layer application environment, in order to prevent the injection attack, it is necessary to work together, the client and the database side should adopt corresponding measures to prevent the SQL statement injection attack.

Some common solutions for preventing SQL injection, Web site security