Doubt and discussion on Front-end asymmetric encryption

even in front-end asymmetric encryption, there must be a public key or private key exposed to the client. So asymmetric encryption can only prevent content from being intercepted and read in the transport layer (but others can use the same data request format to encrypt and send requests). This does not prevent others from swiping the request interface at all? Is that all the front-end asymmetric encryption does? I would like to ask the seniors to advise me that it is best to combine the csrf attack at the front end

.
Mar.28,2021

encryption is encryption, which is not intended to prevent others from swiping the interface. You can use frequency control to limit the interface.


the most important function of encryption is to prevent the middle from being intercepted to learn the plaintext content.
another function of asymmetric encryption is to pass the authentication content of the encryption of their respective keys to each other for authentication, because only the secret key you hold can be decrypted, you can confirm the identity of the other party.

swipe the interface, you have the correct plaintext and the secret key, then you can send the correct encrypted message. How to prevent brushing is another problem.

and if someone intercepts your encrypted content, although he can't crack it, he can still send your encrypted content repeatedly. This kind of problem is not to be solved by encryption.

csrf attacks have nothing to do with encryption. I remember that the Chinese name is a forged cross-site request, which, as the name implies, sends a fake request to a vulnerable website from a dangerous website.
this is an attack that uses some automatic get requests issued by the browser to cross domains (such as the src attribute of the tag, which means that the browser automatically sends a get-type http (s) request to the url specified by src); at the same time, the http (s) protocol is implemented with the cookie feature in the requested domin by default.

The reason for the

vulnerability is that the user's authentication information is stored in cookie and does not determine whether the source of the request is reliable.

so, for example, if site An is a dangerous site, site B is the target site for vulnerabilities, and user a has an account on site B.
user a visited the A website, and the src of a picture on the A website sent a request to the B website. At this time, the request sent by the picture link will carry a's cookie on the B site. If there is a token, for authentication in cookie, you can forge a request on website An and complete the authentication.

Menu