How can I prevent SQL injection?

In the case of dynamically constructing SQL queries, replace all SQL special characters.

Use a stored procedure to execute any query. The way SQL parameters are passed will prevent attackers from using single quotes and hyphens to carry out attacks. In addition, database permissions can be restricted to only specific stored procedures, making it difficult to make it difficult to have an injection attack.

Limit the length of form or query string input or encrypt it. If the user's login name is only 10 characters at most, do not accept more than 10 characters entered in the form, which will greatly increase the difficulty for attackers to insert harmful ** into SQL commands.

Check the legitimacy of the user's input and be sure that the input contains only legitimate data. Data checks should be performed on both the client and server sides – server-side validation is performed to compensate for the weak security of the client validation mechanism.

Encrypt and store user login name, password, and other data.

6) Restrict the permissions of the database account used to execute the query. Perform query, insert, update, delete operations with different user accounts. By isolating what can be done by different accounts, it prevents the SELECT command from being used to execute the insert, update, or delete commands.

Use parameters. Don't use skewers.

With stored procedures, there is no problem with passing parameters.

In general, it is fine to use stored procedures.

Find a professional team or company to solve the problem for you.

All GET requests, as well as POST requests, filter for the input of illegal characters. 'Semicolon Filtering -- Filtering %20 special character filtering, single quote filtering, % percent sign, <>and filtering, tab key value and other security filtering. If you don't know too much about **, it is recommended to find a professional ** security company to deal with it, domestic SINE Security, NSFOCUS, Venustech, are all relatively good security companies.

1. Filter out some common database operation keywords: select, insert, update, delete, and, *, etc.

Or you can use the system function: addslashes (what needs to be filtered).

2. In the PHP configuration file.

register_globals=off;Set to Off action will register the global variable off.

For example, the value of the receiving post form is $ post['user'], if register globals=on; Use $user directly to receive the value of the form.

3. Try not to omit small quotation marks (the one above the Tab key) and single quotation marks when writing SQL statements.

4. Improve database naming skills, name some important fields according to the characteristics of the program, and take the ones that are not easy to guess.

5. Encapsulate the commonly used methods to avoid direct leakage of SQL statements.

6. Turn on PHP security mode.

safe_mode=on;

7. Open Magic Quotes GPC to prevent SQL injection.

magic_quotes_gpc=off;It is turned off by default, and it will automatically convert the query of the SQL statement submitted by the user when it is turned on'Turn to', which has a significant effect on preventing SQL injection.

So on: magic quotes gpc=on;

8. Control error messages.

Disable the error message and write the error message to the system log.

9. Use MySQLI or PDO preprocessing.

The input parameters strictly limit the format, size, reasonableness, and special characters.

SQL injection is not an unsolvable problem in SQL, and the existence of this attack method cannot be entirely attributed to the SQL language. First, a point I've made in other answers: no compilation, no injection.

The reason for SQL injection is similar to many other attack methods such as stack overflow and XSS, that is, unchecked or insufficiently checked user input data is accidentally executed. For SQL injection, the data submitted by the user is compiled by the database system and the developer does not expect. In other words, SQL injection is the data entered by the user, and in the process of splicing SQL statements, it goes beyond the data itself and becomes a part of the query logic of SQL statements, and then the SQL statements that are spliced in this way are executed by the database, resulting in actions that the developer does not expect.

Therefore, the fundamental means to prevent the above types of attacks is to avoid the data from being executed, and always distinguish the boundary between the data and the data. As far as SQL injection is concerned, the executed malicious ** is compiled by the database's SQL interpretation engine, so as long as the data entered by the user is avoided from being compiled by the database system.

Today's database systems provide the functions of pre-compilation (prepare) of SQL statements and binding of query parameters, and place placeholders in SQL statements'?', and then pass the SQL statement with placeholders to the database compiler, and only then pass the data entered by the user as an execution parameter to the user when executing. This operation not only makes the SQL statement no longer need to be spliced when writing, but also looks more direct, and the data entered by the user does not have the opportunity to be sent to the SQL interpreter of the database to be compiled and executed, and it will not become ** beyond the authority.

As for why this parameterized query method is not used as the default way, I think that in addition to being compatible with the old system, it is indeed convenient to use SQL directly, and there are definite use occasions.

To add a little more, from the point of view of **, the practice of splicing SQL statements is also inappropriate.

SQL Injection: The ability to leverage existing applications to inject (malicious) SQL commands into the backend database engine for execution, which is the standard definition of SQL injection.