- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 26 Mar 2008 17:49:11 -0700
- To: Eric Lawrence <ericlaw@exchange.microsoft.com>
- CC: Sunava Dutta <sunavad@windows.microsoft.com>, Ian Hickson <ian@hixie.ch>, "Web API WG (public)" <public-webapi@w3.org>, "public-appformats@w3.org" <public-appformats@w3.org>, Chris Wilson <Chris.Wilson@microsoft.com>, Zhenbin Xu <zhenbinx@windows.microsoft.com>, Gideon Cohn <gidco@windows.microsoft.com>, Sharath Udupa <Sharath.Udupa@microsoft.com>, Doug Stamper <dstamper@exchange.microsoft.com>, Marc Silbey <marcsil@windows.microsoft.com>, David Ross <dross@windows.microsoft.com>, Nikhil Kothari <nikhilko@microsoft.com>
Eric Lawrence wrote: > Ian-- > > Thanks for sharing your opinions. I'd like to take the opportunity to clarify a few points of confusion. > > <<This is blatently untrue, a number of serious security problems with XDR > have already been raised (such as the fact that it encourages content-type > sniffing > > It's possible that you overlooked some mails on the thread? > > Vis-à-vis content-type sniffing, it was plainly stated that Content-Type sniffing is neither recommended, nor necessary. I think you are misunderstanding the issues Ian has raised. Since XDR does not let you set the Content-Type header, the server is in fact required to sniff the content type. How else would the server figure out the content type of the request body? > Any service which requires a client-sent Content-Type must be aware of the threat that the Content-Type header so sent is misleading and represents an attempt to attack the server. As XDR will not allow setting of the header (a change made based on feedback from this group), there is no possibility that a service developer will mistake the request header as authoritative. I think you are misunderstanding the issues Ian has raised. The issue isn't that the server treats the Content-Type as authoritative and then trips over while trying to parse it, but rather that servers will sniff the content, misunderstand what content type it really is, and then do the wrong thing with it. Off the top of my head I don't really see any security issues with the sniffing (although sniffing is in general bad so I wouldn't be surprised if there are any), but rather it just doesn't seem like a very robust API and something that could loose out on functionality. > When this change is made, XDR will be unable to emit anything which could not have been sent by HTML forms. In this way, we can demonstrate that XDR does not introduce new attack surface in the browser platform. As well as adding much less value. > <<the fact that it encourages people to pass their credentials > to untrusted third parties).>> > > XDR is a truly anonymous request and does not send credentials to ANY site (1st party, 3rd party), trustworthy or not. In this way, we have high confidence that there is no possibility of executing a CSRF attack against an unsuspecting legacy server which uses cookies or HTTP authentication. Again, this is not the concern. The concern is sites that do want to transport private data. They are going to try to do this weather the browser provides the API meant for this or not. In fact, I would argue that XDR does encourage sending private data. Most use cases for POST that I can think of involves knowing who the data is coming from. Or have you had other use cases in mind? The simplest way to authenticate fetching private data using XDR is to ask the user for his/her credentials and then include that as part of the uri in a GET request. This has two problems. 1. It means that the user will have to give his/her credentials to the requesting site. This fosters a culture where you hand out your password to 3rd party sites, something that is really unsafe. 2. Including the credentials in the uri will most likely mean that it will get logged in various places along the way. For example proxies as well as browser extensions often track uris of loaded resources. Sure, you can say "hey, we said you shouldn't fetch private data using XDR, it's your own fault for doing so". However that doesn't really help anyone. Additionally, it is not true that no authorization credentials is being sent. Intranet sites might authorize simply based on the fact that you can connect to the intranet server. I have still not seen anything in the XDR spec to prevent internet->interanet POSTs so this still seems to be the case. > This can be contrasted with the CS-XHR proposal, in which credentials ARE automatically passed to 3rd party servers. But the credentials are kept away from the 3rd party site as well as kept out of server logs. > <<It fails to address the majority of use cases for cross-domain data > transfer on the Web.>> > > I think this will prove to be a difficult statement to prove one way or another. It is always challenging to enumerate the universe of current use-cases, let alone accurately predict those which will arise in the future. We absolutely agree that it is possible to define use cases that XDR does not accommodate. We believe that XDR enables the most common cross-domain scenarios with negligible impact to the attack surface of existing servers and the browser. > > We have been contributing to the Access Control spec for some time, and we recognize the work that has gone into the CS-XHR proposal. I definitely appreciate all the work that Microsoft has put into the spec, but am saddened that there was no mention about XDR in any of the numerous posts from anyone at microsoft. / Jonas
Received on Thursday, 27 March 2008 00:51:03 UTC