[WEB SECURITY] CSRF remedies in

Ragan, Rob R rob.ragan at hp.com
Thu Jan 15 14:38:09 EST 2009


I was in no way trying to defame ViewStateUserKey as I also advocate its use. It came up as a question of semantics while I was working on a static analysis tool and we were deciding how to name our check for if ViewStateUserKey is being used. It was between "Possible Cross-site Request Forgery" or "Possible One-Click attack".  Ever since researching how ViewStateUserKey works I've been apprehensive to make an all encompassing comment such as "it prevents CSRF". (You said mitigate, which is fine) The hard part with using an automated tool to check for ViewStateUserKey usage is that it is difficult to tell if the application is following other best practices that ensure it prevents CSRF attacks properly. We decided to leave the check called "Possible One-Click attack" as that implies use of ViewState. I merely want to point out that an ASP.NET developer could seemingly follow all the recommendations about indempotence that you outlined, but access POST data with Request.Params making it possible to negate the ViewState MAC verification.

Maybe we can agree that using GET or Request.Params for sensitive information is a bad practice.

I'm was glad to see that Microsoft's MVC framework added the AntiRequestForgeryToken<http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/> helper as RoR, Django and other MVC frameworks have similar features.

-Rob

From: Eric Rachner [mailto:eric at rachner.us]
Sent: Thursday, January 15, 2009 1:37 PM
To: Ragan, Rob R
Cc: websecurity at webappsec.org
Subject: Re: [WEB SECURITY] CSRF remedies in

I've been advocating ViewStateUserKey<http://www.aspnetpro.com/features/2004/08/asp200408er_f/asp200408er_f.asp> since it first debuted, so I'm just a little bit over-sensitive to any aspersions cast in its direction.  I'll grant that, as you say, it does not prevent CSRF attacks that take place via GET requests, but that's not to say that it ought to.

Developers should be discouraged from using GET requests for sensitive operations, and especially discouraged from feeling safe in doing so.  Anyone who uses GET requests for sensitive operations...

 1.  ...is in violation of RFC 2616 [1]
 2.  ...probably has to restore their app DB from backup every time a user or search engine spiders the site
 3.  ...defeats the helpful purpose of W3C standards concerning the non-replay of cached requests when users hit the 'back' button*
 4.  ...is just going to leak their secret URL-based "security tokens" in the following places
    *   Other people's server logs via the referer field
    *   Their users' browser histories
    *   Their users' favorites list
    *   Email and IM and everywhere else their users copy & paste page URLs
 5.  ...deserves all the misfortune they beget thereby. (Ahem.)
Bottom line, using GET for sensitive operations is such bad practice that it absolutely, positively should not be encouraged, and any security safeguard which only serves to enable further unsafe behavior does at least as much harm as good.

- Eric

p.s. I for one would appreciate fewer guesses ventured as to what most of us do or do not know.

* I refer here to the fact that a W3C-compliant browser will not retransmit a POST request if the original response to that request was an HTTP 3xx.  This is why it is considered good (as in, secure) practice for login pages to always answer with an HTTP 3xx that redirects the browser to the following page, rather than to just immediately display the following page with an HTTP 200 response.

[1] From RFC 2616<http://www.ietf.org/rfc/rfc2616.txt>: "... the GET and HEAD methods SHOULD NOT have the significance of taking an action other than data retrieval."
On Thu, Jan 15, 2009 at 8:32 AM, Ragan, Rob R <rob.ragan at hp.com<mailto:rob.ragan at hp.com>> wrote:

Most of us probably don't know that ViewStateUserKey won't always protect<http://keepitlocked.net/archive/2008/05/29/viewstateuserkey-doesn-t-prevent-cross-site-request-forgery.aspx> ASP.NET<http://ASP.NET> applications from CSRF attacks. It doesn't work if a GET request is being used or if the ViewState MAC is disabled. When passing values using Request.Params<http://msdn.microsoft.com/en-us/library/system.web.httprequest.params.aspx> ASP.NET<http://ASP.NET> doesn't care what HTTP verb<http://www.aspectsecurity.com/documents/Bypassing_VBAAC_with_HTTP_Verb_Tampering.pdf> is being used. This means a GET could be substituted for a POST. If the page is not a post-back the ViewState MAC is never checked. Microsoft's designation for CSRF attacks that use ViewState is One-Click attack<http://msdn.microsoft.com/en-us/library/ms972969.aspx#securitybarriers_topic2>. The moral of the story is don't rely on ViewStateUserKey to protect you from CSRF, instead use it along with something like http://www.owasp.org/index.php/.Net_CSRF_Guard



-Rob



P.S. http://hackademix.net/2008/12/20/introducing-abe/ is an interesting CSRF protection mechanism that lives in the browser.



From: Eric Rachner [mailto:eric at rachner.us<mailto:eric at rachner.us>]
Sent: Wednesday, January 14, 2009 7:30 PM
To: websecurity at webappsec.org<mailto:websecurity at webappsec.org>
Subject: [WEB SECURITY] CSRF remedies in



As most of us know, ASP.NET<http://ASP.NET> provides the ViewStateUserKey<http://msdn.microsoft.com/en-us/library/system.web.ui.page.viewstateuserkey.aspx> feature to mitigate CSRF attacks.  But as a primarily Microsoft-oriented guy, I'm not personally aware of any equivalent solutions for use in other environments, J2EE in particular, except of course for CSRFGuard<http://www.owasp.org/index.php/CSRF_Guard>.

Does anyone happen to know whether any web app development platforms other than .NET provide CSRF mitigations like ViewStateUserKey?

Much obliged,

- Eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20090115/c1c6d394/attachment.html>


More information about the websecurity mailing list