[WEB SECURITY] CSRF remedies in

Eric Rachner eric at rachner.us
Thu Jan 15 13:37:04 EST 2009

I've been advocating
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 be*get* 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> 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 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 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]
> *Sent:* Wednesday, January 14, 2009 7:30 PM
> *To:* websecurity at webappsec.org
> *Subject:* [WEB SECURITY] CSRF remedies in
> As most of us know, 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/7a65bb42/attachment.html>

More information about the websecurity mailing list