Re: First-Party-Only cookies

Any site that relies on this for CSRF protection is going to be sad
given that no browser currently respects it.  The flag only provides
protection once a browser supports it (and that will never be 100%).
In support of other mechanisms (defense in depth), I get it, but this
will never be a primary defense mechanism.

Besides, sites shouldn't be using safe methods to change state.  I
know that that is often convenient, but don't we provide plenty of
better alternatives already?


On Wed, Jan 20, 2016 at 12:53 PM, 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.  In that case, the attacker could still attack the victim by
> doing a top level load of the state changing GET in a background tab.  This
> will send the First-Party-Only cookie along with the request.  If a site
> (like github) only uses unsafe methods for state changing actions, the
> First-Party-Only is sufficient CSRF protection (and it's a lot easier to use
> and understand than CSRF tokens!).
>
> If we remove the restriction, developers may start using First-Party-Only
> for CSRF protection without realizing it isn't going to work for their site.
> The attacker would just have to do a little extra work to make their exploit
> work.  Perhaps we could mitigate this risk with good documentation.
>
>
> On 1/19/16 3:00 PM, Martin Thomson wrote:
>
> On Wed, Jan 20, 2016 at 3:45 AM, Mark Goodwin <[email protected]> wrote:
>
> My questions: What are your opinions on the relative merits of the stricter
> / more relaxed variants of this proposal? What are your opinions in
> providing both mechanisms via an option?
>
> It would be good to know specifically what scenario caused the
> exception to be created.  On face value, I agree with you: the
> exception doesn't seem to belong. GET might be unique in the sense
> that it is heavily used, but from the perspective of how credentials
> are used and the damage that might be caused, a complete separation is
> cleaner.  More so, the exception is surprising.
> _______________________________________________
> dev-security mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security
>
>