Re: Proposed CSRF countermeasure

On Tue, Aug 27, 2013 at 12:54 PM, Brad Hill <hillbrad@gmail.com> wrote:

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

The point is in the complexity of identifying, tracking, and managing
server-side decisions. Where CSP tries to mitigate the *impact* of XSS
rather than fix it (everyone still insists on server-side data validation),
this is motivated by the desire to simplify how apps may control a user's
session context with regard to a resource.

My stance is better interpreted as it's not a good idea to expect the
server's knowledge to always be complete or its invocation without flaws.
One example I used was Wordpress' /wp-admin/ directory. Wordpress has
strong anti-CSRF tokens. But some plugins forget to implement them.
Consequently, they become unnecessarily vulnerable. This SOS idea was to
make available a countermeasure that affects how resources receive session
state (i.e. cookies) rather than a countermeasure that makes forgery more
difficult. And do so in a way that might be easier than current
countermeasures.



>  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?
>
>
They could; I wanted to explore stronger ways to establish security between
site and User Agent without intermediary components.

-Mike




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