Graphic | replay attack is what - Moment For Technology

1. Xiao Hei’s troubles

Baymax and Hei are good workmates. Hei recently moved to a head Internet company, which is engaged in e-commerce, and is still on probation.

A few days ago, because of an interface security problem, xiaohei almost did not go through the probation period, it is not easy.

Let’s see how it works:

The original black interface encountered a replay attack, let us help black together!

2. What is replay attack

2.1 Definition of replay attack

Replay Attacks, also known as Replay Attacks or Replay Attacks, refer to Attacks in which an attacker sends a received packet to cheat the system. These Attacks are mainly used for identity authentication and undermine the correctness of authentication. A replay attack can be carried out either by the originator or by an enemy intercepting and retransmitting the data. Attackers use network monitoring or other means to steal authentication credentials, and then re-send it to the authentication server. Replay attack can occur in any network communication process and is one of the common attack methods of hackers in the computer world.

– Replay attack means that the attacker repeatedly requests the packets received by the server. Since they are legitimate packets that have been received, the server can pass identity authentication if it is not properly guarded.

The attackers of replay attacks can be legitimate clients, such as your external partner who mistakenly circulates the same data 100 times, or the client and server interaction is intercepted and attacked by a middleman.
Replay attack is very common, it is a common attack defense, interface security design must take into account.

After understanding the concept of replay attacks, let’s first look at how Hei designed the interface, and then see what the problem is and what the solution is.

2.2 Design scheme of Xiao Hei

The interface designed by Xiahei is for accessing external data. There are many access parties and large amount of data push.

– Assign a unique datA_FROM field to each access party. – Assign a unique 32-bit secret_key field to each access party. – There are several required fields in the interface, and the string SEG_str is generated in lexicographical order

data_from=abc&data_type=input&data_time=1634365534&interface_name=xyz
Copy the code

Evaluates the signature sign value and converts it to hexadecimal lowercase

md5(seg_str&secret_key=xxxxxx).hex().lower()

The access party transmits plaintext according to the rules. After receiving the required fields, the small black server generates seg_STR in the same lexicality order, and then adds the secret_key of the corresponding account to calculate the sign value.

Hei compares the sign calculated by the server with the sign carried in the request. If the request is consistent, it is considered as a legitimate request and the request is processed normally.

The scheme body is fine, and the authentication logic is similar to that of digital certificates, but there are some holes.

2.3 Loopholes of Xiaohei’s scheme

In fact, whether the access party’s packets are symmetrically encrypted does not solve the problem of replay attack.

Because replay attackers don’t care what the content is, they simply send the requested data again, which is why replay attacks are named.

Given the nature of the replay attack, encrypted transmission is not a vulnerability. Let’s move on.

Vulnerability 1 Limitation of the request time range on the interface. For example, some access parties are lazy and only pass a fixed data_time for each request, which makes it impossible to distinguish an old request from a new one.
The identity verification of vulnerability 2 only has the value of sign. Even if the sign comparison is correct, it still cannot be determined as the reasonable behavior of the access party, that is, it cannot be determined whether the request has occurred, which is similar to the feeling of interface idemidematism.

Some friends may ask, what’s wrong with repeating requests?

In fact, some interface repeated requests no problem, but small black data interaction interface, repeated requests is a problem, on the one hand to the system load, and on the other hand, data will be repeatedly updated in the database, if the plaintext is tampered with, the problem will be more obvious.

To sum up, in combination with the definition of replay attack, small black design scheme, scheme vulnerability, etc., we make it clear that the interface of small black has replay attack risk and is attacked.

So how do you avoid replay attacks?

3. Solutions to replay attacks

A replay attack can also be considered a man-in-the-middle attack if it is carried out by a man in the middle of the intercepted data.

Generally speaking, replay attack does not involve the tampering of packet content, so it is a simple manin-middle attack. Reasonable use of ciphertext transmission can effectively solve the problem of ciphertext tampering.

Depending on the nature of the replay attack, the solution is obvious: determine if the request already exists, reject it, and allow new requests.

3.1 Scheme 1: Uniquely mark each request

The most straightforward solution is to let the requester add a globally unique flag, uniqe_key, which the server only needs to determine if uniqe_key exists.

If uniqe_key is already present, the request is considered old and rejected.
If uniqe_key does not appear, it is considered a new request and passes directly.

But the solution sounds simple, but it’s a bit laborious in practice. – How to generate uniqe_key (uniqe_key, uniqe_key, uniqe_key, uniqe_key);

The server needs to hold all the uniqe_keys, and it is continuously growing. Considering the O(1) query requirement, it is usually implemented in NoSQL, which requires a lot of storage.

Therefore, this solution is good to listen to, the storage and query costs are high, the high request scenario may not work.

3.2 Solution 2: Strictly limit the request time

The server obtains the data_time timestamp from the request. If the difference between the request timestamp and the server timestamp exceeds a certain range, such as 60 seconds, it is considered illegal.

Some friends may ask, why do we need to set the 60s wave?

Time benchmarks on the client and server may be different, including NTP time synchronization and time zone
The network interaction between the client and the server also takes time, and the two may not be identical, but a second timestamp is acceptable considering network latency of tens of milliseconds.

This works a little better, but there is no guarantee of consistency between the client clock and the server clock, that is, it is difficult to set the fluctuation time to 1 minute or 1 hour.

If the tolerance of time difference is set to 10 minutes, replay attacks within 10 minutes are inevitable.

3.3 Scheme 3: Time limit + Unique/random String

Although plan 1 and Plan 2 have obvious problems, the ideas can be used for reference.

Combining plan 1 and Plan 2, a new plan emerges: time limit + unique tag/random string.

Set the tolerance range of the request time and server time to 15 minutes. Requests exceeding 15 minutes are rejected
If the difference between the client time and the server time is less than 15 minutes, the sep_key is used to limit the time. If the sep_key is used within 15 minutes, the sep_key is rejected.

Random strings or unique tokens are more practical, either by means of the generated sign value, or by adding a new nonceStr field, which is stored by account and stored in Redis by increasing the expiration time.

The highlight of this scheme is the use of random strings or unique tags to eliminate the time fluctuation range of replay attacks, storage and random number generation scheme is very simple.

In actual scenarios, scheme 3 is widely used, which is an effective scheme.

3.4 Aliyun API gateway solution

When the client invokes the API, it needs to add the calculated signature to the request. After receiving the request, the API gateway uses the same method to calculate the signature. If the request is identical with the signature calculated by the user, the authentication succeeds; if the request is different, the authentication fails.

In the SIGNATURE of the API gateway, two optional headers, X-CA-timestamp and X-ca-nonce, are provided. The two parameters can be used together when the client invokes the API to prevent replay attacks. – x-ca-timestamp Indicates the time when the request is initiated, which can be taken from the local implementation of the machine. When the API gateway receives a request, it verifies the validity of this parameter within 15 minutes. – x-ca-nonce Specifies the unique identifier of the request. Generally, it is identified by the UUID. The API gateway verifies the validity of this parameter upon receiving it. The same value can only be used once within 15 minutes.

To sum up, xiahei can basically use replay attack defense on the basis of his own scheme. If symmetric encryption of data is added and sign calculation of the whole content is added, high-level man-in-the-middle attack can be accessed and malicious attacks against tampering content can be combated.

4. Summary

This article from a real interface security design case to expand, first introduced the interface scheme, interface vulnerabilities, so that we have a deeper understanding of the case.

It further introduces common solutions and their advantages and disadvantages, and also introduces ali Cloud API gateway scheme, which finally helps Xiahei solve the replay attack problem smoothly.

That’s it. Have a great weekend.

Graphic | replay attack is what