Write the login status information in cookie, if the user caught the packet, forged cookie to send the request, how to avoid this situation?

write the login status information in cookie. How can you avoid this situation if you fake the cookie and send the request after being caught by the user? bold text

Jun.20,2021

the most important thing is to prevent being caught, others can only increase the difficulty of being forged, and can not completely avoid being "forged".

after all, whether it is cookie, session, or token, the client must have a login credential, and the backend can only recognize this credential. If the credentials are taken away by others, there is nothing the backend can do.

of course, you can combine multiple authentication methods to make it more difficult to forge.
for example: the meaning of the fields in
cookie should not be easily understood. Put a few more confusion, some are request parameters, some are authentication;
not only judge the cookie, but also judge whether the client is the same or ip is the same;
not only cookie,localStorge and sessionStorage also put some authentication fields.
.

in addition, talk about several invalid methods:

  1. constantly refresh cookie or session:

this is useless. When you refresh it, you don't exchange the old one for the new one. If the forger has the old one, of course you can get the new one.
of course, it may make forgery more difficult.

  1. encrypt with md5 during front-end transmission:

if the backend wants to authenticate its identity, it must need an algorithm that can be decrypted. If md5 is used as an one-way encryption, there is no way for the backend to authenticate the user's identity. The encrypted string used by the front end must be decrypted by the back end.
if you use an algorithm that can be decrypted, but because the front-end code can be seen by others, the encryption method can also see that there is no point in using the existing encryption algorithm, and it is difficult to use an encryption algorithm that can only be decrypted by yourself.

In short, the same sentence: the most important thing is to prevent getting caught.


for security: please constantly reset session; set the expiration time shorter; monitor the values of referrer and userAgent; use HttpOnly to prevent scripts from reading Cookie. These measures are not foolproof, but they make it more difficult for hackers, so they are also effective.
https://blog.fundebug.com/201.


encrypt it first when you send it. If you use md5 or sha1 encryption algorithm, it is impossible (or too expensive) to push back token without knowing key.

if you say, can't I just get this token and forge it? it's true, so it's basically safe to add session, that is, to store a session_id, in cookie and then the server verifies session_data,session_id + cookie through a secret.

in addition, you can generate a signature for the cookie, and the secret that generated the signature is also saved on the server, and then verify whether the current generated signature is the same as the previous signature for each request. For example, if username saves the aaa, client as username=foo_aaa, according to a certain encryption algorithm and the encrypted signature of secret, and then someone tampers with username to bar_aaa, and transmits it to the server and finds that the signature generated by bar is inconsistent with aaa, it proves that cookie has been tampered with.

other words, there are httponly, secure and other configurations, these are settings to prevent third parties from tampering with cookie, while trying to use https, to prevent the middle of the request transmission process from listening.

personal humble opinion, if there are any mistakes, please correct them.


to be honest, it's impossible. Unless your cookie is disposable, I can use it on your cookie when I grab it. You can only use a variety of strategies to guess whether his behavior is risky and unavoidable.


if your network environment can be caught, your network is already very insecure. Then it's time to show the advantages of https.

Menu