Saturday, May 21, 2011

Anti-CSRF & ViewState

What is Cross Site Request Forgery (CSRF) ?
CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application. (Read more here…)




How to prevent CSRF?
1. Every request should contain a unique identifier (in HTML form), which is a parameter that an attacker cannot guess. In many web articles suggest ViewStateUserKey alongwith ViewState (for Dot Net Applications) can be used for the same. But it has some limitation. Read more ….



2. One suggested option is to add the session id taken from the session cookie and adding it as a parameter. The server must check that this parameter matches the session cookie. The reason an attacker cannot guess this parameter is the "same origin policy” that applies to cookies, so the attacker cannot forge a fake request that will seem real to the server.







Implementation
The code has been developed in C# language. The implementation is pretty simple. We have created a custom HttpModule which intercepts every request and response to validate a pair of unique key combination. We have used GUID for unique key. The unique key has been placed in a hidden form field as well as in a cookie.



The normal recommended way of adding a CSRF token to an ASP.NET application is to use ViewState in combination with a ViewStateUserKey. This requires ViewState to be enabled and an application to have some way of identifying a user uniquely, usually via a SessionID which in turn requires session state to be enabled. This library does not have these requirements; instead it requires cookies to be enabled on the user's browser and uses a temporary cookie, cleared when the browser is closed, to identify a user and a hidden form field to carry the CSRF token.









The main logic for CSRF attack in the module has been given below:













if (context.Request.HttpMethod.Equals("POST", StringComparison.Ordinal))



{if (context.Request != null){



HttpCookie csrfCookie = context.Request.Cookies



[AntiCsrfSettings.Settings.CookieName];



string csrfFormField = context.Request.Form



[AntiCsrfSettings.Settings.FormFieldName];





...



if (csrfCookie.Value != tokenField)



{RaiseError(new PotentialCsrfException



(Properties.Resources.exceptionMessageNotMatched)



, context);



}}}






Please note the following
* The pages that need to be protected from CSRF attack, no code tampering is required.
* The pages that don’t need to be protected, we need to specify an Attribute for each of those classes. [AntiCsrf.Library.SuppressCsrfCheck]





Installation
The objective of this document is to provide a comprehensive guide for Anti CSRF library for ASP .Net and configuring Anti CSRF mechanism for ASP .Net application.

1. Place the Anti.CSRF.Library.dll in the bin folder of the ASP .Net web application.




2. Open the web.config file of the web application and place the following lines.
3. Under put the following:














type="AntiCSRF.Library.Configuration.AntiCsrfSettings, AntiCSRF.Library" />









4. Under put the following













type="AntiCSRF.Library.AntiCsrfModule, AntiCSRF.Library"/>












Testing
As per the configuration above, if any CSRF attack happens, the website should redirect used to the login page. For testing we have designed an ASP .Net application which allow authenticated user to modify their profile.













A CSRF attack can be done with the above profile change page with the following html page:







Without the Anti CSRF library, if we fire the html with a valid session, the record will be updated accordingly.










Now after implementing the Anti CSRF library, if we fire the same event, the malicious page will be redirected to the Login page:







Limitation



<!--[if !supportLists]-->· <!--[endif]-->GET requests are not protected with this module



<!--[if !supportLists]-->· <!--[endif]-->Non-ASP.NET forms are not protected with this module



Reference



http://anticsrf.codeplex.com






No comments:

Post a Comment