In a typical PHP web application you append a hidden CSRF Token in each form and this token is validated when the request is submitted in the server side.

I am performing a penetration test in a .NET application and I want to learn more about the CSRF protection mechanisms in this particular case.

When I intercept the packages I notice a cookie with name __AntiXsrfToken but this cookie has the same value for each session of a user (guidelines dictate that after logout this value has to change). Moreover I don't see a ViewStateUserKey parameter in the request. Obviously this scheme doesn't work correct.

I need to propose a solution to the developer and he is using ViewState so I guess he could enable ViewStateUserKey (I have read about it on other posts but I ain't quiet sure about it). Is it just a fancy name for a hidden input field in each form?

Can anyone elaborate on such a solution?

  • i'd like to suggest using this kind of AntiXsrf - which uses hidden field and cookies as how php usually do - instead of storing on viewstates (which sometimes best to be disabled to save bandwith). your current csrf protection looked like this post? regardless your approach, viewstate is a bunch of strings in the hidden field also you can decode. – Bagus Tesa Mar 1 '18 at 23:01
  • ps. i believe the user key is session-bound (uses cookies nevertheless). – Bagus Tesa Mar 1 '18 at 23:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.