Over the years, we have found that more and more companies have begun to focus on security testing. Why? Because security testing can check out some security vulnerabilities of your project to some extent, so that your system will be relatively safe after it goes online, and it is possible to avoid external attacks as much as possible. Every year, some major security incidents occur on the Internet, and the consequences of each time are very serious, and these lessons precisely illustrate the importance of security testing.
So what is a security test? The explanation given on Baidu Encyclopedia is: Security testing is a process in the life cycle of IT software products, especially from the completion of product development to the release stage, to inspect the product to verify that the product meets the definition of security requirements and product quality standards. According to the editor's understanding, in simple terms, security testing can be understood as follows: security testing is actually testing whether your system has security vulnerabilities. Ordinary testing aims at discovering BUGs, and security testing aims at discovering security risks.
So what can be tested in security testing? When we conduct security tests on a system, there are actually many things that should be considered, such as form attacks, sql injection, XSS attacks, CSRF attacks, brute force cracking, etc.
What I want to talk about today is SQL injection under security testing. Through learning, I will understand what SQL injection is. At the same time, I will explain common SQL injection scenarios and how to perform SQL injection based on several situations in the project. attack. First, let's take a look at what SQL injection is, and explain: SQL injection is to construct some special expressions or these special SQL commands, and submit them to the background server through a form. Finally, it can trick the server into executing malicious SQL commands, or reach a An effect of bypassing server verification.
The first more common injection scenario is the login function of the system. Of course, many large companies' projects are doing very well in this area, and they are also very safe. Very few vulnerabilities such as SQL injection are left, and some Small systems, small projects, or systems that you write to play with may have such security vulnerabilities. Here I wrote a simple login and registration function to help you understand what SQL injection is. The approximate logic is this: login is completed by entering the user name and password on the login page, and the background will get the data submitted by the front desk form to the database. Check and match, if the user exists, let the login succeed, if it fails to match, it will prompt "wrong user name or password". Then here we will implement SQL injection by constructing some special data or expressions. Now the editor will first post the front page of this login function and a few lines of key code in the background:
The following is the front desk login page:
The following is the key code for background login:
In fact, we see that the core code of this backend is actually to get the front desk user name and password to search the database to see if it exists, if it exists, let it go, and if it doesn't exist, it will prompt an error message. Then let's test the login. First, we use the registered user "[email protected]/111111" in the database table to log in:
Enter the user name "[email protected]" and the password "111111" on the login interface at the front desk, click login, and then we found that the login was successful. This result is normal.
Then let's try the wrong user name or password. Here we directly take a user "[email protected]/111111" that does not exist in the user table above to log in, and finally the result is "user name or password error", this The result is also normal.
The correct user name and password can log in successfully, and the wrong user name and password will fail to log in. It seems that there is no problem. Does that mean that the login function is free of bugs and loopholes? It is still too early to make a decision. We used normal data in the previous tests, not special and extreme data. Later we will enter some special data to continue the test. Before the test, let's analyze a line of core code for login. Our students with a little programming foundation can understand the database query code in the login logic below:
This line of code actually gets the user name and password passed in from the front end to splice a piece of SQL, and then execute this spliced SQL in the background to query whether such a user exists in the user table. It seems that there is nothing wrong with it. In fact, it is not. Seeing that the condition field in this sql is spliced with its value with a pair of single quotes. This is also easy to explain, because the string type condition field in the database needs to be accompanied by a value. For single quotation marks (a certain database foundation is required here, students who do not have this part of the foundation can add our test group, find the relevant administrator to learn this part of the database foundation video), and it is precisely because of this splicing writing method that leads to SQL injection The vulnerability exists because we can enter a special expression in the user name field of the front-end login page: 'or '1'='1, and fill in one of the passwords, such as 111111, then the server background will get it When the user name and password passed in at the front desk are used for sql splicing, the final sql obtained will be like this: select count(*) from nm_user where password='111111' and username='' or '1'='1' ; And such a SQL because there is an identical conditional expression: '1'='1', so you can find data from the user table anyway (as long as the user table has data), so it finally passed the server background The verification, login is successful, as shown below:
However, our database does not actually have such users. Here again attach the data of our user table:
However, such a user name is successfully logged in. This is SQL injection. By constructing some special expressions or special SQL and submitting to the background server through the form, the background server is tricked into executing such a malicious SQL or SQL with ulterior motives. To bypass server verification.
Okay, a simple example to illustrate what SQL injection is. I believe that everyone also has a certain understanding of this concept. Other SQL injection scenarios here will not be given as examples here. The examples are different, but the idea is The same, everyone can grasp the concepts and ideas of SQL injection. You can write a simple demo to verify, or use your own company's project to verify, there is no guarantee that such a problem can be reproduced, because such sql injection loopholes are still easy to avoid, directly use ibatis, mybatis, hibernate Related APIs of frameworks such as databases can circumvent such security vulnerabilities, because the underlying APIs for operating databases in these frameworks use PreparedStatement instead of Statement. One advantage of the former over the latter is that it provides a SQL pre-compilation mechanism. And a function of anti-injection.
Okay, this is the end of today's technical sharing of the editor. Next time, we will bring you XSS attacks on software security testing. Stay tuned.
Above are some videos and interview questions I collected.
For software testing friends, it should be the most comprehensive and complete interview preparation warehouse. In order to better organize each module, I also refer to many high-quality blog posts and projects on the Internet, and strive not to miss every knowledge point. Friends relied on these contents to review, and got offers from big factories such as BATJ. This warehouse has also helped many software test learners, and I hope it can also help you.
Follow my WeChat public account [Programmer Erhei] Get it for free