Last post Apr 06, 2015 01:52 AM by gtscdsi
Apr 02, 2015 05:52 AM|Mr.Breaker|LINK
Hey everyone, first post on these forums.
I would like to share my concerns on the following article:
http://www.asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacks. I know the article is quite old, but I believe still many users use it as a reference. Unfortunately my message became too big to put in the comments, so
I had to put it in a forum post.
I see a problem regarding the recommended implementation for Anti-CSRF for Ajax calls. The anti-CSRF protection relies highly on the expiration of the cookie. Whenever the cookie expires, the client's browser will never send that cookie to the server, hence
the time an attacker has to find the proper combination of the cookieToken and the formToken is reduced to the current time and the expiration date of the cookie. As far as me and a colleague could reverse engineer, the validity of the token is purely based
on a check between the contents of both (unencrypted) tokens and does not rely on the session. The expiration, therefore fully reliant on the expiration date of the cookie.
When both tokens are placed in one header a problem is introduced. By placing both tokens in one header, both tokens practically merge into one larger single token which is theoratically infinitely valid. History shows that there have been problems with
applying the Same-origin policy for custom headers (i.e. http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-February/007533.html).
Under the right circumstances, an attacker has infinite time to find (for example, by brute-forcing it, or by an MITM-attack) a valid value for the token and then to use the token in a CSRF attack.
I'm very curious about your view on this!
Apr 06, 2015 01:52 AM|gtscdsi|LINK
Here are some articles discussing about Anti-CSRF for Ajax which may interest you.
Hope useful to you!