- 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>
* 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 http://lists.w3.org/Archives/Public/public-appformats/2008Apr/0073.html 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