Today, me and my colleagues- Chintan and Ronnie were having a long discussion about ViewState's ability to thwart CSRF attacks. While Chintan's argument was that CSRF is possible even the application is implementing ViewState, Ronnie's thought was it's virtually impossible to launch a CSRF attack on ViewState enabled application. My idea was that it's not impossible but very difficult and takes a great expertise to launch the attack. We also saw various articles were mentioning the ViewState as a countermeasures to CSRF, at the same time they were not denying the fact that this can also be circumvented.
For sake of doing some research over topic I stumbled upon some articles and came to some conclusion:
When attempting to exploit a CSRF issue, the attacker will try to remove the viewstate from the page, since often viewstate is not required for a page to function properly. If the page complains when the viewstate is removed, the attacker will try logging into the application, visiting the page, and then copying the viewstate from the page into the CSRF exploit. Depending on the application, ASP.Net may accept the viewstate on behalf of the victim. Viewstate may be omitted or substituted because not all applications depend on the viewstate being present or initialized.
To mitigate the CSRF weaknesses, ASP.Net 1.1 introduced the Page.ViewStateUser-Key property. The property can be used to add entropy to the viewstate. When ASP.Net receives a postback it will use the ViewStateUserKey along with the validation key to calculate the page viewstate’s HMAC. By adding a unique value per user per page, it will not be possible for an attacker to substitute his own viewstate when creating a CSRF exploit.
Now starting .Net 1.1 the applications are 'almost' secure against the CSRF. Having said that it is also recommended to implement anti-CSRF token in the application. That will make the application's defense against CSRF more robust.
For sake of doing some research over topic I stumbled upon some articles and came to some conclusion:
When attempting to exploit a CSRF issue, the attacker will try to remove the viewstate from the page, since often viewstate is not required for a page to function properly. If the page complains when the viewstate is removed, the attacker will try logging into the application, visiting the page, and then copying the viewstate from the page into the CSRF exploit. Depending on the application, ASP.Net may accept the viewstate on behalf of the victim. Viewstate may be omitted or substituted because not all applications depend on the viewstate being present or initialized.
To mitigate the CSRF weaknesses, ASP.Net 1.1 introduced the Page.ViewStateUser-Key property. The property can be used to add entropy to the viewstate. When ASP.Net receives a postback it will use the ViewStateUserKey along with the validation key to calculate the page viewstate’s HMAC. By adding a unique value per user per page, it will not be possible for an attacker to substitute his own viewstate when creating a CSRF exploit.
Now starting .Net 1.1 the applications are 'almost' secure against the CSRF. Having said that it is also recommended to implement anti-CSRF token in the application. That will make the application's defense against CSRF more robust.
Comments