Shulou(Shulou.com)06/01 Report--

This article mainly introduces the security handout of MySQL database, hoping to supplement and update some knowledge, if you have any other questions you need to know, you can continue to follow my updated article in the industry information.

In fact, that's all about database security, SQL injection. In the aspect of modern Web data security, a considerable number of companies actually do not attach importance to the problem of data security. According to foreign statistics, more than half of the websites may have SQL injection vulnerabilities.

For example, on November 30th, a famous company sent a text message inviting me to attend the Cloud products Summit, and received the url of the invited QR code text message. The IP address of this url will not be mentioned as the management backend (you should know who it is, and you will be responsible for reading this article on the website of others). Enter or 1 # 1 directly in the user name input box, and you don't even need to enter the password. The super administrator verifies it and goes directly to the administrator background.

In other words, who is to blame for SQL injection vulnerabilities?

Can you blame the operation and maintenance staff who are busy wiping their butts all day and night? Can you make fun of the DBA of the database?

Strictly speaking, they all have the responsibility to do a good job of safety. However, when it comes to essence, it really has nothing to do with them.

Sometimes, the program does a good job of filtering suspicious characters in the input box, or even adding a little more logical judgment, security can be completely avoided. But why don't they do this test, is it a matter of human security awareness, or do not know anything about SQL injection?

The essential cause of SQL injection vulnerability is not how negligent at the operation and maintenance level, but that programmers do not do a good job of filtering and logical problems. Why?

First of all, we need to clarify how to define the SQL vulnerability * *. The SQL vulnerability is essentially how to make full use of the logic of the program to do what they want to do for the people who want to do it.

So, whether we can do it or not is a matter of the program. Whether the program can be treated as a fool or not, it can do whatever it is told to do, and it can even do something with a hole.

This is the nature of exploiting SQL injection vulnerabilities. For example, some conference tickets and so on, troublemakers want tickets for free, and even want to resell tickets, want to log on to the administrator backstage, how to do?

This is obviously illegal, everyone is not stupid, this is not what you want to be able to post, is that right? But you have to find a "fool" to show up, and the troublemaker never plays his cards as usual. How can we guard against such troublemakers?

Log on to the website, you have to enter a user name and password to verify, as we all know. Assuming that there are only two input boxes: user name and password, how do you bypass this authentication?

So let's take a look at the principle of bypassing username and password authentication. When we enter the user name: hxf, the password is: 123, the program will be saved to the variable, $uname='hxf',$pass='123'. Click login at this time, the user name and password data will be submitted to the program.

So how does a program that is treated as a fool make a logical judgment? Let's look at a process similar to the following:

First, execute a SQL statement, such as sql= "selectcount (*) from users where uname=$uname and password=$pass", which means to check whether the user with this user name and password exists in the database, and then the program will logically judge based on the returned result. If the user name and password match, then the returned result must not be empty. If it is not empty, then log in and pass.

At first glance, there seems to be nothing wrong with this judgment process. So let's see how mischief is.

Enter directly in the user name input box: 1'or 1 characters 1 enter the password box without filling in any characters and enter directly. Through this direct verification, you can reach the administrator background and easily get web administrator privileges, and of course, there are other inputs with the same effect.

Why do you get Web administrator privileges in this way? Let's break down the action.

When the troublemaker enters "1'or 1" in the user name input box, it will be passed to the program in single quotation marks and become: $uname= "'1' or 1", $pass= "". This result will be passed to the SQL statement and executed in the database as follows: select count (*) from userswhere uname='1' or 1quote 1'. # and password= ", you can execute it below, this result obviously changes the logic, the result can not be empty, the logic of or is always true, the result can not be empty. Either empty or true, the administrator logged in successfully, especially if there is only one administrator in the table.

So how to prevent this kind of thing? There are a lot of loopholes in input validation here: multiple input boxes do not verify whether there is input or valid character checking. So the way to prevent it, on the one hand, is to do character filtering, similar single quotes and SQL keywords are prohibited. Of course, whether the two input boxes enter characters or not, and how many characters they enter, I should not educate the programmer.

To sum up, the essential cause of SQL injection vulnerabilities is actually our program problem, in the final analysis, it is still a problem of human consciousness, so there are still many SQL injection vulnerabilities on many websites. Most programmers, OPS and DBA actually don't know what the injection inside is. "inside MySQL injection Technology" takes the actual SQL injection * * as an example, how to master SQL injection * * step by step, how to counteract against * *, and how to make a safe defense. In fact, it is not intended to teach people about other websites, but how to prevent their own websites from being used by others. The knife is a sharp weapon, the bad guys can do bad things, and the good guys can defend themselves from the bad guys.

After reading the above security handouts on MySQL database, I hope it can give you some help in practical application. Due to the limited space in this article, it is inevitable that there will be deficiencies and need to be supplemented. If you need more professional answers, you can contact us on the official website for 24-hour pre-sales and after-sales to help you answer questions at any time.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.