W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

Re: IE Team's Proposal for Cross Site Requests

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Thu, 15 May 2008 02:00:05 +0200
To: Chris Wilson <Chris.Wilson@microsoft.com>
Cc: "public-webapi@w3.org" <public-webapi@w3.org>, Sunava Dutta <sunavad@windows.microsoft.com>
Message-ID: <7lkm24p4n8gn0k05mfu0kssmh5a7pk286k@hive.bjoern.hoehrmann.de>

* Chris Wilson wrote:
>This sound like nothing short of demonstrating actual exploits against
>the design will demonstrate to you that it might be vulnerable.  Have
>you actually looked into secure coding principles at all?  Even, say,
>Writing Secure Code[1]?

I bought mine in the Microsoft MVP store back when I had points to spend
there, and read it cover to cover. However, I don't think discussing our
reading habits or who's got the bigger market share will do this dis-
cussion much good. What you wanted to say inevitably got lost in all the
lines of your message that deal only with what Ian said, and he did not
contribute much in his message to begin with.

In evaluating Microsoft's XDR proposal I believe two questions are most
important. First, how well does it address what people actually want to
do in terms of cross site requests. The mechanism is very crude, you can
not use methods other than GET and POST, you can't set headers, you have
no standard methods for authentication, you can only transfer strings,
you have to be able to manipulate the HTTP header, and it only works if
you can use the special new API, not if you use some other methods to
embed external resources.

If that is all developers want to do, XDR may be quite suitable. If, on
the other hand, developers actually need and want additional methods,
authentication, transfer data that isn't simply a string conveniently,
and other things, it is quite possible they will come up with crude ad-
hoc work arounds to address their requirements, and are highly likely to
implement security vulnerabilities in their applications in the process;
more so if many different applications require different workarounds.

It does not matter all that much to most users whether they get screwed
because of a browser bug, or a web site bug. It appears that Microsoft
realizes as much, citing how easily other solutions are misconfigured as
one motivation for the XDR work, but it is very much unclear to me why
developers are not going to make grave errors when setting up XDR-based
sites and services.

The second questions is simply whether this is all. Is there going to be
an "XDRv2" in "IE9" with more developer aids to build secure cross site
setups? Or other solutions in other Microsoft products? The latter would
seem to be so in the case of the next version of Microsoft Silverlight.

In the current Beta version you will find many of the things we hear are
bad from the Internet Explorer Team, that is, policy files, cookies are
sent, the same APIs are used for same-domain and cross-domain requests,
and while there are two differnt kinds of policy files, and an upcoming
full cross-domain model for socket access. But no apparent XDR support.

Improved support for web services of all kinds, including cross domain
access, is one of the main marketed features of the next Silverlight re-
lease, and I have great difficulty imagining that either will be dropped
or that Silverlight will simply switch to using XDR only, and it's less
than three months now that Silverlight 2 is supposed to be released to
all those wanting to access NBC's Summer Olympics coverage.

That Microsoft itself cannot agree on one technology, or at least only
one philosophy to approach the problem does not inspire confidence in
any of the solutions, and the prospect of having to cope with several
new cross domain access solutions, even though we already have too many,
is rather worrying.

Personally speaking, the IE Team's emphasis on security and simplicity
is a welcome contrast to the XHR2+AC design team's emphasis on broad
applicability, ease of deployment, and efficiency, but XDR is so limited
in its ability that I might aswell continue using remote <script>s and
HTML form posts, that at least works everywhere and the security impli-
cations are well-known.
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Thursday, 15 May 2008 00:00:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:26 UTC