A question about token verification in the interface between APP and web server?

If I get all the parameters and headers such as api_token, user_token, etc. through packet capture, then in a short period of time, I can directly bring the parameters I obtained, and the verification rules will still pass. Can I use this interface? The only way I can think of is to shorten the token verification time. I wonder how the masters solved this problem?

Reply content:

This is what tokens do... aren't they just designed for you to use? The main purpose of designing the token is not to save the user's username and password for a long time, so it is converted into a random code. This code itself has the function of replacing the username and password, so once it is leaked, the natural consequences will be serious.
Nowadays, APIs with high security levels can generally only use HTTPS. In this way, the content of the connection cannot be captured from the middle of the path, so the token will not be leaked to others. As for the two ends, one is originally the user and the other is your own server. This token is the content that should be shared between both parties.
There was another design in the past that used two values ​​​​api_key and secret_key, where api_key is transmitted in clear text in HTTP, while secret_key does not appear in HTTP clear text, but participates as part of the MD5 Hash, generally the entire URL parameter Normalize (sort by parameter name, uniformly convert to lowercase, and correctly encode the URL), then add secret_key, calculate MD5, and then pass MD5 as an additional sig parameter through HTTP, so that even if the package is caught in the middle, it can only If you see api_key but not secret_key, you cannot use this interface freely. But this design has weaknesses for replay. Although I can't freely recombine parameters, I can reuse previously captured parameters, which is still unsafe; moreover, there is a lack of a means to safely distribute secret_key to the terminal. . So it is actually more effective to use HTTPS directly.

As a reference, let’s take a look at the design of OAuth 2.0. OAuth 2.0 is a third-party login that involves the relationship between users, authentication centers, and third-party applications. The problems it encounters are more complicated. We can see how it obtains the token and prevents the token from being leaked to parties that should not be leaked:

1. The OAuth server and the third-party server know the same api_key, secret_key at the same time
2. User and The third-party server knows the api_key at the same time (usually carried by a third-party application or Web page)
3. The user and the OAuth server know the same username and password at the same time, and the third-party application does not know
4. User application When a third party logs in, use api_key to call the OAuth server login interface (generally guided by a third-party application), use the OAuth server page to enter the username and password, and the OAuth server returns auth_code, which can be regarded as a temporary token. This step must use https to ensure that the username and password are not stolen.
5. Users use auth_code to call the interface of third-party applications (usually completed automatically by the callback mechanism). This step can use HTTP, so auth_code may be leaked
6. Third-party applications use auth_code api_key secret_key to call OAuth The second step of the server's login interface is to obtain the access_token, which is the official token. Although the auth_code may be leaked, since the secret_key cannot be obtained by the attacker, the auth_code cannot be used in exchange for the token. This step must use HTTPS to ensure that secret_key is not leaked.

At this point, the third-party application has successfully obtained the access_token, and this access_token is only shared between the OAuth server and the third-party server and will not be leaked to third parties including users. It can be seen that this process mainly relies on the encryption features of HTTPS to ensure that the most important data (username, password, secret_key) are not leaked. In addition, tokens with different security levels should have different timeouts. For example, auth_code has a very short timeout, while access_token has a relatively long timeout.

The interface uses https, and the captured packets are all garbled. But is there also a way to pretend to be a middleman? Thank you...
The most extreme method:
Each token is only valid once...

Of course, this involves a lot of read and write operations.
SO… I don’t usually do this… Random number plus token plus timestamp are used for md5 signature, and the signature, random number and timestamp are sent to the server together. This is not the case. On the server side, the session must be judged first, and only after passing it will it enter the token verification we wrote. 1: https;
2: The authentication module is independent, the token is entered into the session, and verified again. This is related to the design of the authentication;
3: The token is changed frequently, depending on the business importance;

The above personal opinions may not be rigorous.