For the front end:
If the Ajax request interface is used separately at the front and back ends, the function of the request interface can be placed in a separate js file, and finally the js file is obfuscated and encrypted. This can prevent some illegal users from seeing the interface address directly after opening and checking the website front desk.
In addition, in order to prevent some illegal users from capturing packets, the interface address needs to be SSL encrypted, and HTTPS needs to be used to encrypt the data during transmission. If you capture the packet after encryption, you can only capture the encrypted data.
The above is all to prevent the IP address of the interface from being exposed.
For the backend:
Generally, the parameters token, timestamp and sign are added to the interface design.
timestamp is the timestamp, which is the current timestamp passed in when the client calls the interface. The purpose of the timestamp is to prevent DoS attacks. Each time the interface is called, the interface will determine the difference between the current system time of the server and the timestamp passed in the interface. If the difference exceeds a certain set time, for example, the set time is 3 minutes, then the request will be intercepted. If it is within the set timeout period, DoS attacks cannot be prevented. The timestamp mechanism can only mitigate the duration of DoS attacks and shorten the attack time. If a hacker modifies the timestamp value, it can be handled through the sign signature mechanism.
sign is a signature. It is usually used for parameter signatures to prevent illegal tampering of parameters. The most common is to modify important sensitive parameters such as amounts. The value of sign is generally all non-empty parameters. The parameters are sorted in ascending order and then +token+key+timestamp+nonce (random number) are spliced together, and then encrypted using a certain encryption algorithm. The advantage of this method is that after being hijacked, the parameter values are modified, and then If you continue to call the interface, although the value of the parameter has been modified, the attacker does not know how sign is calculated, so even if you tamper with the value of the parameter, you cannot modify the value of sign. When the server calls the interface, it will follow The sign rule recalculates the value of sign and then compares it with the value of the sign parameter passed by the interface. If they are equal, it means that the parameter value has not been tampered with. If they are not equal, it means that the parameter has been illegally tampered with, and no real response information will be returned.
Impotent operation The so-called idempotent operation is to prevent repeated operations. We can save the generated signature and key to redis, and set the timeout and expiration Automatic deletion, when duplicate values exist, will not be processed, which can prevent repeated submissions and ensure the consistency of request results.
Its usage process is as follows:
The interface caller (client) applies for an interface calling account from the interface provider (server). After the application is successful, the interface provider will give the interface caller an AppKey and an APP Secret parameter.
When the caller applies for App Key and App Secret, when generating a request, the parameters are spliced and encrypted, for example, using HMAC-SHA256 or MD5 encryption, and then the App Key and the encryption result are appended to the request. sign=encryption(appId + timestamp + key)
After the service receives the request, it identifies the caller based on the App Key, decrypts the parameters and compares the time to determine whether it has timed out. Then it queries the corresponding App Secret from the dictionary, splices it with the request parameters, encrypts it, and matches it with the signature in the request. After comparison, if the signature result is the same, it is a legitimate request.
In addition, in actual applications, you can also add some public parameters, such as Host, interface version, and other parameters to verify the security of the interface.