Current situation of front-end and back-end separation architecture;
In this case, the back-end api is exposed to the external network, because the front-end of the conventional web project will access the back-end api through the public network anyway, which also brings many hidden dangers.
The 1. interface is open and anyone can access it.
2. The parameters of the data request were tampered with during transmission.
3. The interface is called repeatedly.
...
Sessions and cookie are authentication required for communication between clients and servers. When the value of the client is consistent with the value of the server, the api is allowed to be requested, which solves the problem of 1. However, when the attacker obtains the session or cookie value during transmission, the second and third attacks can be carried out.
JWT standard token contains three parts:
The header is used to describe the most basic information of JWT, such as its type and the algorithm used for signature.
The following string can be obtained through the JSON object above [base64 encoding]. This string is called the title of JWT.
Payload is also a JSON object. Contains some other information.
The first five fields are defined by the JWT standard.
The following string can be obtained through the JSON object above [base64 encoding]. This rope is called the payload of JWT.
Connect the above two encoded strings with a period (the head is in front) to form.
Finally, we use HS256 algorithm to encrypt the spliced string. When encrypting, we need to provide a secret. If we use mystar as the key, we can get our encrypted content.
This part is called signature.
Finally, this part of the signature is also spliced after the signed string, and we get the complete JWT.
Signature solves the risk of parameter tampering during data transmission.
Generally speaking, encryption algorithms always produce different outputs for different inputs. If someone decodes, modifies and encodes the contents of the header and payload, the signatures of the new header and payload will be different from the previous ones. Moreover, if you don't know the key used in server encryption, the signature will definitely be different.
The problem of tampering with data has been solved, and there is a third problem, that is, the attacker does not modify the data, but only repeats the attack.
For example, the token of the browser-side username/password verification signature was stolen by a Trojan horse. Even if the user logs off the system, the hacker can still use the stolen token to simulate the normal request, but the server knows nothing about it because the JWT mechanism is stateless.
You can add a timestamp to the payload, and both the front end and the back end are involved in solving this problem: