The anti-weight of the API

Talk about the anti-replay mechanism of the API

2017-03-20 18:19 by Xuan Blade, 685 Read, 7 reviews, favorites, compilation

Talk about the anti-replay mechanism of the API

When we design the interface, we are afraid that an interface is intercepted by the user for replay attacks. What is replay attack? is to send your request again, two times ... n times, normal requests pass through validation into normal logic, and if the normal logic is to insert database operations, then once the database is inserted in the statement is not good, it is possible to have more than one duplicate of the data. Once a slow query operation, it can lead to the database blocking and so on.

There is an anti-replay mechanism to do the request verification.

Timestamp+nonce

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

The timestamp is used to represent the current timestamp of the request, and the timestamp is, of course, corrected with the server timestamp. We expect the timestamp parameters of the normal request band to be different (it is expected that the normal person will do at most one action per second). The timestamp of each request band cannot exceed the time specified by the current time. Like 60s. This way, if the request is intercepted, you can only perform replay attacks within 60s. Expiration expires.

But this is not enough, and gives the attacker 60s of time. So we need to use a nonce, random number.

Nonce is generated by the client based on sufficient random conditions, such as MD5 (Timestamp+rand (0, 1000)); It has a requirement that, under normal circumstances, it is almost 0 to generate two identical nonce instances in a short period of time (such as 60s).

Service side

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, then create this key, which will invalidate the key time and verify that the time of timestamp failure, such as 60s.
3 If yes, this key is already in use within 60s, then this request can be judged as replay request.

Example

So for example, here's the request:

http://a.com?uid=123&timestamp=1480556543&nonce=43f34f33&sign=80b886d71449cb33355d017893720666

This request for China's UID is a meaningful parameter that we really need to pass

Timestamp,nonce,sign are for signature and anti-replay use.

Timestamp is the time to send the interface, the nonce is a random string, sign is the uid,timestamp,nonce (for some restful API, I recommend also put the URL into the signature signed). The method of signing can be MD5 ({secret to}key1=val1&key2=val2&key3=val3 ...)

The service ends up receiving this request:
1 Verify that the sign signature is reasonable and that the request parameter has not been tampered with halfway
2 re-verify that the timestamp expired and that the request was issued in the last 60s
3 finally verify that the nonce is already available, proving that the request is not a replay request within 60s

The anti-weight of the API