What is a BUG
A vulnerability is a defect in hardware, software, protocol implementation, or system security policy that allows an attacker to access or damage a system without authorization. For example, logical errors in Intel Pentium chip, programming errors in the early version of Sendmail, weaknesses in NFS protocol authentication and improper configuration in Unix system administrator setting anonymous Ftp service may be used by attackers, threatening the security of the system. Therefore, these can be considered as security loopholes in the system. In a narrow sense, bug refers to software program vulnerabilities or defects. In a broad sense, bug also includes the details of software that can be changed discovered and proposed by test engineers or users, or the implementation of functions that are different from requirements documents.
Simply put, the program doesn’t perform as you expect it to, or the program simply reports an error. In every programmer’s career will encounter more or less bugs, some people write the program bug is less, some people write the program bug is a lot of. This is because the breadth and depth of technology varies from person to person. Know the principle of technology to write the code will be fewer bugs, do not understand the principle of writing must be full of errors. But even if you’re technically proficient, bugs are inevitable.
Attitude towards bugs
I’ve seen countless programmers get nervous when they see a program go wrong, as if it would kill them. In fact, it is not terrible to report mistakes, but can be handled. You look where you see an error and you look where you see a line and you think about why that line is an error. Direct debug is not ok. It’s ok to report an error. Relax your mind and find it slowly. Bit by bit, find out why the error is reported. In fact, after doing it for a long time, I realize that the bug reporting error is not terrible at all, but the bug not reporting error is terrible. The logic is completely correct, but it does not follow your expectation. Bugs like this tend to make you doubt life.
How to find the BUG
The premise of finding bugs is to reproduce problems, many bugs are in specific circumstances will appear, just like we often encounter in their own computer no problem on other people’s computers, or in the external network environment no problem, not in the internal network environment. We encounter this situation to the first time to reproduce the problem, if you can’t reproduce the problem you certainly can’t solve. You can’t just sit around and debug yourself. Your environment is fine and you’re still debugging it on your computer. I’m surprised it works. You have to go to the problem of the environment to find problems, Intranet problems you go to the Intranet to reproduce the problem, reproduce and then compare with the difference between the external network slowly solve, must not produce fear of war psychology, in fact, a lot of problems as long as find the root of suddenly revealed.
A BUG that wasn’t easy to find
Last winter, the company arranged me to go to Harbin for training. Before the training, we tested the functions to be trained, and quickly changed the other problems. However, I encountered a problem: an interface requested the background, and the background took data from the session, but the session object in the background was always null. The default session expiration time is 30 minutes and I’m doing all the requests in the background, so there’s no way that the session will expire. I can do whatever I want locally. First, let’s talk about our environment. During development, we are a front-end project and a back-end project. The front-end system configuration menu, and the front-end directly requests the back-end to take data. And when we publish it, we have to add the front end page to another system, and the other system is a.NET system, and we configure the front end page address, menu name, permissions and so on in the.NET system. Those of you who often do background management systems should know that it is usually the top column menu and the left column menu. In the middle is the function page. The middle page is iframe, which is a system. But we are different, the top and left menu bar is the same system, the function page in the middle is embedded in our front system page address, the function page in the middle is also iframe. At first I felt ok with these, since the function page is iframe should be the same. But THERE’s no way I can reproduce it here. This is very helpless, find a bug you must find clues. I just looked at the request sent from the front page and looked at it for a long time before I found the problem.
So if we look at the response header we have a set-cookie and we’re giving the browser a Cookie. It doesn’t seem to be a problem, but I noticed that every request the back end gives the browser a Cookie with key JSESSIONID, and the header doesn’t send this Cookie to the back end every time. This is confusing. This explains why the Session object is null in the background. Now let’s find out why cookies are not sent to the background when the request is made. If we know why cookies are not sent, we will know the problem. Everything else is fine in the background when you’re giving cookies to the browser but SameSite=lax is something I don’t understand.
I found out what this property means by searching the question on My Baidu.
To put it simply, For the sake of security, Google does not allow cookies to be sent to the original page and iframe page requests of different sites after browser version 80. Because the menu bar and iframe published on our Intranet are two systems, that is, two sites, so the requests sent by iframe pages do not carry cookies. Naturally, the background can’t get the Session. The menu bar and iframe are one system in the development environment of the Internet, so the requests sent by iframe pages are all with cookies, which will not cause the background to fail to get the Session. So here we see the problem. Just figure it out from there.
In fact, this BUG seems very simple, but it is not. First of all, you need to reproduce the problem, and secondly, you must know the working principle of Session and Http protocol. If you do not understand the principle of these two technologies, you cannot find the problem.
There’s no system that works and doesn’t work
There is another problem, that is, we have two background systems deployed on one server, one system A occupies port 80, the other system B occupies port 8080. Some front-end pages request the backend of system A, and some front-end pages request the backend of system B. Other people told me that they often lost sessions (that is, the background can not get the Session object). Several people did not find the problem, but found me, in fact, I am very confused. But I do not agree with others, the system absolutely does not exist for a while can not, can have a reason, can not have a reason. Every cause has its effect. After my tests, it is ok to keep using the page of request SYSTEM A, and it is also ok to keep using the page of request system B. However, if you open the page of system B and then open the page of system A, an error will be reported. Then I discovered the problem. The first time I opened the page requesting system B, system B responded with a Cookie with key JSESSIONID to the browser, because the browser requested system B for the first time. JSESSIONID’s Path attribute is/and Cookie scope is not related to port. If we open the page requesting system A, we will also bring the JSESSIONID to the page, and this value is not related to system A, and system A will give the browser A new JSESSIONID. System A is not going to get sessions. The first step in the emergence of a BUG must be to reproduce, if the reproduce can not be found, followed by traces to find a way to find where is not normal, understand the principle. If I didn’t understand that Cookie scoped and port didn’t matter, I couldn’t figure out why.
If you like this article, please focus on your favorite collection. If you have any confusion, please comment.
Welcome to pay attention to earth gas programmer, public number, nuggets, blog garden, Jane book, CSDN of the same name.