Re: First-Party-Only cookies

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