“This is the third day of my participation in the August More Text Challenge.

Interface security

When making interfaces, we often consider security, including authentication and authorization, interface security and other aspects. Here is a design of interface security. If there are any other good designs, you can put forward in the comments section

background

Why do you need to control the security of interfaces for these reasons

  1. Anti-counterfeit attack
  1. Tamper-proof attack
  1. Defend against replay attacks
  1. Prevent data information leakage

For example, when our user logs in to an account, the user enters the password from the front end. What happens if our interface also receives the password with these two parameters? If important business is involved, others can steal user information simply by grabbing a packet and analyzing it. So how do we solve this? Please see the following

The solution

There are many solutions. The common approach is to verify the token and then add HTTPS.

In these four cases, the interface is vulnerable if no security policy is implemented.

For the first type of anti-counterfeiting attack, common interfaces carry token authentication and can be filtered out.

For the second and third types, if someone intercepts the request and modifies the parameters, the token mechanism cannot be secure. Therefore, the effective method is encryption, and there are many ways to encrypt.

Here is a diagram to introduce one I use, diagram for convenience, I will simply hand painted to see

The steps of this method are

  1. The request parameters (generally in json form) plus the agreed salt for AES encryption, encryption is byte, generally use Base64 transcoding output, can also do bit offset, get an encrypted string; Then add the token of the backend, add the timestamp, carry out MD5 encryption to get a fixed length sign string
  1. The advantage of this is that for the second or third attacks, others block your request and tamper with it. The back end performs AES encryption based on parameters + agreed SALT and MD5 encryption based on +token+ timestamp. If the two MD5s are inconsistent with sign, you know that someone must have tampered with the parameters and can reject the request. If you don’t want to expose the parameters directly, you can also use AES encryption to the back end. This avoids the fourth case

conclusion

The above is my humble opinion, if there is a better design method, welcome to exchange and learn