Api-gateway Practice (+) HTTP request Tamper-proof

I. Concepts and definitions 1, what is replay attack?

When we design the interface, we are most concerned that an interface is intercepted by an ulterior user and used for replay attacks. What is replay attack? is to send the request to be sent unaltered, once, two times ... n times.

2. Consequences of replay attacks

The general request is submitted to the background execution, after "page verification" is submitted to the "background logic", submitted to the "background logic" process, the request may be intercepted,

• If this "background logic" is inserted into the database operation, it is easy to create multiple duplicate data into the database.
• If this "background logic" is to query the database operation, it may lead to repeated queries, the database is blocked and so on.

Therefore, we need an anti-replay mechanism to do the request verification.

II. Solution 1, Client (carry Timestamp+nonce)

The mechanism we use to prevent replay is the replay mechanism using timestamp and nonce.

1.1, timestamp

The timestamp is used to represent the current timestamp of the request, which is corrected beforehand with the server timestamp. We expect the timestamps of normal request bands to be different, such as assuming that normal people do at most one action per second.

Each request carries a timestamp that is not close to the current time, i.e. it cannot exceed the specified time, such as 60s. If the request is intercepted, it can only be replayed within a limited time (e.g. 60s), and expiration will expire.

1.2. nonce

Just providing timestamp is not enough, we still provide the attacker with 60s of attack time. To avoid an attack within 60 seconds, we also need to use a nonce random number.

Nonce is generated by the client based on random, such as MD5 (Timestamp+rand (0, 1000), under normal circumstances, in a short time (such as 60s) continuous generation of two of the same nonce is almost 0.

2, the service side (verify the time is over limit, check the signature)

The server does the following behavior for the first time when it receives this nonce:

1 go to Redis to find out if there is a string with key nonce:{nonce}

2 if not, create this key to set the time for the key to expire and verify that the timestamp expires, such as 60s.

3 If yes, this key is already used within 60s, this request can be judged as replay request.

3. Program Flow

http://www.xxxx.com?userid=123&username=zhangsan&timestamp=1480556543&nonce=43f34f33 &sign=80b886d71449cb33355d017893720666

In this request, UserID and username are the business parameters that really need to be passed, and timestamp,nonce,sign are used for signing and anti-replay.

Timestamp is send request time, nonce is random string, sign is to uid,timestamp,nonce (for some rest-style API, it is recommended that business parameters are signed together).

The processing logic that the service receives for this request:

• Verify that the sign signature is reasonable and that the request parameter has not been tampered with halfway
• Verify that the timestamp has expired and that the request was issued in the last 60s
• Finally verify that the nonce is there, proving that the request is not a replay request within 60s

Api-gateway Practice (+) HTTP request Tamper-proof