Re: [PATCH] Enable CsrfViewMiddleware -- make CSRF protection required by default

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Marti Raudsepp <marti(at)juffo(dot)org>
Cc: pgsql-www <pgsql-www(at)postgresql(dot)org>
Subject: Re: [PATCH] Enable CsrfViewMiddleware -- make CSRF protection required by default
Date: 2012-11-02 14:32:14
Message-ID: CABUevEx46f9v1fbKrzpnGZJJuprz7yX8iVm_TJ4Eez+dCPsOoA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-www

On Fri, Nov 2, 2012 at 3:23 PM, Marti Raudsepp <marti(at)juffo(dot)org> wrote:

> On Fri, Nov 2, 2012 at 1:31 PM, Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
> > So, one more thought. Is this going to break if the form is cached? That
> is,
> > the original form at e.g. http://www.postgresql.org/community/ for the
> > surveys is cached. That means that the CSRF token that's on the form
> > actually ends up being cached. Is the CSRF token going to be valid in
> those
> > cases, and is it actually going to protect us?
>
> Yeah, that's true. But it should be a matter of flushing the Varnish
> cache, right? There are no cache policy headers on these responses, so
> browsers will generally revalidate the page.
>

No, we'd need to disable the caching of the page completely, if we want the
cookie to be passed along.

For a "pure form", that will only affect performance, and probably not too
bad. But they need to be identified and excluded.

For combined pages, like the /community/ page, it's a slightly bigger
problem. Disabling caching of it disables grace mode, which also makes that
page completely unavailable in the event of a backend or network failure.
For a regular form it's not a big problem sinc the form wouldn't work
anyway, but that page is used as a navigation page as well... I'm not sure
if we have any other such pages (other than the search, but we can
certainly disable CSRF for search, right?)

But now that you mention it, there is another caching impact:
> accessing this page causes the user's cookies to be changed, and due
> to "Vary: Cookie", it will prevent the caching of any subsequent page
> fetches for this user in Varnish, even on other pages (for 1 full year
> by default).
>

No, that's not a problem. We strip cookies in varnish by default. We only
support them over https...

Of course the above also affects any users who logged in -- since the
> csrftoken cookie is served without the "secure" flag, the cookie is
> also present in any non-secure requests.
>

We only log users in over https, not http. All login-required pages are
(should be) behind https only, and the session cookie has the secure flag
set. Any cookies present on a http request are just removed.

Does this also impair Varnish "grace mode", when the backend server is down?
>
>
Yes, turning off caching turns off that functionality as well, which is why
it's something we'd like to avoid.

Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-www by date

  From Date Subject
Next Message Magnus Hagander 2012-11-02 14:36:21 Re: Search points to ancient manuals
Previous Message Marti Raudsepp 2012-11-02 14:23:41 Re: [PATCH] Enable CsrfViewMiddleware -- make CSRF protection required by default