In website development, we may accidentally cause a security problem to people. Below I will introduce a summary of some commonly used SQL injection attack methods. Novice friends can try to refer to it.
1. Escape characters are not filtered correctly
This form of injection or attack occurs when user input is passed to a SQL statement without escape character filtering. This results in end users of the application performing operations on statements on the database. For example, the following line of code demonstrates this vulnerability:
The code is as follows | Copy code | ||||
|
代码如下 | 复制代码 |
SELECT * FROM users WHERE name = 'a' OR 't' = 't'; |
The code is as follows | Copy code |
SELECT * FROM users WHERE name = 'a' OR 't' = 't'; |
If this code was used in an authentication process, then this example would be able to force the selection of a valid username, since the assignment 't' = 't' would always be correct.
代码如下 | 复制代码 |
a';DROP TABLE users; SELECT * FROM data WHERE name LIKE '% |
The code is as follows | Copy code | ||||
a';DROP TABLE users; SELECT * FROM data WHERE name LIKE '%
|
Makes the final SQL statement look like this:
The code is as follows | Copy code |
SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM data WHERE name LIKE '%'; |
Other SQL implementations do not execute multiple commands in the same query as a security measure. This prevents an attacker from injecting a completely independent query, but it does not prevent an attacker from modifying the query.
代码如下 | 复制代码 |
"SELECT * FROM data WHERE id = " + a_variable + ";" |
The code is as follows | Copy code |
"SELECT * FROM data WHERE id = " + a_variable + ";" |
As can be seen from this statement, the author hopes that a_variable is a number related to the "id" field. However, if the end user selects a string, the need for escape characters is bypassed. For example, set a_variable to: 1; DROP TABLE users, it will delete the "users" table from the database, and the SQL statement becomes:
The code is as follows | Copy code | ||||
|
Sometimes, there are vulnerabilities in database server software, such as the mysql_real_escape_string() function vulnerability in MYSQL server. This vulnerability allows an attacker to perform a successful SQL injection attack based on incorrect Unicode encoding.
4. Blind SQL injection attack
So-called blind SQL injection attacks occur when a web application is vulnerable to an attack but the results are invisible to the attacker. A vulnerable web page may not display data, but instead display different content based on the results of logical statements injected into legitimate statements. This attack is quite time-consuming because a new statement must be carefully constructed for each byte obtained. But once the location of the vulnerability and the location of the target information are established, a tool called Absinthe can automate the attack.
5. Conditional response
Note that there is a SQL injection that forces the database to evaluate a logical statement on a normal application screen:
代码如下 | 复制代码 |
SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=1 |
The code is as follows | Copy code |
SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=1 |
This results in a standard screen, while the statement
SELECT booktitle FROM booklist WHERE bookId = 'OOk14cd' AND 1=2 It may give a different result when the page is vulnerable to SQL injection attacks. Such an injection will prove that blind SQL injection is possible, which will allow the attacker to design a statement that can judge the authenticity based on the content of a certain field in another table.
6. Conditional errors
代码如下 | 复制代码 |
SELECT 1/0 FROM users WHERE username='Ralph'。 |
Obviously, division by zero will cause an error if user Ralph exists.
7. Time delay
Time delay is a kind of blind SQL injection. Depending on the injected logic, it can cause the SQL engine to execute a long queue or iyige time delay statement. An attacker can measure the time it takes for a page to load to determine whether the injected statement is true.
The above is only a rough classification of SQL attacks. But technically speaking, today's SQL injection attackers are smarter and more comprehensive in how to find vulnerable websites. Some new SQL attack methods have emerged. Hackers can use a variety of tools to speed up the vulnerability exploitation process. We might as well take a look at the Asprox Trojan, which is mainly spread through a botnet that publishes emails. Its entire working process can be described as follows: First, the Trojan is installed on the computer through spam emails sent by the controlled host. A computer infected by this Trojan then downloads a piece of binary code that, when launched, uses the seo/seo.html" target="_blank">search engine to search for vulnerable websites that use Microsoft ASP technology to create forms. The search results become a target list for SQL injection attacks. Then, the Trojan will launch SQL injection attacks on these sites, causing some websites to be controlled and damaged. Users who visit these controlled and damaged websites will be deceived. A piece of malicious JavaScript code is downloaded from another site. Finally, this code directs the user to a third site, which contains more malware, such as a password-stealing Trojan
.In the past, we often warned or recommended web application programmers to test and patch their code, although the probability of SQL injection vulnerabilities being discovered and exploited was not very high. But recently, attackers are increasingly discovering and maliciously exploiting these vulnerabilities. Therefore, developers should be more proactive in testing their code before deploying their software and patching the code as soon as new vulnerabilities emerge.
For example, some people may use this method to bypass the login window. If your query username and password look like this:
The code is as follows | Copy code | ||||
[code='sql']
|
Since the empty string is always equal to the empty string, the query condition is always true. Therefore, it can be seen that the risk of MySQL injection is still very high, because the attacker can see the data that should be accessed through logging in. It is very important to protect your website from injection attacks. Fortunately, PHP can help us prevent injection attacks.
MySQL will return all rows in the table. Depending on your program logic, all users may be logged in because they are all matched. Now, in most cases, people will turn on the magic_quotes_gpc option (which is also the default in PHP). Such a configuration will automatically add backslashes and escape all '(single quotes), "(double quotes), (backslashes ) and null characters. But things are not that simple to solve, because not all characters that cause risks are escaped. PHP has a function that can escape all MySQL characters that may cause redundant SQL clauses. This function is mysql_real_escape_string().
Be careful when using this function, because you may have turned on the magic_quotes_gpc option, and using mysql_real_escape_string() will cause a second escape. The following function avoids this problem by first judging
Whether the magic_quotes_gpc option is turned on, and then decide whether to execute mysql_real_escape_string().
[code='php']
The code is as follows | Copy code
|
||||
//Add quotes to variables to ensure safety function quote_smart($value) { $link=mysql_connect('mysql_host','mysql_user','mysql_password'); //De-escape |
if(get_magic_quotes_gpc())
//Quote all non-digits
In addition, it should be noted that because different MySQL versions have different filtering requirements, mysql_real_escape_string() requires a MySQL connection to work, so a MySQL connection must be passed in as the second parameter. If MySQL is installed on the local machine, it can be omitted. However, if MySQL is not installed on the local machine or is connected to MySQL remotely, this parameter is essential, otherwise mysql_real_escape_string() will return an empty string.