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

Before the title: this text is intended to be sent to the Kelai Forum (with purpose). As a result, the Kelai Forum has been completely silent and the administrator is missing. I have not finished my post for two months. I am extremely disappointed and feel that it has been written in vain. But at least it took some painstaking efforts to post the original article on the 51CTO blog and didn't bother to modify it.

Background: a website of operation and maintenance has been equipped with WAF equipment of Netgod Company. Due to the recent severe network security situation, in order to strengthen the network security protection capability, we began to try out a certain cloud WAF system (pointing the domain name resolution address to the cloud WAF system address, and the cloud WAF system is responsible for ferry). During this period, it was found that a small number of users could not log in, and the reason was unknown. The failure remains the same after switching back to the local area, but according to the webmaster, it can be accessed normally after clearing the browser cache or changing the browser.

After receiving feedback, because the fault can not be reproduced and the user computer for collecting information has not been found, the field engineer is unable to provide more valuable information and it is difficult to determine the specific cause of the fault. Due to the small number of visits to the website and the failure is not obvious, so leave it to be solved after the failure reappears (part of the reason is laziness). A few days later, I received feedback from local users and started work.

Scheduling process:

After the user's computer test, the use of the commonly used 360browser access is completely unresponsive, find out the IE browser access is normal (why? This has to ask 360 security guards).

Preliminary judgment is that the access was intercepted by the WAF system.

PING the domain name first, and find that the website domain name points to the local system, thus eliminating the possibility of direct interception of cloud WAF.

Log in to the local WAF device and find that the access to the user device is blocked because of cross-site scripting. Find out the cause of the failure.

Digression: friends must be very confused at this time, so why didn't this fault occur before? Is it possible that this kind of psychic event will occur after switching over cloud WAF? At this time, the engineer in charge of the network explained that when the local WAF is launched, some normal access to other protected websites will be blocked by some rules under the WAF cross-site scripting rule set. At that time, these rules were directly deleted to ensure the normal operation of the system. Now, due to network security reasons, these rules have been re-enabled the week before the trial of the cloud WAF system, which may be due to the small number of visits to the website. By the way, I am the one who is in charge of the network. I completely forgot about it before finding out the cause of the failure. Blame yourself for three seconds, and then begin to complain that too much work will really kill people, memory decline is serious, it is bound to be Alzheimer's in the future.

All right, back to the point. The cause of the fault has been found, how to solve it? Removing these rules again is really not in line with my professionalism, so I can only continue to dig deep into the cause of the fault.

The user cannot access it because it is blocked by WAF, so why is it blocked?

Check the WAF intercept log and there is no exception except for the intercept rules. I have no choice but to grab the bag at the scene. At this time, we solemnly recommend the network package capture software used: Kelai Network Analysis system 10 technology exchange version. I don't have the money to buy a professional version, but fortunately the technology exchange version is enough (so highly recommended, I only hope that the official staff of Kelai can enjoy buying the official version at a huge discount after seeing this post).

Open the 10 technical exchange version of Kelai Network Analysis system, enter the real-time analysis interface, click the open button to enter the package capture analysis interface, open the 360browser to directly access the domain name, the page cannot be opened, visit the / INDEX.DO page under the domain name, but still cannot be opened; then open IE, and both pages are accessed normally, click the stop button to end the package capture.

Click the TCP conversation bar in the analysis interface, enter the website domain name in the filter input box to filter, and then sort by package delivery time. The screenshot is as follows:

Click to view the access failure record and find that after the TCP connection is established normally, the access request cannot be sent to the server and is constantly retransmitted. The screenshot is as follows:

The screenshot of the normal access record is as follows:

Thus it can be seen that the first request to visit the site has been blocked by WAF. Next, compare the parameter differences between the two request packets.

The following is a screenshot of the parameters of the intercepted transaction request:

The following is a screenshot of accessing normal transaction request parameters:

By comparison, only the COOKIES parameters carried by the two transactions are significantly different:

Intercepted COOKIES parameters:

Cookie: UM_distinctid=15e78eb321b81-05b400905-4349052c-1fa400-15e78eb321e305; _ gscu_264088535=05267233ghc0ek25; _ _ guid=188558254.4450887942645648000.1505720364652.8474; CNZZDATA1254021662=1759409609-1505716920-http%253A%252F%252Fwww.XXXX.gov.cn%252F%7C1505716920

Access the normal COOKIES parameters:

Cookie: JSESSIONID=F91BD6BBF20E7FEF70066DD1CBB86819; CNZZDATA1254021662=2125437701-1505264969% 7C1505976274; _ gscbrs_264088535=1; UM_distinctid=15ea368883f9b-07964ba146a25f4-19704f6e-1fa400-15ea36888401c6; _ gscu_264088535=05980090ml7lf511; _ gscs_264088535=05980090gjxj3h21 | pv:5

From this we can see that:

The intercepted COOKIES parameter uses the URL escape character and escapes twice. (http%253A%252F%252Fwww.XXXX.gov.cn, of which% is% after% 25 is escaped) this COOKIES message is marked with CNZZ (home of the webmaster); (the word CNZZDATA is in the parameter)

It can be inferred that the COOKIES information in the access URL parameters has escape characters, which accords with one of the most basic characteristics of cross-site scripting * *. It is basically clear that normal access is blocked because the WAF interception rules are simple and rough. With the cooperation of the webmaster, it is clear that the code that leaves this COOKIES information is the visiting statistics code of the webmaster's house.

After testing, the COOKIES generated by normal access to this website does not contain escape parameters; only if the browser is not closed and continues to visit the website after logging in and logging out will generate COOKIES parameters such as blocked, which leads to access blocked by WAF, which is also the reason why only a small number of user visits are blocked.

Afterwards, after the webmaster replaced the webmaster's visit statistics code with Baidu access statistics code, the problem was solved.

The end of the story sighed: Kelai network analysis system is really easy to use, especially for friends who can't recognize a few English; (to reiterate: such a strong recommendation, only hope that the official staff of Kelai can enjoy buying the official version at a huge discount price after seeing this post); the WAF of the webmaster needs to be greatly improved; the statistical code of the webmaster's home needs to be updated; the work is too tricky and TM can't stand it.

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.