CSRF Protection in .NET – ViewStateUserKey
Cross Site Request Forgery is one of the most happening attacks over the internet today. The attackers find it easy to exploit as it does not require any authentication information, session cookies but only require the user to be authenticated to the application. And this works on every platform. It doesn’t matter what authentication type application uses, windows or forms authentication. Let’s assume attacker hosts a page on some X server which executes critical application functionality; attacker having knowledge of the application tricks the victim to visit the page by phishing attack, email abusing, redirection flaw, etc. The action executes in the background without the victim knowledge using user’s logged in session state.
.NET 3.5 framework has a built-in functionality to prevent CSRF attack. The framework has ViewStateUserKey property under system.web assembly which partially fixes the issue. This, however, does not make the application completely safe against CSRF attack if used alone. This is just a part of defense-in-depth concept.
ViewStateUserKey assigns a random value to current visiting page for an individual user. The random value is assigned in a ViewState parameter; which must be enabled in an application. This random value can be your authentication cookie, session ID or any random token. A good approach is to set two variables on authentication i.e. first in viewstate, second at server side and then subsequently drop the first variable from viewstate after successful authentication. Now, before serving the critical functionality page to the client set first variable in request and compare the same with server side variable in response. If matched, process the request otherwise drop the request. Make sure that the first variable is hidden.
It is recommended to use viewstate encryption mode along with ViewStateUserKey method.
More solutions to CSRF:
- Check the Refferer field for the domain along with above mentioned implementation.
- Add a unique and random page token to every form. This token must change on every form submission for example token X is for user addition, token X changes to Y for user updation, and so on.
No comments:
Post a Comment