SQL injection attack: a means of defending and checking SQL injection

Although there are many previous articles that discuss SQL injection, the content discussed today may help you check your server and take precautions. TSE, you can win. The first thing to understand is what kind of SQL injection attack is.

Looking at recent security incidents and their aftermath, security experts have come to the conclusion that these threats are mainly caused by SQL injection. Although there are many previous articles that discuss SQL injection, the content discussed today may help you check your server and take precautions.

Types of SQL injection attacks

TSE, you can win. The first thing to understand is what kind of SQL injection attack is.

1. Escape characters are not filtered correctly

This form of injection attack occurs when the user's input is not filtered for an escape character, and it is passed to an SQL statement. This causes the end user of the application to manipulate the statements on the database. For example, the following line of code demonstrates this vulnerability:

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

This code is designed to take a particular user out of its user table, but if the user name is forged in a particular way by a malicious user, the statement may perform an action that is not just what the author of the code expects. For example, set the user name variable (that is, username) to:

A ' or ' t ' = ' t, at which point the original statement has changed:

SELECT * from users WHERE name = ' a ' OR ' t ' = ' t ';

If this code is used for an authentication process, then this example can force a valid username to be chosen because the assignment ' t ' = ' t is always correct.

On some SQL Servers, as in SQL Server, any SQL command can be injected through this method, including executing multiple statements. The value of the username in the following statement will result in the deletion of the users table and the selection of all the data from the "Data" table (which in fact reveals each user's information).

A ';D ROP TABLE users; SELECT * FROM data WHERE name like '%

This turns the final SQL statement into the following:

SELECT * from users WHERE name = ' A ';D rop TABLE users; SELECT *

From DATA WHERE name is like '% ';

Other SQL executions do not use multiple commands in the same query as a security measure. This prevents an attacker from injecting a fully independent query, but does not prevent an attacker from modifying the query.

2.Incorrect type Handling

This form of attack occurs if a user-supplied field is not a strong type, or if the type coercion is not enforced. This attack occurs when a numeric field is used in an SQL statement, and if the programmer does not check the legality of the user's input (whether it is a numeric type). For example:

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

As you can see from this statement, the author wants a_variable to be a number related to the "id" field. However, if the end user chooses a string, it bypasses the need for the escape character. For example, set A_variable to: 1;drop table users, which deletes the users table from the database, and the SQL statement becomes: SELECT * from DATA WHERE id = 1;drop table users;

3. Vulnerabilities in the database server

In some cases, 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 uniform character encoding.

4. Blind SQL injection type attack

A so-called blind SQL injection attack occurs when a Web application is vulnerable and its results are not visible to the attacker. A vulnerable web page might not display data, but instead display different content based on the results of a logical statement injected into a legitimate statement. This attack is time-consuming, because a new statement must be constructed carefully for each byte that is obtained. But once the location of the vulnerability and the location of the target information are established, a tool called Absinthe can automate this attack.

5. Conditional response

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

SELECT booktitle from Booklist WHERE bookid = ' ook14cd ' and 1=1

This would result in a standard quilt, while the statement

SELECT booktitle from Booklist where BookID = ' ook14cd ' and 1=2 it is possible to give a different result when the page is vulnerable to SQL injection attacks. Such an injection would prove that a blind SQL injection was possible, which would allow an attacker to design statements that could be judged to be authentic based on the contents of a field in another table.

6. Conditional errors

If the WHERE statement is true, this type of blind SQL injection forces the database to judge a statement that causes the error, resulting in a SQL error. For example:

SELECT 1/0 from users WHERE username= ' Ralph '. Obviously, if the user Ralph exists, being 0 will cause an error.

7. Time delay

Time delay is a blind SQL injection that, depending on the injected logic, can cause the SQL engine to execute a long queue or a time delay statement. An attacker could measure the time the page was loaded to determine whether the injected statement was true.

The above is just a rough classification of SQL attacks. But technically, today's SQL injection attackers are smarter and more comprehensive about how to find vulnerable sites. Some new methods of SQL attack have emerged. Hackers can use a variety of tools to speed up the exploit process. Let's take a look at the Asprox Trojan, which is mainly spread through a spam-sending zombie network, and its entire work can be described as follows: first, the Trojan is installed on the computer by a spam message sent by a controlled host, and then The computer infected by this Trojan downloads a piece of binary code that, when it starts, uses a search engine to search for a vulnerable web site using Microsoft's ASP technology to create a form. The result of the search is a list of targets for SQL injection attacks. The Trojan will then launch a SQL injection attack on these sites, allowing some sites to be controlled and corrupted. Users who visit these controlled and compromised sites will be tricked into downloading malicious JavaScript code from another site. Finally, this code will guide the user to the third site, there are more malicious software, such as password-stealing Trojan.

Previously, we often warned or recommended that the Web application's program members test and patch their code, although the chances of SQL injection vulnerabilities being discovered and exploited are not too high. But recently, attackers are increasingly discovering and maliciously exploiting these vulnerabilities. Therefore, before deploying its software, developers should be more proactive in testing their code and patching up the code as soon as new vulnerabilities emerge.

Ways to defend and check SQL injection

1. Using Parameterized filtering statements

To defend against SQL injection, the user's input cannot be directly embedded in the SQL statement. On the contrary, user input must be filtered, or parameterized statements should be used. Parameterized statements use parameters instead of embedding user input into statements. In most cases, the SQL statement is fixed. User input is then limited to one parameter. Here is an example of using the 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 an application is not susceptible to SQL injection, one is to use code review, and the other is to force parameterized statements. Forcing the use of parameterized statements means that SQL statements that embed user input are rejected at run time. However, there is not much support for this feature at this time. such as the H2 database engine is supported.

2. There is also a need to avoid the use of interpretative procedures, which are the means by which hackers execute illegal orders.

3. Prevent SQL injection, but also avoid some detailed error messages, because hackers can use these messages. Use a standard input validation mechanism to validate the length, type, statement, and enterprise rules of all input data.

4. Use a professional vulnerability scanning tool. But defending against SQL injection attacks is not enough. attackers are currently automatically searching for targets and attacking them. Its technology can even be easily applied to vulnerabilities in other web architectures. Enterprises should invest in some professional vulnerability scanning tools, such as the famous Acunetix Web Vulnerability scanner. A perfect vulnerability scanner is different from a network scanner, which specifically looks for SQL injection vulnerabilities on a Web site. The latest vulnerability scanner can look for newly discovered vulnerabilities.

5. Finally, the enterprise will implement code security checks at all stages of the Web application development process. first, to implement a security test before deploying a Web application, this measure is more significant and far-reaching than ever before. The enterprise should also test the site with vulnerability scanning tools and site monitoring tools after deployment.

The Web security pull alarm has sounded, the security form is extremely serious, the enterprise should never haste. Safe and heavy!