W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [cors] security issue with XMLHttpRequest API compatibility

From: Tyler Close <tyler.close@gmail.com>
Date: Tue, 7 Apr 2009 17:55:34 -0700
Message-ID: <5691356f0904071755v7024bc97wbd4c9146e9e3b0d1@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: public-webapps@w3.org
On Tue, Apr 7, 2009 at 5:29 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Tue, Apr 7, 2009 at 4:16 PM, Tyler Close <tyler.close@gmail.com> wrote:
>> On Tue, Apr 7, 2009 at 3:57 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> My point is that having two APIs that are identical and intended to be
>>> used for basically the same thing, except for that they use different
>>> security models, is a security bug waiting to happen.
>> So you do of course realize that this is exactly what the WG is
>> currently proposing, right? Browser version X will have an XHR with
>> one security model and browser version X+1 will have an identical XHR
>> API with a different security model.
> But it's for a limited time. In a few years hopefully all browsers
> supports cross site XHR.

So, in your words, for "a few years" we have "a security bug waiting to happen"?

I'm also skeptical that it's just a few years, since it's not just the
browser upgrade cycle, but the web-application upgrade cycle. By
definition, all the XHR code out there today is written to a different
security model than the one this WG proposes. This WG further proposes
to substitute its more liberal security model, without opt-in from the
existing application code.

> You are proposing a model where there's two types of XHR objects. One
> where we specifically tell users that you can rely on the request
> won't be sent cross site, and one where you can't.

I'm proposing that we leave the existing security model in place and
provide a switch that applications must flip in order to swap in the
new security model. I've proposed a design where flipping this switch
requires minimal changes to existing application code. There's nothing
radical about this proposal, it's just the way things are done when
you're being careful.

Received on Wednesday, 8 April 2009 00:56:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:25 UTC