SQL injection of "database" software security test

Over the years we've found that more and more companies are starting to focus on safety testing, why? Because the security test can somehow get rid of some of your project's security holes, so that your system is on-line to be relatively secure, it is possible to avoid external attacks. Every year there are major security incidents on the Internet, and the consequences of each are serious, and the lessons are all about the importance of security testing.

So what is a safety test? Baidu Encyclopedia on the explanation is: security testing is in the life cycle of it software products, especially product development basically completed to the release stage, the product inspection to verify that the product complies with the definition of safety requirements and product quality standards process. According to the small part of the understanding, simple point of view, in fact, the security test can be understood as follows: Security testing is actually testing your system for security vulnerabilities, common testing to find bugs as the goal, security testing to identify security risks as the goal.

So what can be tested for safety testing? There are a lot of things that we should consider when we are testing a system, such as form attack, SQL injection, XSS attack, csrf attack, brute force hack and so on.

What we're going to talk about today is SQL injection under security testing, learning what SQL injection is, and I'll combine several scenarios in the project to explain common SQL injection scenarios and how to execute SQL injection attacks. First, let's take a look at what SQL injection is, and explain: SQL injection is done by constructing some special expressions or some special SQL commands that are submitted to the backend server through the form, and eventually to the spoofing server executing a malicious SQL command, or to an effect that bypasses the server checksum.

The first more common injection scenario is the system login function, of course, now many large companies of the project in this piece is done very well, also do very safe, rarely leave SQL injection such loopholes, and some small system, small projects or the system of their own written to play may exist such a security vulnerability. Here I wrote a simple login registration function, to help you understand what is SQL injection, the logic is that: through the login page to enter a user name and password to complete the login, backstage will get the foreground form submitted data to the database to do check matching, if there is this user let login success, Prompt "Wrong user name or password" if the match is not reached. And here we are. SQL injection is implemented by constructing some special data or expressions. Now the small part of the login function of the front page and the background of a few lines of key code to paste out:

Here is the front desk login page:

Here is the background login key code:

In fact, we see the core code in the background is actually to get the foreground user name and password to the database to do a search, to see if there is a release, there is no prompt error message. Then we will test the login, first we take the database table has registered users "[email protected]/111111" To log in:

Front Desk Login Interface input user name "[email protected]", password "111111", click Login, and then we found that the successful login, the result is normal.

Then we will try the wrong user name or password, here we directly take a user table above the user "[email protected]/111111" To log in, the result is "user name or password error", the result is normal.

The correct user name password can log on successfully, the wrong user name password on the login failed, it seems that there is no problem, that means that the login function there is no bug no loopholes? It's still too early to make the decision, and we're doing tests that are normal data, not special, extreme data. Later we will enter some special data to continue the test. Before testing, we analyze the login line of core code, we have a little bit of programming based on the students can understand the following login logic in the database query code:

This line of code is actually to get the front end of the user name and password to join to get a SQL, and then in the background to execute the concatenation of SQL to query the user table whether there is such a user, there seems to be no problem, it is not, We see that the condition field in this SQL is joined to its value with a pair of single quotation marks wrapped up, this is also very good explanation, because the string type in the database after the condition field with the value of the need to bring a pair of single quotation marks (here need a certain database base, not this part of the base of the classmate can add our test group, Find the relevant administrator to the database base this part of the video to learn), and it is because of such a concatenation of the SQL injection vulnerability exists, because we can be in the front-end login page user name field input: ' or ' 1 ' = ' 1 such a special expression, password words to fill in a random, For example, or fill in 111111, the last server backstage to get the foreground incoming user name and password to do SQL splicing, the final SQL will be such a: SELECT COUNT (*) from Nm_user where password= ' 111111 ' and Username= ' or ' 1 ' = ' 1 ', and such a SQL because there is an identity conditional expression: ' 1 ' = ' 1 ', so in any case can be found from the user table data (as long as the user table has data), so finally through the server background check, login success, such as:

However, our database is actually not such a user. The data for our user tables is attached here:

And such a user name is logged in successfully, this is SQL injection, by constructing some special expressions or special SQL and then submit to the background server through the form, cheat the server to execute such a malicious SQL or an ulterior motive SQL to bypass the server checksum.

OK, simple example of what is SQL injection, I believe you also have a certain understanding of the concept, here are some other SQL injection scenario here is no longer a separate example, the example is changed, but the idea is unchanged, we will grasp the concept of SQL injection and ideas can be. You can write a simple demo to verify, or take their own company's project to verify that the issue is not guaranteed to reproduce, because such a SQL injection vulnerability is still very good to avoid, the direct use of Ibatis,mybatis, The related APIs of the Hibernate database and other frameworks can circumvent such security vulnerabilities because the API underlying the operational database in these frameworks is preparedstatement instead of statement, One advantage of the former relative to the latter is that it provides a mechanism for SQL precompilation and a function of anti-injection.

Source: Https://mp.weixin.qq.com/s/p8Kv89G-L3LIn6pWjizqow

SQL injection of "database" software security test