The development mode of front and back end separation, we take the interface as the standard to promote, define the interface, develop their own functions, and finally carry out joint integration. Regardless of the development of native APP, WebAPP or PC software, as long as the mode of front and back end separation, it is inevitable to call the interface provided by the back end for business interaction.

Web pages or apps can clearly know the data obtained by the request as long as they capture the package, and they can also forge the request to obtain or attack the server. It’s also a boon for the reptilian engineer, who can easily capture your data. So how do we solve these problems?

Interface signature

Let’s first consider the problem of the interface data being forged and the interface being called repeatedly. To solve this problem, we need to use the interface signature scheme.

The signature process

Signature rule

1. Assign AppID and AppSecret offline, and assign different AppID and AppSecret to different callers

2. Add timestamp (timestamp) and the data will be valid within 5 minutes

3. Add the temporary serial number nonce (to prevent repeated submissions) with at least 10 digits. For the query interface, the serial number is only used for log landing, facilitating log verification. The uniqueness of serial number in validity period should be verified for the processing interface to avoid repeated requests.

4, add signature field signature, all data signature information. The above fields are placed in the request header.

Signature generation

Rule for generating signature fields

All dynamic parameters = Request header + Request URL + Request Request parameters + Request Body

The preceding dynamic parameters are stored in key-value format and sorted by key value

The last string to be concatenated is in concatenated appSecre.

signature = DigestUtils.md5DigestAsHex(sortParamsMap + appSecret)

That is, concatenate a string and then perform MD5 irreversible encryption

Request header

Request header = “appId = xxxx&nonce = XXXX x tamp = xxxx&sign = XXX”

The four parameters in the request header must be passed or an exception will be raised

Request URL address

This is the request interface address inclusion protocol, such as

mso.xxxx.com.cn/api/user

Request Request parameters

That is, the parameters passed in when the request is a Get

The request Body

That is, if the request is Post, the Body is requested

Get it from request InputStream and save it as a String

Implementation of signature algorithm

In fact, the basic principle is relatively simple, that is, to customize filter, processing each request; The overall process is as follows

1) Verify the required header parameters

2) Get the header parameters, the request parameters, the Url request path, the request Body, and put these values into SortMap for sorting

3) Splice the values in SortMap

4) Encrypt the spliced value to generate sign

5) Compare the generated sign with the sign passed in by the front-end, and return an error if they are different

Let’s look at the code

The above is the Filter class, among which appSecret needs to be obtained by our own business. Its main function is to distinguish different client apps. And use the obtained appSecret to participate in the sign signature, to ensure that the client request signature is controlled by our background, we can issue different appSecret for different clients.

Let’s look at the validation header parameters again

The figure above is actually verifying whether a value is passed in; However, there is a very important point, is the request for time verification, if more than 10 minutes indicates that the link has timed out, to prevent others to this link to request. This is to prevent theft.

So let’s see, how do we get the parameters

Above we get the parameters, which are relatively simple; Let’s look at generating sign and validating sign

In the above process, there will be an additional security treatment,

· To prevent theft, we can make links expire

· Use the nonce parameter to prevent repeated submission

After the signature verification is successful, it determines whether to submit again.

The principle is to combine redis to determine whether it has been committed

conclusion

Today we use signatures to protect the interface we provide externally; But this protection only goes so far as to prevent someone from tampering with the request or impersonating it.

However, there is still a lack of security protection for data itself, that is, the requested parameters and returned data may be intercepted and obtained by others, and these data are plaintext, so as long as intercepted, the corresponding business data can be obtained.