Last Word-ism (was: Re: UMP / CORS: Implementor Interest)

On Wed, May 12, 2010 at 10:02 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Wed, 12 May 2010, Tyler Close wrote:
> >
> > So HTML is not vulnerable to Cross-Site Scripting, C++ is not vulnerable
> > to buffer overflows and so CORS is not vulnerable to Confused Deputy.
>
> Correct.
>
>
> > As explained above, CORS with credentials is intrinsically vulnerable to
> > Confused Deputy. The use of credentials forces the developer to consider
> > Confused Deputy vulnerabilities.
>
> You are using the word "vulnerable" in a manner inconsistent with its
> meaning in the Web standards community.
>
>
> > > It's just as possible to make bad designs using UMP than with CORS.
> >
> > It's rare that a tool makes bad design impossible. Are you saying that's
> > the metric for comparing the security of two tools? So long as bad
> > design is possible, the two tools are equivalent?
>
> You seem to be arguing that as long as bad design is possible, a tool
> shouldn't be made available at all! [1]
>
> [1]
> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0604.html
>
>
> > > (I would argue that UMP actually makes it more likely that designs
> > > will have poor security characteristics since it ends up being easier
> > > to ask for the user's credentials directly than doing the right thing.
> > > With CORS, on the other hand, it's easier to use the user's existing
> > > session, so it's less likely that people will ask for credentials
> > > inappropriately.)
> >
> > But you haven't considered the dangers that come from reusing the user's
> > existing session. That's an inherently dangerous thing to do, but you
> > seem to ignore the problem and so come to the conclusion you want.
>
> It is not an inherently dangerous thing to do, that's hyperbole. It is
> certainly possible to use this tool wrongly, e.g. by executing actions on
> the behalf of another origin, but is anyone suggesting doing that?
>
> It would be helpful if we could focus on concrete use cases, so that we
> could document them and add offer them to Anne to add to the CORS spec.
>
>
> > > What use cases would you like examples for? Let's write them up and
> > > give them to Anne to the introduction section.
> >
> > I want to see CORS try to develop something like the Security
> > Considerations section in UMP with simple, clear choices for application
> > developers to consider. I want this advice to be feasible to follow and
> > to provide a robust defense against Confuse Deputy problems. I doubt
> > such advice can be provided for CORS.
>
> I'm interested in providing authors with concrete examples based on
> real-world use cases. What use cases are you concerned about? I see no use
> cases in the section to which you refer, only abstract advice:
>
>   http://dev.w3.org/2006/waf/UMP/#security
>
>
> > Confused Deputy attacks cannot be fixed by escaping data. There may be
> > no static test that can be done to validate an identifier.
>
> Then don't use identifiers of this nature.
>
>
> > It is a strange security model that says the client must completely
> > validate the request before submitting it.
>
> It's how all the technologies on the Web so far have been secured. While
> it may be academically strange, it is the only security model Web authors
> are familiar with, so to them it isn't strange at all. XSS, XSRF, SQL
> injection -- all these classes of problems are addressed by validating
> data in the request before acting on it or passing it on to the next
> system. You may not like this kind of design, but it's what authors are
> most used to.
>
>
> > Yes, well, that's what I'm trying to do. By refusing to admit that tools
> > contribute to bugs in any way, you are doing the opposite.
>
> To be blunt: browser vendors have said they are implementing CORS, and
> that UMP isn't enough. Continuing to argue against this isn't working. If
> you want CORS replaced with something else, you need to find something
> that will convince browser vendors; repeating your claims that the CORS
> technology is vulnerable is merely distancing you further from the rest of
> the working group and is more likely to make any further advice you may
> have get ignored as well.
>

Hi Ian, I detect genuine concern in your last statement above, so I'm sure
the following observation does not indicate any malicious intent. Please do
not take it otherwise. I think what is going on is only that good debaters
can fall into rhetorical habits that are more effective than they are
legitimate. Responding in kind to your concern, I'd like to alert you to the
possibility that you may be doing that.

You (and many others here) are placing Tyler in a no win bind. You are
repeating fallacies that have already been repeated dozens of times in this
thread, and that Tyler has already responded to dozens of times. When you
repeat them yet again, if Tyler responds yet again, you and many others on
in this forum accuse him of repeating old arguments. Should Tyler not
respond, then the fallacies rest on the "legitimacy" simply of being
repeated so often as to wear out anyone's ability to respond, and especially
of anyone's patience at putting up with asymmetric criticisms about
repeating arguments.

While on the one hand you and others are perpetuating this loop, Dirk, Adam,
and Tyler are advancing the conversation in fresh ways. I think the search
for an actual three party CORS deployment that can be reviewed is a great
challenge. No matter how it turns out, I expect us all to learn a lot --
much more so than repeating schoolyard debating tactics. I suggest holding
back on your own repetition and instead letting this conversation proceed.


You do raise one new point here, the use of the term "vulnerability".
Tyler's use of the term is correct regarding the security community's use of
the term. Regarding the web standards community, I defer to your judgement
and experience. As a security person I would say "html is vulnerable to XSS"
or "html has XSS vulnerabilities". As someone participating in web
standards, what word would you have me substitute?


>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
>


-- 
    Cheers,
    --MarkM