简体   繁体   中英

When its Necessary to Protect Forms with Token (CSRF attacks)?

As much as I understand, web developer should create token and put it in hidden field of form to prevent CSRF attacks. Also, he should save the same token in a session and then, when form is submitted - check that tokens are equal.

I came to question... is it necessary to do this technique for all forms? I mean, imagine form that is created to sign-in. I can't see any harm done to site and/or user if there is no CSRF protection, because user have no privileges (like he would have if he would be signed-in). The same goes for sign-up... Am I right?

PS If I'm wrong, please explain me the concept.

The danger that CSRF tries to prevent is when you have the following situation:

  1. The user has signed-in or whatever, and has a certain level of authority
  2. The bad guy exploits that authority without the user's permission

Sometimes this is by tricking the user into making an HTTP request without knowing it, for example in an image's source attribute.

The forms you want to protect are the forms that require this authority.

On the crazy, off-chance that this didn't actually make sense, Chris Shiflett has an awesome article on CSRF (which you may very well have already read:/)

Generally speaking, you want to protect your form anytime its submission will result in a change of content/state; be it adding it, removing it, editing it or sharing it with an external source ("share on xyz.").

An exemple of forms you wouldn't need to protect is a search box, since it doesn't result in any change of content.

If you're unsure, any form which will result in something being saved/deleted (whether it's on your site or not) should be protected.

And if you are really unsure just add the token, doesn't cost anything to be safe.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM