Re: Proposed CSRF countermeasure

Thanks for the interesting proposal.  You mentioned briefly in the original
message that you decided not to target cookies with this policy because
they are “already ugly, clunky and broken”.

  I’d like to see more explanation and exploration of why such a policy
doesn't belong as part of the artifact you’re trying to control: either
attached directly to cookies, or as part of the problem statement for
successor session management mechanisms currently under discussion at the
WebSec WG in the IETF.

 https://datatracker.ietf.org/doc/draft-ietf-websec-session-continue-prob/

 Note that document does NOT currently include CSRF protections in the
motivation or requirements section.  I'd speak up on websec@ietf.org if you
think it ought to.

  The complexity cost of introducing a distinct header to modify cookie
behavior independently of Set-Cookie, the implementation cost and
complexity of adding more and independent long-term state to the UA in
addition to cookies, as well as the real performance and manageability cost
of pre-flight requests, are all pretty serious obstacles here, in addition
to the weaknesses and compatability issues mentioned by M. Zalewski.

  I see that the exception mechanism is something not easy to store as
client-side state, but I wonder what benefits are gained by having the
server express a policy as part of a pre-flight that the client must then
apply, vs. just having the server decide which cookies it will ignore for a
given request based on a Referer or Origin header?  It will have to anyway,
for legacy UAs.

-Brad



On Tue, Aug 20, 2013 at 12:07 PM, Michael Shema <mshema@qualys.com> wrote:

>
> On Tue, Aug 20, 2013 at 1:54 AM, John Wilander <john.wilander@owasp.org>wrote:
>
>> 2013/8/15 Mike Shema <mshema@qualys.com>
>>
>>> An SOS policy may be applied to one or more cookies for a web
>>> application on a per-cookie or collective basis. The policy controls
>>> whether the browser includes those cookies during cross-origin requests. (A
>>> cross-origin resource cannot access a cookie from another origin, but it
>>> may generate a request that causes the cookie to be included.)
>>
>>
>> Michal mentioned it but it wasn't clear to me – does your proposal apply
>> only to CORS or to all cross-origin requests (iframes, frame sets, images,
>> scripts, style sheets, form gets/posts etc)?
>>
>>    Regards, John
>>
>
> It applies to all cross-origin requests since those are the potential
> attack vector for CSRF. In practice, a policy would only be necessary for
> areas with CSRF potential. For example, there's likely no reason to worry
> about CSRF and pulling resources from a CDN, not to mention that could be a
> different origin from the protected target anyway. No requests would be
> prevented, but a cookie could be excluded from a request based on a policy.
>
> The original reference to CORS was focused on adopting its concept of
> pre-flight requests for the purpose of the browser asking, "Should I
> include or exclude this cookie with a cross-origin request?" (As well as
> being able to cache responses to reduce bandwidth overhead.)
>
> Many sites expect incoming cross-origin requests. Not all incoming
> requests touch a resource that carries risk with regard to CSRF. Hence, the
> proposal aims to allow an exception-based policy where it would (or at
> least, should) be easy to accommodate "safe" requests while still being
> able to block cookies (i.e. a security context) for sensitive resources.
>
> Thanks,
> Mike
>
>
>
>