Measures to defend against and check SQL injection attacks

Introduction: although many articles have discussed SQL injection, the content discussed today may help you check your servers and take corresponding preventive measures. Only those who know each other can win. First, you must know the types of SQL injection attacks.

Observing recent security events and their consequences, security experts have come to the conclusion that these threats are mainly caused by SQL injection. Although many articles have discussed SQL injection, the content discussed today may help you check your servers and take corresponding preventive measures.

Types of SQL injection attacks

Only those who know each other can win. First, you must know the types of SQL injection attacks.

1. escape characters are not properly filtered

When user input is not filtered for escape characters, injection attacks of this type will occur and it will be passed to an SQL statement. This will cause end users of the application to manipulate the statements in the database. For example, the following line of code demonstrates this vulnerability:

Statement: = "SELECT * FROM users WHERE name = '" + userName + "';"

This Code is designed to extract a specific user from its user table. However, if the user name is forged by a malicious user in a specific way, the operations executed by this statement may not be what the code author expects. For example, set the username variable (that is, username):

A' or 'T' = 'tat this time, the original statement has changed:

SELECT * FROM users WHERE name = 'A' OR 'T' = 'T ';

If this code is used in an authentication process, this example forces you to select a valid user name, because the value 'T' ='t is always correct.

On Some SQL servers, for example, in SQL Server, any SQL command can be injected using this method, including executing multiple statements. The username value in the following statement will lead to the deletion of the "users" table, and all data can be selected from the "data" table (actually, the information of each user is disclosed ).

A'; drop table users; SELECT * FROM data WHERE name LIKE '%

This will change the final SQL statement to the following:

SELECT * FROM users WHERE name = 'a'; drop table users; SELECT *

From data where name LIKE '% ';

Other SQL statements do not use multiple commands in the same query as a security measure. This prevents attackers from injecting completely independent queries, but does not prevent attackers from modifying queries.

2. Incorrect type handling

If a field provided by a user is not a strong type, or the type is not enforced, this type of attack will occur. When a numeric field is used in an SQL statement, this attack occurs if the programmer does not check the validity of user input (whether it is a numeric type. For example:

Statement: = "SELECT * FROM data WHERE id =" + a_variable + ";"

From this statement, we can see that the author wants a_variable to be a number related to the "id" field. However, if the terminal selects a string, it bypasses the need for escape characters. For example, if you set a_variable to: 1; drop table users, the "users" TABLE will be deleted FROM the database, and the SQL statement will be changed to: SELECT * FROM DATA WHERE id = 1; drop table users;

3. Database Server Vulnerabilities

Sometimes, there are also vulnerabilities in the database server software, such as the mysql_real_escape_string () function vulnerability in the MYSQL server. This vulnerability allows an attacker to execute a successful SQL Injection Attack Based on the wrong unified character encoding.

4. Blind SQL injection attacks

When a Web application is vulnerable to attacks and its results are invisible to attackers, a so-called blind SQL injection attack occurs. Web pages with vulnerabilities may not display data, but different contents are displayed based on the results of logical statements injected into valid statements. This attack is time-consuming because a new statement must be carefully constructed for each byte obtained. However, once the vulnerability location and target information location are established, a tool called Absinthe can automate this attack.

5. Conditional response

Note that there is an SQL injection that forces the database to calculate the value of a logical statement on a normal application screen:

SELECT booktitle FROM booklist WHERE bookId = 'ok14cd' AND 1 = 1

This leads to a standard surface, and the statement

SELECT booktitle FROM booklist WHERE bookId = 'ok14cd' AND 1 = 2 when the page is vulnerable to SQL injection attacks, it may give a different result. Such an injection will prove that blind SQL injection is possible. It will allow attackers to design a statement that can judge the authenticity of a field in another table.

6. Conditional errors

If the WHERE statement is true, this type of blind SQL injection will force the database to judge a wrong statement, resulting in an SQL error. For example:

SELECT 1/0 FROM users WHERE username = 'ralph '. Apparently, if the user Ralph exists, Division by zero will lead to an error.

7. Time Delay

Time delay is a blind SQL injection. According to the injection logic, it can cause the SQL engine to execute a long queue or a time delay statement. Attackers can measure the page loading time to determine whether the injected statement is true.

The above is only a rough classification of SQL attacks. However, technically, today's SQL Injection attackers are more intelligent and comprehensive in how to identify websites with vulnerabilities. Some new SQL attack methods have emerged. Hackers can use various tools to accelerate the vulnerability exploitation process. Let's take a look at the Asprox Trojan, which is mainly spread through a botnet that publishes emails. the entire working process can be described as follows: first, install the Trojan on the computer through Spam Sent by the controlled host. Then, the computer infected with the trojan will download a piece of binary code. When the trojan is started, it uses the search engine to search for websites with forms and vulnerabilities using Microsoft's ASP technology. The search result becomes a list of targets for SQL injection attacks. Then, this trojan will launch SQL injection attacks to these sites, so that some websites are under control and damaged. Users who access these controlled and corrupt websites will be deceived and download malicious JavaScript code from another site. Finally, this code directs the user to the third site, where more malware, such as password-stealing Trojans, are available.

In the past, we often warned or suggested Web application programmers to test and patch their code, although the probability of SQL injection vulnerability discovery and utilization is not too high. However, more and more attackers have recently discovered and maliciously exploited these vulnerabilities. Therefore, before deploying the software, developers should take the initiative to test its code and patch the code immediately after a new vulnerability occurs.

Measures to defend against and check SQL Injection

1. Filter statements using parameterization

To defend against SQL injection, user input cannot be directly embedded into SQL statements. On the contrary, user input must be filtered or parameterized. Parameterized statements use parameters instead of embedding user input into statements. In most cases, the SQL statement is corrected. Then, user input is limited to one parameter. The following is an example of using Java and JDBC APIs:

PreparedStatement prep = conn. prepareStatement ("SELECT * FROM USERS WHERE

PASSWORD =? ");

Prep. setString (1, pwd );

In general, there are two ways to ensure that the application is not vulnerable to SQL injection attacks. One is to review the code, and the other is to force the use of parameterized statements. Forcing parameterized statements means that the SQL statements embedded in user input will be rejected at runtime. However, there are not many such features currently supported. For example, the H2 database engine is supported.

2. Avoid using interpreter because it is exactly what hackers use to execute illegal commands.

3. Prevent SQL injection and avoid detailed error messages because hackers can use these messages. A standard input validation mechanism should be used to verify the length, type, statement, and enterprise rules of all input data.

4. Use professional vulnerability scanning tools. However, it is not enough to defend against SQL injection attacks. Attackers are currently Automatically Searching for attack targets and launching attacks. Its technology can even be easily applied to vulnerabilities in other Web architectures. Enterprises should invest in professional vulnerability scanning tools, such as the well-known Acunetix Web vulnerability scanning program. A complete vulnerability scan program is different from a network scan program. It specifically finds SQL injection vulnerabilities on the website. The latest vulnerability scan program can find the latest discovered vulnerabilities.

5. Finally, enterprises should implement code security checks at all stages of the Web application development process. First, security testing should be carried out before Web applications are deployed. This measure is more significant and far-reaching than before. Enterprises should also use vulnerability scanning tools and site monitoring tools to test websites after deployment.

The Web security pull alarm has sounded, and the security format is extremely serious. Enterprises should never rush to do so. Security is more important than Taishan!