[WEB SECURITY] CSRF remedies in
Ragan, Rob R
rob.ragan at hp.com
Thu Jan 15 15:23:10 EST 2009
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. Be sure to prevent open redirects by white listing the site's for which you need to allow redirects.
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
-> 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