SQL Injection for Data room charging systems

When I was working on the student information management system, many people mentioned this issue. However, I did not go into the details. Later, the Ministry of Railways purchased tickets online with SQL injection. It is said that this problem belongs to the cainiao level. Then, during the acceptance, the master told me about the SQL Injection problem, so I had this article that someone else had written for a long time.

First, let's talk about SQL injection. SQL injection is an attack method in which malicious code is inserted into a string and then transmitted to the SQL server instance for analysis and execution. Injection vulnerability check should be performed for any process that constitutes an SQL statement, because SQL server will execute all the syntaxes it receives for effective queries. An experienced and determined attacker can even operate on parameterized data. Simply put, attackers can use SQL injection to operate your database illegally. As long as the injected SQL code syntax is correct, tampering cannot be detected by programming. Therefore, you must verify all user input and carefully check the construction performed on your server
SQL command code. The following is a summary of how to prevent SQL Injection for online queries.

Prevent SQL injection:

1) verify all inputs: user inputs are always verified by test type, length, format, and range.

Do not make any assumptions about the size, type, or content of the data received by the application.

Test the input size and data type, and enforce appropriate limits. This helps prevent intentional Buffer Overflow.

Test the content of the string variable and only accept the required value. Reject input content that contains binary data, escape sequences, and comments. This helps prevent Script Injection and some buffer overflow attacks.

When using XML documents, all input data is verified based on the data architecture.

Do not directly use user input to generate a Transact-SQL statement.

Use stored procedures to verify user input.

In a multi-tier environment, all data should be allowed to enter the Trusted Zone after verification. Data that did not pass the verification process should be rejected and an error will be returned for the previous layer.

Implement Multi-layer verification. Preventive measures taken against malicious users with no purpose may be ineffective for a strong attacker. It is better to verify input on the user interface and all subsequent points across the trust border.

Do not concatenate unverified user input. String concatenation is the main input point for script injection.
If possible, reject input that contains the following characters: ";", "", "XP _"

2) parameter input in Stored Procedures: if stored procedures are used, parameters should be used as input in stored procedures.

3) Use a parameter set in dynamic SQL

4) use quotename () and replace () to wrap Parameters

Some of the above content is not understood yet, such as stored procedures, and has not been used in the database. Therefore, we need to wait for a while to learn.