What is the principle of Tencent's click verification code?

There are still many technical details about the attack of forging network requests, and the space is limited. If you are interested, you can look at my blog, which contains some technical details about the verification code:

CSRF vulnerability principle

If I don't have a popular explanation for any of the technical terms mentioned, please reply below.

If it is too long and you want to get to the point, you can directly find the important content dividing line. Seeing that part is actually the core security mechanism of this verification code.

At present, the verification codes of web front-end are mainly divided into several categories:

1 See the figure, recognize it with the naked eye, and input characters;

2. Interactive operation between mouse and finger (mobile terminal) according to interface graphics;

3 SMS, telephone and email verification.

Article 3 is usually used in combination with article 1 to prevent SMS bomb attacks caused by CSRF vulnerabilities.

Including the user's unconscious man-machine inspection mode (in short, it is the front-end token+referrer judgment, which will be discussed later),

The ultimate goal of all the means mentioned above is to check whether the current visitor is a "person" or a "machine".

This is called Turing test in the field of computer research. Turing is a computer scientist. He put forward the definition of "artificial intelligence" as follows: If you put a computer in an isolated room and a person in an identical room at the same time, you can ask questions and test both the person and the computer. If the two reactions are basically the same (there will always be differences, even between people), then

Having said that, I still want to express one point. There are many researches on "making machines imitate human behavior" or "pretending to be adults" in the professional field. Nowadays, there are many things on the Internet, such as verification codes and security checks, which many people don't understand and think increase the cost for people to use the software normally. In fact, these security measures are to prevent hackers from using various technical means to forge network requests and pretend to be real users to "brush" various interfaces of websites.

Let's get back to the topic and talk about the technical implementation of Tencent verification code page mentioned by the subject.

Take a look at the source code of this page (for the web field, the source code of the page program is completely naked, which is different from the code of the client program, so if you want to study the other side's code, it is relatively easy for the web developer, in other words, the front-end code of the web does not have too many secrets, so the security of the web is relatively poor). This page is a very common one among some verification code systems I have seen, which is the aforementioned No.65438.

Let's look at the UI level, which is the most common. Callbacks are triggered by listening events that javascript binds to DOM. As shown in the figure, if I remove the click monitor in the red circle on the right and there is no response after clicking the button, then the logic of basically determining its verification code is unloaded from the callback function of CT_btn_trigger. Then look at the layer that pops up after clicking:

Are all implemented in DOM. I didn't find any trace of flash object in the code (why flash is mentioned, this is also mentioned later). After entering the verification code, I listened to the network packet and found the interface to send the verification code:

The interface of the server that accepts the verification code is /cap_union_verify_new, and the query field name of a verification code we just entered is ans. The network request here is transmitted through https protocol, including the entire qq security center page. The biggest difference between https protocol and the well-known http protocol is that it avoids the interception of data packets by the middle layer of the network through encryption, which is worthy of recognition for this group of verification codes. At present, many verification code systems do not have https for transmitting network requests of verification codes.

Last night, I took a cursory look and flipped through it, and found the core part of this verification code system, which is actually the collect field in the screenshot above. Thanks to @ Li Moran for reminding me, this part is actually the token mentioned in my last article. It is not difficult to guess from the name of the collect field that this token is a front-end assembly thing. I won't elaborate on how to assemble it here. Considering that it is a security center page after all, the technical details here are too thorough, and ordinary users don't care so much. Instead, it saves something for people with ulterior motives. So don't disturb the students in front of Tencent. Let's talk briefly here.

Collect parameters. When the user clicks this button, the server will send a collection parameter. At this point, some assembly and soft encryption processing are carried out in the collect parameter to get the ciphertext. It is not difficult to guess that it must be the URL of the picture wrapped with the verification code.

When the input verification code is completed, the request sent from the client to the server, although the verification code in the ans field is plaintext, still carries the collect field. At this point, the content of the collect field is different from the previous collect field, which is obviously an encrypted result. Presumably, the plaintext obtained after decryption by the server should at least contain some data of the user's local operation, including whether the picture corresponding to the verification code he entered is. Maybe the url of the picture is saved, maybe it is a set of key values of the picture recorded by the server, but this correspondence is definitely there.

The collect field mentioned above is actually the most critical point of the whole verification code system. In order to decipher this layer of defense of csrf, hackers first need to know how the two collect fields are encrypted. From the perspective of other system clients, it is not difficult to decipher this layer of encryption. However, because the code of the web client is a natural disadvantage of streaking, hackers can directly look at the source code, see how the collect field is assembled, and then combine the image recognition module to brush this interface. Because the verification code itself is the simplest picture 6-digit verification code, it is not very difficult to identify it in image processing.

Generally speaking, this verification code system is quite satisfactory, and it may not be taken seriously because it does not involve the security of the amount.

How to gracefully block Baidu advertising promotion

Let's briefly talk about several technical details encountered in the process of turning over the source code just now, which is worth knowing:

Is the verification code 1 safe?

Unfortunately, I am a person who likes to tell the truth. Such a verification code is not absolutely safe.

2 What is CSRF vulnerability?

CSRF is just a fake network request. In this way, hackers use scripts to write some automatic programs, and use the http interface called by normal users abnormally when accessing web pages, so as to achieve other purposes (stealing numbers, brushing interfaces, and even dragging servers to the library). This is the fundamental reason for adding the verification code to the web page, which increases the cost of the hacker's CSRF attack, because his automated script can send any user-related data, but it is difficult to guess the characters in the graphic verification code that appears randomly every time.

3 What are the security risks of such a verification code?

Simple graphic verification code is not safe now, because with today's image recognition technology, hackers can construct an automatic script, first get the picture of verification code, then give it to a program module specializing in image recognition for recognition, return a recognition result, and then backfill the recognition result into the parameters of http request like normal users fill in verification code. We can see that he directly put the characters of the verification code into the parameters of the http request without any md5 or AES processing, so the hacker can easily know what this parameter is and construct the above-mentioned automatic penetration tool. To attack the server. The ability of his image recognition algorithm does not need to be as high as 90% to 80%. Even with the accuracy of 10%, hackers can distribute such a set of script attack programs on machines in various computer rooms, causing certain attacks on servers. Whether the qq security center page you see is safe or not really has no difference between yes and no, only the value is not worth it. After all, with the current technology, the cost of building a set of automatic attack programs mentioned above is still very high. But it is not impossible. This also explains why 12306 issued such a set of abnormal verification codes when Spring Festival travel rush grabbed tickets, because the benefits of grabbing tickets were too great. If someone can decipher its verification code system, the loss is unacceptable to the railway department. It is better to let ordinary users ask for it, and never leave an opportunity for hackers' automated attack programs.

4 why do you want to mention flash?

As a technology troubled by many security vulnerabilities in the software industry, flash can be regarded as a silver bullet in the web field in a sense, at least I think so. Why do you say that? As I just said, in the software industry, there are no secrets in the client code. You really want to protect some code logic with a very high security level, which is reliable only when it is put on the server. This is why everyone will be given a U shield when applying for an online banking card, because the software client is always unsafe, or it is not safe enough in front of hackers compared with the benefits of such a large-scale transaction. Therefore, it is necessary to rely on the hardware encryption means of U shield to weld some important encryption logic in the chip for curing protection. On the other hand, why should we say that flash is safe in the web field? Because the web is too insecure, as a client, all its code is streaked, unpacked and not compiled. (Some people may mention packaging tools such as webpack today, but the practical significance of those things lies not in packaging, but in modularity. The popular explanation is that any engineer who knows the front-end js code can learn what the front-end code of other websites has done at a very low cost, which is relative to the client development of other platforms.

Therefore, many websites will write some data that they don't want others to "steal easily" into a flash client, and then load the swf packaged after flash compilation into the page as a static resource (because browsers now support flash), so that flash can interact with users. If you want to disassemble flash, it is much higher than the html and javascript code of the web front-end for engineers who are also engaged in flash AS development and web front-end development.

In addition, most web engineers today are not familiar with flash code, so it makes sense to regard flash as a silver bullet for some security risks in web systems. Here, I can give an example of online music. Cool dog music is to decode an audio file in acc format (special audio format, which ordinary browsers and players can't play directly) through flash player, so as to realize the anti-piracy version of music songs. Because even if you get the URL of his audio file and download it, you can't play it directly.

For this part, I won't digress.