Re: Proposed CSRF countermeasure

I guess I question the consistency of the reasoning here.   On the one
hand, you say it's a good idea to make server-side decisions, e.g. in a
WAF, to manage exceptions and set the policy in the first place.   On the
other, you say it's not a good idea to insist the server have knowledge of
the invocation safety of its own resources.

 Why couldn't decisions about which cookies to strip also be made by a WAF
with the same level of configuration and knowledge of application structure
as is needed for SOS?


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

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