The front-end and back-end development methods are separated. We use the interface as the standard to promote , define the interface, develop their own functions, and finally make joint adjustments . Whether it is developing native APP, webapp or PC-side software, as long as the front-end and back-end are separated, it is inevitable to call the interface provided by the back-end for business interaction .
For web pages or apps, as long as you grab the package, you can clearly know the data obtained by the request , and you can forge the request to obtain or attack the server; it is also a boon for crawlers, and it is easy to capture your data. So how do we solve these problems?
Interface signature
Let us first consider the problem of forged interface data and repeated calls of the interface. To solve this problem, we need to use the interface signature scheme.
Signature process
Signature rules
1. Assign appid and appsecret offline, and assign different appid and appsecret for different callers
2. Add timestamp (timestamp) , the data is valid within 5 minutes
3. Add the temporary serial number nonce (to prevent duplicate submission) , at least 10 digits. For the query interface, the serial number is only used for log landing, which is convenient for later log verification. It is necessary to verify the uniqueness of the serial number within the validity period for the processing interface to avoid repeated requests .
4. Add the signature field signature , the signature information of all data.
The above fields are placed in the request header.
Signature generation
Signature field generation rules
All dynamic parameters = request header part + request URL address + request request parameters + request body
The above dynamic parameters are stored in key-value format, and sorted in the positive order of the key value for splicing
The last spliced string is spliced in appSecret
signature = DigestUtils.md5DigestAsHex(sortParamsMap + appSecret)
That is to splice into a string , and then do md5 irreversible encryption
Request header
Request header="appId=xxxx&nonce=xxxx×tamp=xxxx&sign=xxx"
The 4 parameters in the request header must be passed, otherwise an exception will be reported directly
Request URL address
This is the address containing protocol of the request interface, such as
https://mso.xxxx.com.cn/api/user
Request request parameters
That is, when the request is the Get method, the incoming parameters are obtained
Request body
That is, when the request is Post, the body of the request body
Obtain from request inputstream and save as String form
Signature algorithm implementation
The basic principle is actually relatively simple, that is, customize the filter to process each request; the overall process is as follows
1) Verify the necessary header parameters
2) Get the header parameters, request parameters, URL request path, request body Body, and put these values into SortMap for sorting
3) Splicing the values in SortMap
4) Encrypt the spliced value to generate sign
5) Compare the generated sign with the sign passed in from the front end, and return an error if they are not the same
Let's take a look at the code
@Componentpublic class SignAuthFilter extends OncePerRequestFilter{static final String FAVICON = "/favicon.ico";static final String PREFIX = "attack:signature:";}
The above is the filter class. One of the appSecrets needs to be obtained by your own business. Its function is mainly to distinguish different client apps. And use the obtained appSecret to participate in the sign signature , ensuring that the client's request signature is controlled by our background, and we can issue different appSecrets for different clients .
Let's take a look at the verification header parameters
The above figure is actually to verify whether the value is passed in; but in fact, there is a very important point, which is to verify the time of the request. If it is greater than 10 minutes, the link has timed out , preventing others from coming to this link to request. This is to prevent hotlinking.
Let’s take a look at how to get each parameter
We have obtained various parameters above, which is relatively simple; let’s take a look at generating sign and verifying sign
In the above process, there will be an additional security process,
· Prevent hotlinking, we can let the link expire
· Use the nonce parameter to prevent repeated submissions
After the signature verification is successful, judge whether to submit repeatedly;
The principle is to combine redis to determine whether it has been submitted
to sum up
Today we use signatures to protect the interfaces we provide to the outside ; but this protection only prevents others from tampering with requests or simulating requests.
However, there is still a lack of security protection for the data itself , that is, the requested parameters and the returned data may be intercepted by others, and these data are in plaintext, so as long as they are intercepted , the corresponding business data can be obtained.
Old Gu's next article will introduce how to ensure the security of interface data, thank you! ! !