Preventing Cross-Site Request Forgery (CSRF) Attackshttp://asp.netThu, 23 May 2013 05:00:29 GMTumbracoComments for Preventing Cross-Site Request Forgery (CSRF) AttacksenComment Posted by mambyhttp://asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacksFri, 08 Mar 2013 03:57:53 GMT00000000-0000-0000-0000000018619Hi Mike,

where do we call the "ValidateRequestHeader"?

]]>Comment Posted by duanehaworthhttp://asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacksThu, 09 May 2013 14:50:30 GMT00000000-0000-0000-0000000019085And where does the "AntiForgery.GetTokens" method from the line:

AntiForgery.GetTokens(null, out cookieToken, out formToken);

come from?

]]>Comment Posted by matt.ghttp://asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacksWed, 15 May 2013 10:13:32 GMT00000000-0000-0000-0000000019109This seems to be all about MVC. What about Web Forms, as this page www.asp.net/ said to go here?

]]>Comment Posted by cornanhttp://asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacksMon, 20 May 2013 15:30:57 GMT00000000-0000-0000-0000000019145I'm not 100% sure I follow how this works. It would make the post clearer for me if the numbered bullets under "Anti-Forgery Tokens" spelled out the "untrustworthy site" scenario. Other paragraphs touch on the "same-origin policies", but they are not included in that set of numbered bullets, so I'm not sure at which point the hidden form field cannot be seen and by "whom".

Otherwise interesting and clear...

]]>Comment Posted by lonelypixel3http://asp.net/web-api/overview/security/preventing-cross-site-request-forgery-(csrf)-attacksThu, 23 May 2013 05:00:29 GMT00000000-0000-0000-0000000019160When is this anti-forgery token generated and how long is it valid? Consider having the web app open in multiple tabs and doing multiple things concurrently. There can be different form values, but only one cookie. So would it be safe enough to use the same token throughout a session? Then, would it be safe enough to use the session ID value directly as the token? This would avoid a separate cookie and the site itself could easily copy the session ID into a form field, as could AJAX requests.

]]>