1

If an attacker can read hidden fields then how is sending anti CSRF token in a hidden field useful?

I am preparing for an interview and came across CSRF.I know that CSRF is possible because whenever our browser sends a request to the website we are logged in it automatically sends cookies with it too. For the authentic server to know if the user really made a request, this article suggests that a anti CSRF token should be added as an hidden value in every request sent by the browser. This way the authentic server will know which request was forged and which was not as an attacker cannot predict the anti CSRF token.

But this post says that an attacker can easily see the hidden values. Doesn't this make the above suggested mitigation useless? I am confused.

1 Answers1

1

Context and attention to detalis are important.

For starters, the answer to Web security, are there issues with hidden fields (no sensitive data)? doesn't say that an attacker can "easily" see the hidden values, but that it would be "just as easy" as seeing query string parameters - that's a comparative, not absolute.

Then you have to consider who the attacker is. Debating hidden fields vs. query parameters implies simply hiding values that the user isn't supposed to see - the attacker is a regular user accessing the page.
CSRF on the other hand, in the most generic case, involves a third-party tricking the user into submitting a form; the attacker is the third-party and (unless other vulnerabilities are present) isn't able to just read the user's data.

And finally, the protection technique described in the blog post you linked doesn't rely merely on a hidden field, but it couples it with a token stored in a cookie - this is known as the Double Submit Cookie pattern and is a textbook CSRF protection mechanism. An adversary would need to match both the form and cookie tokens to perform a successful attack.

So yes, the solution outlined in the blog post does prevent CSRF attacks.

Narf
  • 14,600
  • 3
  • 37
  • 66