[WEB SECURITY] CSRF remedies in
stephanwehner at gmail.com
Fri Jan 16 02:04:24 EST 2009
On Thu, Jan 15, 2009 at 12:23 PM, Ragan, Rob R <rob.ragan at hp.com> wrote:
> Sounds like you're describing a Permalink. [http://en.wikipedia.org/wiki/Permalink]
> Your step 2 seems over complicated. For bookmarks to sensitive information I would 302 the user to a login page and re-authenticate them with a "ReturnTo" query string parameter that redirects back to the requested content.
You mean even if they are logged in already? That might work.
> Be sure to prevent open redirects by white listing the site's for which you need to allow redirects.
I lost you with this one. Do you mind explaining?
> -----Original Message-----
> From: Stephan Wehner [mailto:stephanwehner at gmail.com]
> Sent: Thursday, January 15, 2009 1:34 PM
> To: Ragan, Rob R
> Cc: Eric Rachner; websecurity at webappsec.org
> Subject: Re: [WEB SECURITY] CSRF remedies in
> 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
>> 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 ASP.NET doesn't care what HTTP verb 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. 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
> By the way, I am not sure about CSRF protection vs. bookmarks. When
> tokens are generated/validated even for GET requests -- which can be
> important when the response contains information that needs to be
> protected -- the user cannot use their browser's bookmark function.
> I'm considering a few solutions for the scenario of a web application
> that provides the CSRF-sensitive functionality to users only after
> they log in:
> 1. Use longer-lived tokens for GET requests.
> 2. Add "bookmarkable links" to each page which take the browser to a
> URL that has a longer-lived token. If user bookmarks a "short-lived"
> protected URL, and access the page from their bookmark function,
> inform them about the need for potection; instruct them how to find
> those "bookmarkable links" within the application and tell them to use
> those. (Getting ugly ?)
> 3. Maintain bookmarks within the web application itself.
> Am I overlooking something? Are there other ways?
>> 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 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.
>> Does anyone happen to know whether any web app development platforms other
>> than .NET provide CSRF mitigations like ViewStateUserKey?
>> Much obliged,
>> - Eric
> Stephan Wehner
> -> http://stephan.sugarmotor.org (blog and homepage)
> -> http://www.thrackle.org
> -> http://www.buckmaster.ca
> -> http://www.trafficlife.com
> -> http://stephansmap.org -- blog.stephansmap.org
-> http://stephan.sugarmotor.org (blog and homepage)
-> http://stephansmap.org -- blog.stephansmap.org
Join us on IRC: irc.freenode.net #webappsec
Have a question? Search The Web Security Mailing List Archives:
Subscribe via RSS:
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
Join WASC on LinkedIn
More information about the websecurity