[cap-talk] Fwd: [cors] TAG request concerning CORS &Next Step(s)

[Toby Murray]

On Thu, 2009-06-25 at 18:45 -0700, David Wagner wrote:
> Toby Murray  wrote:
> >On Thu, 2009-06-25 at 15:55 -0700, David Wagner wrote:
> >> Toby Murray  wrote:
> >> > How could you convince the CORS crowd this this doesn't "sound like a
> >> > pain"?
> >> 
> >> Security is often a pain.  Could you elaborate on why/how the Origin:
> >> header makes this case less of a pain?
> >
> >No; I can't do that. I'm not arguing that CORS is less of a pain. I was
> >quoting Adam Barth, who did make this claim. I'll certainly argue that
> >the CORS folks believe the unguessable tokens approach is (more of) a
> >pain (than  CORS). Despite appearances to the contrary, I've never
> >believed this to be so. I'm just trying to distill an argument against
> >the idea that unguessable tokens are more of a pain than CORS by playing
> >devil's advocate. 
> 
> Hmm.  I think the first step for anyone who wants to put together such
> an argument is to understand the problem domain as well as (if not better
> than) the folks you are arguing with.  This means understanding, in great
> detail, the problem requirements, the security and functionality goals,
> the pragmatic engineering constraints, etc.  It's hard to contribute to
> a technical discussion without that background.  (And this is something
> Adam has consistently done extraordinarily well in his research.)

I agree. This is why I've posted here rather than public-webapps. 

> I'll put it another way.  It sounds like you are starting from the
> position that the unguessable tokens approach just has to be better than
> the Origin: header approach, and now you're looking for arguments to
> support that position.  Well, without deep domain knowledge, how do you
> know for yourself that it's better (let alone convincing anyone else)?
> How do you even know what "better" means, in this context?

That's probably true. Very astute. I see where you're going.

> In this case, you provided a particular example problem statement, and
> claimed that the Origin: header has obvious advantages over unguessable
> URLs for that problem statement.  If you're going to make that claim,
> I think you should be prepared to defend it.

I should have been more precise earlier. I began by quoting Adam's
statement which implied that the Oigin: header approach had advantages
in the case he mentioned, which I also quoted. Later I repeated this
position without quoting Adam (hence, you're right, I did make this
claim). This contradicts my statement above that I don't believe the
Origin: approach has advantages over ungessable tokens.

This contradiction exists because I'm 100% convinced either way. I
understand the pincipled arguments against Origin: (rooted in
CSRF-as-Confused-Deputy etc. and captured by Tyler's "ACL's Don't").
However, I also defer to Adam's expertise in this area. As you said
above, he has an incredibly deep understanding of the problem domain --
orders of magnitude deeper than my own. My indecision is apparent in the
contradictory positions I've taken here. My apologies for that.

> You say that you're just copying this claim from Adam, but I'm not sure
> whether that's exactly the claim that Adam made.

I've tried not to stray from Adam's claim, having quoted his text a few
times in this thread. However, I probably have deviated from it,
extrapolating a few times in order to try to defend the position that
the Origin: header may have advantages in the scenario he described.#

>   It's one thing to say
> that the Origin: header is generally easier to use, and another to say
> that it's easier to use for this specific example. 

I've never said the former. I have said the latter; although, I'm still
undecided on that point. I'll also admit that there is a difference
between "easier to deploy" and "defends against certain attacks" (like
impersonating an origin or stealing a capability or whatever. I think
these two things have been conflated by me (and possibly others) in this
discussion. From the start, I've failed to articulate the exact
requirements that any unguessable-tokens alternative needs to meet. I
should have done that but didn't have enough context from Adam's
original post to do so confidently. I now see that this failure made
this venture less useful than it might otherwise have been.

[snipping stuff I totally agree with]

> When discussing web security, there's an important difference between
> (i) defenses that are intended to be deployable immediately, despite all
> the warts of the current web architecture, and that try to incrementally
> improve things, even if they aren't perfect, vs (ii) solutions that try
> to provide a clean, principled, long-term solution but may be harder to
> deploy or represent a greater change from the current web.  Personally, I
> think both kinds of work are valuable.  We shouldn't discount the benefit
> of partial solutions that have known imperfections but that meet the
> pragmatic engineering constraints out there today and are immediately
> deployable.  When advocates of short-term "do-the-best-you-can"
> engineering and advocates of long-term, clean, principled solutions get
> together, it's easy to talk past each other if we forget the difference
> in goals and mindsets between these two communities.

Indeed. However, how does one ever see principled solutions deployed
when it will always be easier to apply short-term fixes one atop the
next. (This is probably why we have anti-virus software rather than POLA
and formally verified code, both of which are harder to do (the latter
orders of magnitude more) than deploy AV software.) The goal must then
to be to make the principled solution much easier to use than the
short-term fix, if the former is ever to see the light of day.

Thanks for the enlightening discussion.

Toby