0

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?

galoget
  • 1,414
  • 1
  • 9
  • 15
XII
  • 524
  • 1
  • 6
  • 14
  • i'd like to suggest using this [kind of AntiXsrf](https://github.com/ServiceStack/ServiceStack/blob/340e7f71468d7c60481be345e15b301c8e39c1f9/src/ServiceStack.Razor/Html/AntiXsrf/AntiForgery.cs) - 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](https://stackoverflow.com/a/29962060/4648586)? regardless your approach, viewstate is a bunch of strings in the hidden field also you can [decode](http://viewstatedecoder.azurewebsites.net/). – Bagus Tesa Mar 01 '18 at 23:01
  • ps. i believe the user key is session-bound (uses cookies nevertheless). – Bagus Tesa Mar 01 '18 at 23:04

0 Answers0