Re: Proposed CSRF countermeasure

On Mon, Aug 26, 2013 at 1:39 PM, Brad Hill <hillbrad@gmail.com> wrote:

> 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.
>

Part of the motivation behind using a header vs. decorating the cookie was
the desire to make retrofitting easier. For example, using an inline
proxy/WAF rather than digging into cookie APIs or touching the app's code.
(Admittedly, this starts to blur the distinction between design and
implementation of a control.) Another was wondering if the SOS concept
might be expanded or redirected into controls that affect the instantiation
of other objects, of which including cookies with a request are one
example. I will make a better case with regard to the cookie (either for or
against -- I'm not beholden to the proposal, just the idea of improving
countermeasures).

Thanks for the reference to the IETF link.


>   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.
>
Yes, the "return to" type of URL is the "unsafe-inline" weakness for sites
that rely on that kind of pattern and have no additional authz checks on
such pages. I do think there are other situations and site architectures
for which the proposal could be beneficial and provide strong security. It
makes the solution less universal, but not useless.

Performance and manageability remain important and deserve some reference
data to put it in a good light. I'm working on that.

  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
>
Being able to have the server knowledgeably decide which cookies to ignore
and when is essentially the problem of CSRF. Building such logic on the
server-side would be similar to applying CSRF tokens in terms of an
effective countermeasure.

One way to look at SOS is through a lens like the state of X-Frame-Options.
Sites need to rely on JavaScript-based anti-framing for legacy browsers,
but may depend on XFO for modern browsers. CSRF tokens would be a migration
path to SOS. Some apps may expect user populations with legacy browsers and
find little benefit from this, others may expect modern browsers that
support HTML5 features and may find it easier to embrace this approach. (Or
an app may have no current protection and find that SOS offers an
incremental improvement for some users.)

Thanks for your feedback.
-Mike




>
> 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
>>
>>
>>
>>
>