How to Deal with the Security of Network Layer in Project

This article describes the way to do security processing in the network layer of the project.

Try to use HTTPS

HTTPS filters out most of the security issues. HTTPS requires effort in certificate application, server configuration, performance optimization, and client configuration. Therefore, developers who lack security awareness are easy to skip HTTPS or wait until they encounter problems. In addition to performance optimization, other services are simpler than expected. If you don't have the energy to optimize performance, at least you need to enable HTTPS in the registration and login module. This part of the business has relatively low performance requirements.
Do not transmit clear text passwords
I don't know how many apps have passwords stored in plaintext in the background. Whether the client, server or network transmission should avoid plaintext password and use hash value. The client does not need to do any password related storage, nor does hash value. Store the token for the next authentication, and the token needs to set the validity period, and use refresh
Token to apply for a new token.
Post is not safer than get
In fact, post is as insecure as get. It's both plaintext. There is no security difference between querystring and body. In the HTTP environment, encryption and signature processing are required when using post or get.
Do not use 301 jump
301 jump is easy to be hijacked by HTTP. Mobile HTTP 301 is more dangerous than desktop. Users can't see the browser address and can't detect that they have been redirected to other addresses. If you have to use it, make sure that the jump occurs in the environment of HTTPS, and that the certificate binding verification is performed for HTTPS.
All HTTP requests carry Mac
MAC (message authentication) is carried with all client requests, whether they are queries or write operations
Code）。 Mac can not only ensure that the request is not tampered with (integrity), but also ensure that the request is from your legitimate client (signing). Of course, the premise is that your client's key is not leaked. How to ensure the security of the client's key is another topic. The calculation of MAC value can be simply treated as hash (request)
params＋key）。 With Mac, the server can filter out most of the illegal requests. Although MAC has the function of signature, it is different from the electronic signature method of RSA certificate. The reason is that MAC signature and signature verification use the same key, while RSA uses private key signature, public key verification, MAC signature does not have legal effect.
HTTP request to use temporary key
In the network environment with high latency, the experience of HTTPS without optimization is obviously inferior to that of HTTP. In the case that there is no condition for HTTPS or requires high network performance and lacks experience in the optimization of HTTPS, the traffic of HTTP should also be encrypted by AES. AES key can be generated temporarily by the client, but this temporary AES
The key needs to be encrypted with the server's public key to ensure that only its own server can decrypt the requested information. Of course, the server's response also needs to use the same AES
Key. Because the application scenarios of HTTP are initiated by the client and responded by the server, this way of unilaterally generating the key by the client can ensure the communication security to a certain extent.
AES uses CBC mode
Do not use the ECB mode. Remember to set the initialization vector. Before encrypting each block, the secret text of the previous block should be calculated.