| Newsgroups |
gmane.comp.mozilla.security |
| Message-ID |
<[email protected]> |
I'd like to see better browser support for preventing CSRF. I think it's still hard to solve properly in some cases [1].
And I think it's overly pessimistic to discount First-Party-Only / SameSite as never providing primary defense against CSRF.
Maybe support will never reach 100% in an absolute sense, but would argue that it will get close enough that it's no longer a viable attack vector for many use cases, in a few years.
Having a 'read-cookie' (without SameSite) and a 'write-cookie' (with strict SameSite) feels like it's not too hard to document?
Joe.
[1]: Example - I was looking at CSRF protection in a Node site that used Socket.io recently. The expressjs csurf middleware doesn't work for the XHR fallback case, so to be safe, I think you have to handle csrf tokens manually for socket connections.
On Wednesday, January 20, 2016 at 12:01:13 PM UTC, Mike West wrote:
> Thanks for starting this thread, Mark. I'll reply to some of the questions
> inline, but I'll first note that I'm working on an -05 draft which might be
> helpful in terms of clarifying the mechanism under consideration at
> https://mikewest.github.io/internetdrafts/first-party-cookies/draft-west-first-party-cookies-05.html.
> That should make the Fetch story clearer, and hopefully address Anne's
> question about workers (it also renames the feature to "SameSite", for
> reasons that aren't worth getting into here).
>
> Broadly, the "safe" top-level navigation carveout is meant to deal with the
> confusion that might otherwise result from an auth cookie not being present
> for a request. Since GitHub is the only implementation I know of, let's use
> them as an example: it would be confusing if I clicked on a link to a
> private repository in an email, navigated to GitHub.com, and got a 403
> error telling me I wasn't logged in. Likewise, it would be strange if I
> popped up a window as part of a "Sign in with GitHub" OAuth dance and had
> to sign in every time.
>
> They certainly _could_ rewrite their session management system to deal with
> multiple cookies granting different levels of access (just as Amazon
> requires reauth to actually buy things), but based on some conversations,
> they're more likely to simply not use the feature than to undertake that
> rewrite.
>
> At the moment, I'm thinking that it might be reasonable to have the
> carveout as an option; `SameSite=Lax` or something. I've been reluctant to
> do so, as I'm not sure the extra complexity is worth it, but if folks like
> GitHub wouldn't use the strict form of the feature, then such an option
> starts sounding more reasonable.
>
> On Wed, Jan 20, 2016 at 2:53 AM, Tanvi Vyas <[email protected]> wrote:
>
> > I believe the intention here is to prevent sites that use safe methods for
> > state changing actions from depending on the First-Party-Only flag for CSRF
> > protection.
>
>
> For clarity, this isn't the intention of the carveout. The spec plainly
> states that this feature constitutes defense in depth, on top of a already
> robust CSRF protection. If we decide, however, that the carveout should be
> removed (optionally), then I certainly wouldn't block that decision based
> on the fact that some developers might mistakenly rely on it too heavily.
> We should give developers sharp tools. *shrug*
>
> -mike