IE Team's Proposal for Cross Site Requests

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
122 messages Options
1234567
Reply | Threaded
Open this post in threaded view
|

Re: Seeking XDR versus AC4CSR+XHR2 follow-ups by Microsoft [Was: Re: IE Team's Proposal for Cross Site Requests]

Jonas Sicking-2

I'm not quite sure I understand why the answers to technical questions
about the security model is affected by strategic decisions about how to
move forward. I would have expected the dependency to go the other way
around.

I'm also not sure how you could be surprised by the WGs vote not to
replace years worth of work with a completely different and incompatible
proposal. Especially when any security concerns could have been
addressed by tweaks to the existing specification.

That said, I'm looking forward to your answers to our questions.

Best Regards,
Jonas Sicking

Sunava Dutta wrote:

> Art,
> I apologize for the delay but we're currently coming up with a plan moving forward to regarding how we want to proceed with cross domain. Our timeframe for responses to the questions below is tied to that plan. As you can imagine, the Web API's support for XDR is something we believe would go a long way towards securing cross domain. The current WG decision based on the survey will cause us to re-strategize significantly.
> Chris, out platform architect will get back soon with a response.
>
>
> -----Original Message-----
> From: Arthur Barstow [mailto:[hidden email]]
> Sent: Friday, May 02, 2008 3:57 AM
> To: Sunava Dutta; Eric Lawrence; Chris Wilson
> Cc: ext Anne van Kesteren; Web API WG (public); [hidden email]; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Marc Silbey
> Subject: Seeking XDR versus AC4CSR+XHR2 follow-ups by Microsoft [Was: Re: IE Team's Proposal for Cross Site Requests]
>
> Sunava,
>
> Several of the active contributors of the AC spec and XHR{2} specs
> have now asked you and your colleagues for follow-ups before a voice
> conference.
>
> Would you folks please follow the four UIRs Anne listed below and
> provide feedback as requested?
>
> -Regards, Art Barstow
>
>
> On Apr 23, 2008, at 4:31 AM, ext Anne van Kesteren wrote:
>
>> On Wed, 23 Apr 2008 10:01:33 +0200, Anne van Kesteren
>> <[hidden email]> wrote:
>>> On Wed, 23 Apr 2008 04:26:39 +0200, Sunava Dutta
>>> <[hidden email]> wrote:
>>>> Thanks for the participation and comments.
>>>> I think this discussion is best continued in a telecon. I'm
>>>> working with Doug Schepers to see what we can schedule here.
>>>> Once again, thanks for sharing thoughts and providing feedback.
>>> Wouldn't it be better if the IE Team first addressed the issues
>>> raised so far with XDomainRequest in an e-mail? Getting this
>>> information in a teleconference is not very convenient as minutes
>>> are often of poor quality and teleconferences don't allow for
>>> thinking arguments through and studying them.
>> I was told it would be good to point out some of those e-mails.
>> Here's a subset of the e-mails that as far as I can have not been
>> addressed by the IE Team:
>>
>>   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0211.html
>>   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0212.html
>>   http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0125.html
>>   http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0056.html
>>
>>
>> --
>> Anne van Kesteren
>> <http://annevankesteren.nl/>
>> <http://www.opera.com/>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Seeking XDR versus AC4CSR+XHR2 follow-ups by Microsoft [Was: Re: IE Team's Proposal for Cross Site Requests]

Ian Hickson

On Fri, 2 May 2008, Jonas Sicking wrote:

> Sunava Dutta wrote:
> > I apologize for the delay but we're currently coming up with a plan
> > moving forward to regarding how we want to proceed with cross domain.
> > Our timeframe for responses to the questions below is tied to that
> > plan.
>
> I'm not quite sure I understand why the answers to technical questions
> about the security model is affected by strategic decisions about how to
> move forward. I would have expected the dependency to go the other way
> around.

Yeah, I'm confused as to why Microsoft's technical comments on one
specification are being held hostage to Microsoft's overall strategy.

Surely the technical comments are valid independent of your strategy, and
providing them would improve the Web, which I'm assuming is what you want.

After all, you said you had these comments available last November, at the
Boston meeting, and would send them by mid-December!

This does not give a good impression of your commitment to standards.

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

Reply | Threaded
Open this post in threaded view
|

RE: IE Team's Proposal for Cross Site Requests

Sunava Dutta
In reply to this post by Maciej Stachowiak

Maciej wrote:
" I would also prefer to see a clear statement of Microsoft's position
in written form ahead of the telecon. By their nature, these are
issues that need careful analysis, and cannot be evaluated fully in
the context of a teleconference."

I think the request will help discussion. Yes, we will be making our position and points that need further deliberation available in a written form prior to the teleconference.

-----Original Message-----
From: Maciej Stachowiak [mailto:[hidden email]]
Sent: Tuesday, April 29, 2008 5:01 PM
To: Ian Hickson
Cc: Chris Wilson; Anne van Kesteren; Sunava Dutta; Web API WG (public); [hidden email]; Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
Subject: Re: IE Team's Proposal for Cross Site Requests


On Apr 29, 2008, at 2:14 PM, Ian Hickson wrote:

>
> On Tue, 29 Apr 2008, Chris Wilson wrote:
>>
>> Given the multitude of issues raised, and the obvious back-and-forth
>> that denotes many differing opinions, I'd suggest having a telecom to
>> discuss these questions, and make sure that Sunava, Eric and myself
>> can
>> attend.
>
> I'm with Anne on this. Please reply to the e-mails before convening a
> telecon. It is very difficult to carefully consider feedback in the
> context of a telecon.
>
> The problem isn't "back-and-forth" denoting "many differing
> opinions", the
> problem is that we don't know what Microsoft's opinion _is_.
>
> Telecons are by their nature much less open, and minutes are almost
> uniformly so poor that it is hard to impossible to get precise
> technical
> details out of telecons. A telecon would not be appropriate at this
> point.

I would also prefer to see a clear statement of Microsoft's position
in written form ahead of the telecon. By their nature, these are
issues that need careful analysis, and cannot be evaluated fully in
the context of a teleconference.

Regards,
Maciej



Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Charles McCathieNevile-2

There has been rather more to-ing and fro-ing than actual work, it seems.

I am happy to schedule a teleconference, and to ensure that Anne is  
available (as editor of XHR I think he is a critical resource). But we  
need to establish an agenda. (I am also trying to organise a face to face  
meeting to ensure that we can work as rapidly as possible - people are  
implementing stuff now and I would hate things to slow down to the point  
where people effectively opt out of the standards process and just ship  
something different).

Before trying to schedule a teleconference, we need an agenda. As Maciej  
and others have noted, these are potentially complicated issues and we  
need to have reading time before the meeting in order to avoid wasting  
valuable teleconference time.

The results of the survey on simply sopting IE's approach were pretty  
conclusive. The reasons given seem pretty clear, such as a desire not to  
fork requests in the first place, a belief that moving security risk from  
the implementation of requests to each specific use of a request actually  
increases the risk for end-users.

Microsoft apparently feels that there are reasons to implement something  
other than the standard approach being developed, since they did so and I  
presume it was not from bloody-mindedness or ignorance. In order to  
usefully address these issues we need to understand them. Which means we  
are waiting on Microsoft to provide written feedback.

Given the months that elapsed between the last time feedback was promised  
and when it was delivereed, I am reluctant to schedule teleconferences  
before such feedback is provided, at least sufficient to justify holding a  
teleconference.

cheers

Chaals (as chair, webapi woring group)

On Sat, 03 May 2008 00:51:27 +0100, Sunava Dutta  
<[hidden email]> wrote:

> Maciej wrote:
> " I would also prefer to see a clear statement of Microsoft's position
> in written form ahead of the telecon. By their nature, these are
> issues that need careful analysis, and cannot be evaluated fully in
> the context of a teleconference."
>
> I think the request will help discussion. Yes, we will be making our  
> position and points that need further deliberation available in a  
> written form prior to the teleconference.
>
> -----Original Message-----
> From: Maciej Stachowiak [mailto:[hidden email]]
> Sent: Tuesday, April 29, 2008 5:01 PM
> To: Ian Hickson
> Cc: Chris Wilson; Anne van Kesteren; Sunava Dutta; Web API WG (public);  
> [hidden email]; Eric Lawrence; Zhenbin Xu; Gideon Cohn;  
> Sharath Udupa; Doug Stamper; Marc Silbey
> Subject: Re: IE Team's Proposal for Cross Site Requests
>
>
> On Apr 29, 2008, at 2:14 PM, Ian Hickson wrote:
>
>>
>> On Tue, 29 Apr 2008, Chris Wilson wrote:
>>>
>>> Given the multitude of issues raised, and the obvious back-and-forth
>>> that denotes many differing opinions, I'd suggest having a telecom to
>>> discuss these questions, and make sure that Sunava, Eric and myself
>>> can
>>> attend.
>>
>> I'm with Anne on this. Please reply to the e-mails before convening a
>> telecon. It is very difficult to carefully consider feedback in the
>> context of a telecon.
>>
>> The problem isn't "back-and-forth" denoting "many differing
>> opinions", the
>> problem is that we don't know what Microsoft's opinion _is_.
>>
>> Telecons are by their nature much less open, and minutes are almost
>> uniformly so poor that it is hard to impossible to get precise
>> technical
>> details out of telecons. A telecon would not be appropriate at this
>> point.
>
> I would also prefer to see a clear statement of Microsoft's position
> in written form ahead of the telecon. By their nature, these are
> issues that need careful analysis, and cannot be evaluated fully in
> the context of a teleconference.
>
> Regards,
> Maciej
>
>
>



--
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Reply | Threaded
Open this post in threaded view
|

RE: Seeking XDR versus AC4CSR+XHR2 follow-ups by Microsoft [Was: Re: IE Team's Proposal for Cross Site Requests]

Sunava Dutta
In reply to this post by Ben Adida-2

XDomainRequest is optimized for the "public data" use case; it sends anonymous requests that do not carry cookies or credentials.

Obviously, it is possible to create XDomainRequest-based AJAX applications whereby identity or authorization tokens are carried in a request body payload (in JSON/XML/other format) but any server configured to accept such tokens must take steps to mitigate any CSRF vulnerabilities, and should also ensure that proper HTTP caching directives are present on any non-public response.

-----Original Message-----
From: Ben Adida [mailto:[hidden email]]
Sent: Friday, May 02, 2008 3:29 PM
To: Sunava Dutta
Cc: Arthur Barstow; Eric Lawrence; Chris Wilson; ext Anne van Kesteren; Web API WG (public); [hidden email]; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Marc Silbey
Subject: Re: Seeking XDR versus AC4CSR+XHR2 follow-ups by Microsoft [Was: Re: IE Team's Proposal for Cross Site Requests]

Sunava Dutta wrote:
> Art, I apologize for the delay but we're currently coming up with a
> plan moving forward to regarding how we want to proceed with cross
> domain.

Sunava,

I've been lurking on this list for a while, and wanted to ask a question
that I don't think has been answered on the list.

The IE8 White Paper on "Better Ajax Development" says:

"Cross-domain requests are anonymous to protect user data, which means
that servers cannot easily find out who is requesting data. As a result,
you only want to request and respond with cross-domain data that is not
sensitive or personally identifiable."

Is that an accurate representation of MS's position, that XDR should
never be used to request sensitive/private information, only generic
public data?

Thanks,

-Ben Adida
[hidden email]


Reply | Threaded
Open this post in threaded view
|

RE: IE Team's Proposal for Cross Site Requests

Chris Wilson-12
In reply to this post by Sunava Dutta
Indeed, there has been a lot of back and forth on the topics of XDR and XHR2+AC over the last couple of weeks.  This message is not attempting to set forth in detail all the objections we have had; Sunava will deliver that in a concise form. From the comments in various responses in this topic, it is clear that expectations are extremely high for the level of detail in those objections; that takes much time to prepare, and involves a number of people here across multiple teams.  Some of these concerns are direct and technical, and might be fixed in the XHR2+AC draft; however, some of our most important concerns pertain to the approach of enabling cross-domain.

We are interested in participating in standardizing cross-domain access.  We believe quite strongly that cross-domain access is one of the next enabling needs of the web platform, and we are most interested in enabling that in an interoperable way.   However, we feel the design of grafting cross-domain access on to the already-existing XHR system is dangerous, and the current design is being arrived at by the method of discussing what developers want to do, then trying to make it safe, rather than starting with what is secure by principle and incrementally adding functionality.  Experience has taught us it is much easier to ship a system that is secure by design and add functionality than try to secure a implementation after it ships by rolling back features.  For example, today the current XHR draft proposes to block a list of headers that are unsafe only in a cross-domain context; however, this is difficult to deploy since XHR has already shipped, and challenging to imagine that there are no other headers in use by servers anywhere around the world that might not be good to access.

There are fundamental cross domain security principles that we firmly believe need to be guaranteed by a cross domain solution; otherwise, our experience leads us to believe there will be exploits found over time.  Cross-domain access in Flash has had a trail of bugs for these reasons [1].  Sunava will detail these security principles; I believe the XHR2+AC approach can currently be demonstrated to violate these. Even the AC draft itself has a list of security concerns and vague requirements as observed and discussed in the group [2].  Even if current vulnerabilities like exposure to Time of Check, Time of Use, DNS Rebinding attacks, and URL path canonicalization issues can be patched (rather than ignored), we are concerned that this approach to cross-domain access for the browser platform is not based first on security principles.  It is extremely difficult to add security in as a feature after the design is done without creating cracks in that security.  It is also quite difficult to add security on to an already-deployed API without creating large-scale incompatibilities with deployed uses.  For example, is there a blocklist of headers? If so, how will this be maintained as the list of discovered headers grows? Will patching existing implementations in place through an automatic updating mechanism be sufficient to keep customers secure?  In our opinion, one of the fundamental problems with the XHR2+AC proposal is that it blithely reuses an already-existing API for same-domain communication, and then attempts to patch the cracks that appear when it is used to perform cross-domain transfers.

We want to be extremely clear that XDR is most definitely NOT, in our opinion, a “slightly different API that solves nearly the same problem” – neither is it “different for no extra benefit.”   [3]  Nor is it an “incompatible proposal,” [4] since it’s not intended to be merged with XHR or Access Control; it can happily coexist.  XDR is not intended to be a competitor to XHR2+AC; it is different by design, and is focused on a much smaller set of cross-domain access needs.   We believe it a principled and focused design.  It is not, of course, the only principled, focused, or secure design that can be described.

As for the XHR2+AC draft itself, I don't believe we intended anything we ever said to equate to “XHR2+AC is good;" I challenge the assertion of “Microsoft reviews W3C spec as good” [5] as an accurate generalization of what has been said [6].  This message did not claim to reflect a deep technical analysis of its contents of the Access Control draft, but let’s lay aside that concern; it is far more germane that there was no indication that we saw at the time that this access control mechanism would be simply directly applied to the XMLHttpRequest object.  Even according to the designer of Access Control,  the feature was designed for non browser applications, and the idea of enabling AC for the browser platform by applying Access Control to XHR “came as an afterthought.” [7].   As the AC draft has changed over time, and as it was applied to XHR, Microsoft has had increasing concerns over the security of the design of this proposal.  These concerns come from painfully learned lessons about browser security, as we have seen many examples of how violating some basic security principles has led to vulnerabilities in the past.

We’ve given the feedback that we believe this approach to enabling cross-domain is inherently insecure, but unfortunately the working group has not been receptive to these lessons we have learned from our experience.  For example, one response was: “I'm also not sure how you could be surprised by the WGs vote not to replace years worth of work with a completely different and incompatible proposal.  Especially when any security concerns could have been addressed by tweaks to the existing specification.”  [8]  In my opinion, this response is flawed on multiple levels; first, because we had never recommended throwing away all work on XHR2+AC and replacing it with XDR; we’ve suggested that XDR is a focused subset of cross-domain functionality that we believe is securable today.  Certainly, XHR2+AC attempts to enable a lot more functionality; that would assure its place in the future.  Secondly, I would think that issues of security in design would make it obvious that more work is necessary; just because something has been around for a year doesn’t mean it’s right, or that it is the best way of doing something.  Finally, we disagree that the security concerns about XHR2+AC can be addressed by mere tweaks to the technical details.  For example, I pointed out that the flow of this design is inherently open to DNS rebinding attacks [9], as well as other issues we’ve pointed out.  I believe we have several times laid out some of our concerns with the current XHR2+AC method of doing cross-domain; it continues to be claimed that “nobody has responded to the requests for a description of these problems” [10].  I don’t believe that’s appropriate; I think whenever we do describe where we see design flaws and potential exploit area (e.g. [11]), there is a flurry of discussion that results in claims that it’s really not so bad, the exploits can happen in other situations anyway so don’t worry about it; or that such power is needed, and any cross-domain access design that doesn’t enable everything is flawed.

The responses I’ve seen to the issues we have shared on this list have typically been dismissive that there is a problem – or presumptive that the problem can simply be spackled over.  When we do go down detailed discussions, the threads seem to disappear (e.g. [12]).  Alternately, the threads seem to devolve into acrimony, e.g. the back-and-forth over content-typing (where we are told “Stating this doesn’t make it true”). [13]  In short, the discussion has devolved into unsupported sniping [14], including claims that XDR is less secure, that it is “arbitrary,” and that XHR2+AC is technologically superior without any objective measure of such or definition of metrics.

At any rate, focusing on individual technical issues misses the point; spackling security over existing designs to extend them in ways they were not intended is very complex to get right.  We have been calling for simplicity in the underlying design, rather than trying to graft secure cross-domain on to the already-existing APIs; hard experience has led us to be cautious and conservative.  As Jon Ferraiolo of the OpenAjax Alliance said, “security trumps all others [concerns];”  it was gratifying to have his support on the principle of being conservative, and see that some others do recognize that adding incremental complexity to already-existing APIs adds up to “a small beast”. [15]

To address these concerns, we built a simpler, more focused API to enable some set of cross-domain access we felt could be secured, in the most focused way possible.  Unlike Access Control, XDR is modeled off the defacto security policy defined by HTML 4.0 – that is, the prohibition against HTTP methods other than GET and POST and limitations of HTTP headers are in the HTML 4.0 specification and widely used as Tyler Close from HP pointed out to the Web API mailing list.  [16]  Indeed, the Open Ajax Alliance claims that XDR promises to be simpler and more secure [17].

I do want to be clear, since there was some confusion based on a conversation between Charles and Michael Champion – we will be shipping our XDR implementation in IE8 (modified by any feedback we might get before we must lock down for release).  As we’ve said, we'd welcome feedback on XDR [18], and if it is timely enough, it could be incorporated into our IE8 product.   We would of course be happy if this minimal, secure subset were to be accepted as a submission by the WG, turned into a deliverable and improved by an open standards process – and if that were the case, I believe it would be our responsibility to modify our implementation to comply with the (eventual) standard.  However, we recognize that the Web API WG has voted informally to not pursue the XDR submission; in our view that makes it more imperative that the WebAPI’s design be made really secure if it is to be a W3C Recommendation and the only way to interoperably enable access across domains; but this does not change the customer need for us to ship a secure subset of cross-domain capabilities in this release of IE.

We will of course continue to participate in the Web API WG’s work on cross-domain access, and I hope that work can be made secure to our satisfaction (and therefore implementable in IE); but we simply cannot implement APIs that we believe expose customers to security exploits.  We desire interoperability; we cannot enable that at the expense of security.

-Chris

[1] http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html
[2] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0150.html
[3] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0205.html
[4] http://lists.w3.org/Archives/Public/public-webapi/2008May/0028.html
[5] http://www.w3.org/2008/Talks/0421-ac-tbl/#(4)
[6] http://lists.w3.org/Archives/Public/public-appformats/2007May/0029.html
[7] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0154.html
[8] http://lists.w3.org/Archives/Public/public-webapi/2008May/0028.html
[9] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0114.html
[10] http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0209.html
[11] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0114.html
[12] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/050.html
[13] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0211.html
[14] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0206.html
[15] http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0099.html
[16] http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0095.html
[17] http://www.regdeveloper.co.uk/2008/03/28/openajax_alliance_internet_explorer_eight/
[18] http://lists.w3.org/Archives/Public/public-appformats/2008Mar/0017.html


-----Original Message-----
From: Charles McCathieNevile [mailto:[hidden email]]
Sent: Monday, May 05, 2008 7:30 AM
To: Sunava Dutta
Cc: Chris Wilson; Web API WG (public); [hidden email]; Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
Subject: Re: IE Team's Proposal for Cross Site Requests

There has been rather more to-ing and fro-ing than actual work, it seems.

I am happy to schedule a teleconference, and to ensure that Anne is
available (as editor of XHR I think he is a critical resource). But we
need to establish an agenda. (I am also trying to organise a face to face
meeting to ensure that we can work as rapidly as possible - people are
implementing stuff now and I would hate things to slow down to the point
where people effectively opt out of the standards process and just ship
something different).

Before trying to schedule a teleconference, we need an agenda. As Maciej
and others have noted, these are potentially complicated issues and we
need to have reading time before the meeting in order to avoid wasting
valuable teleconference time.

The results of the survey on simply sopting IE's approach were pretty
conclusive. The reasons given seem pretty clear, such as a desire not to
fork requests in the first place, a belief that moving security risk from
the implementation of requests to each specific use of a request actually
increases the risk for end-users.

Microsoft apparently feels that there are reasons to implement something
other than the standard approach being developed, since they did so and I
presume it was not from bloody-mindedness or ignorance. In order to
usefully address these issues we need to understand them. Which means we
are waiting on Microsoft to provide written feedback.

Given the months that elapsed between the last time feedback was promised
and when it was delivereed, I am reluctant to schedule teleconferences
before such feedback is provided, at least sufficient to justify holding a
teleconference.

cheers

Chaals (as chair, webapi woring group)

On Sat, 03 May 2008 00:51:27 +0100, Sunava Dutta
<[hidden email]> wrote:

> Maciej wrote:
> " I would also prefer to see a clear statement of Microsoft's position
> in written form ahead of the telecon. By their nature, these are
> issues that need careful analysis, and cannot be evaluated fully in
> the context of a teleconference."
>
> I think the request will help discussion. Yes, we will be making our
> position and points that need further deliberation available in a
> written form prior to the teleconference.
>
> -----Original Message-----
> From: Maciej Stachowiak [mailto:[hidden email]]
> Sent: Tuesday, April 29, 2008 5:01 PM
> To: Ian Hickson
> Cc: Chris Wilson; Anne van Kesteren; Sunava Dutta; Web API WG (public);
> [hidden email]; Eric Lawrence; Zhenbin Xu; Gideon Cohn;
> Sharath Udupa; Doug Stamper; Marc Silbey
> Subject: Re: IE Team's Proposal for Cross Site Requests
>
>
> On Apr 29, 2008, at 2:14 PM, Ian Hickson wrote:
>
>>
>> On Tue, 29 Apr 2008, Chris Wilson wrote:
>>>
>>> Given the multitude of issues raised, and the obvious back-and-forth
>>> that denotes many differing opinions, I'd suggest having a telecom to
>>> discuss these questions, and make sure that Sunava, Eric and myself
>>> can
>>> attend.
>>
>> I'm with Anne on this. Please reply to the e-mails before convening a
>> telecon. It is very difficult to carefully consider feedback in the
>> context of a telecon.
>>
>> The problem isn't "back-and-forth" denoting "many differing
>> opinions", the
>> problem is that we don't know what Microsoft's opinion _is_.
>>
>> Telecons are by their nature much less open, and minutes are almost
>> uniformly so poor that it is hard to impossible to get precise
>> technical
>> details out of telecons. A telecon would not be appropriate at this
>> point.
>
> I would also prefer to see a clear statement of Microsoft's position
> in written form ahead of the telecon. By their nature, these are
> issues that need careful analysis, and cannot be evaluated fully in
> the context of a teleconference.
>
> Regards,
> Maciej
>
>
>



--
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com
Reply | Threaded
Open this post in threaded view
|

RE: IE Team's Proposal for Cross Site Requests

Chris Wilson-12
Right you are, on both points.  My apologies.

-----Original Message-----
From: Bjoern Hoehrmann [mailto:[hidden email]]
Sent: Friday, May 09, 2008 3:08 PM
To: Chris Wilson
Subject: Re: IE Team's Proposal for Cross Site Requests

* Chris Wilson wrote:
>Even according to the designer of Access Control,  the feature was
>designed for non browser applications, and the idea of enabling AC for
>the browser platform by applying Access Control to XHR “came as an
>afterthought.” [7].

>[7] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0154.html

Henri is talking about his validator.nu site, not about "Access Control"
(neither is he "the designer of Access Control").
--
Björn Höhrmann · mailto:[hidden email] · 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/
Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Henri Sivonen

(Quotes reordered.)
On May 10, 2008, at 01:46 , Chris Wilson wrote:

>
>> * Chris Wilson wrote:
>>> Even according to the designer of Access Control,  the feature was
>>> designed for non browser applications, and the idea of enabling AC  
>>> for
>>> the browser platform by applying Access Control to XHR “came as an
>>> afterthought.” [7].
>>
>>> [7] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0154.html
>>
>> Henri is talking about his validator.nu site, not about "Access  
>> Control"
>> (neither is he "the designer of Access Control").

> Right you are, on both points.  My apologies.


Moreover, the way my message was quoted misses the point of my  
message. The point is this:

I designed RESTful Web service APIs according to best practice with  
knowledge that the APIs would be called by untrusted HTTP clients out  
there. Those HTTP clients could be of any kind from my point of view--
currently browsers just refuse.

With access-control, I was able to add a policy that will make  
browsers not refuse in one place without changing my RESTful API  
design and without changing the way a client script programmer sees  
the API.

All three competing proposals (XDR, JSONRequest and postMessage
+iframe) would require me to add a new API design alongside the ones I  
already have and tailor it to the whims of the competing proposal.

--
Henri Sivonen
[hidden email]
http://hsivonen.iki.fi/



Reply | Threaded
Open this post in threaded view
|

RE: IE Team's Proposal for Cross Site Requests

Ian Hickson
In reply to this post by Chris Wilson-12
On Fri, 9 May 2008, Chris Wilson wrote:
>
> Sunava will deliver [all the objections we have had] in a concise form.
> From the comments in various responses in this topic, it is clear that
> expectations are extremely high for the level of detail in those
> objections; that takes much time to prepare [...]

I don't think anyone expects Microsoft's long-promised feedback to be any
more detailed than anyone else's feedback. Sunava said last November that
this feedback would be sent as soon as possible. As far as I know, nobody
else spent six months writing up their feedback.


> For example, today the current XHR draft proposes to block a list of
> headers that are unsafe only in a cross-domain context; however, this is
> difficult to deploy since XHR has already shipped

This is FUD -- there is nothing difficult to deploy about this, since
cross-site XHR has never been available before. Not only that, but the
only headers that are blocked by XHR2/AC and are not blocked by regular
XHR today are the Cookie and Cookie2 headers, and that is actually the
subject of outstanding feedback on the same-domain XHR spec rather than
anything particularly specific to cross-domain XHR.


> and [it is] challenging to imagine that there are no other headers in
> use by servers anywhere around the world that might not be good to
> access.

Actually the great thing about the way the AC spec is designed is that we
don't have to imagine this -- we can guarantee it. No headers under author
control are ever sent to a server until the server opts in to this
cross-domain mechanism explicitly.


> Cross-domain access in Flash has had a trail of bugs for these reasons
> [1].  Sunava will detail these security principles; I believe the
> XHR2+AC approach can currently be demonstrated to violate these. Even
> the AC draft itself has a list of security concerns and vague
> requirements as observed and discussed in the group [2].
> [1] http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html
> [2] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0150.html

This is all FUD -- the Flash issue is irrelevant here as we are by design
avoding the policy file problem altogether (so we couldn't even have the
old Flash 9 vulnerabilities if we tried), and the e-mail you cite above is
just an e-mail from your team with vague unspecified security concerns,
not a citation of vague requirements in the spec. (For example, Sunava in
that e-mail suggests that same-site and cross-site XHR having different
behaviour is bad design, despite the fact that the solution you are
advocating doesn't only have different behaviours but has an entirely
different API, and then goes on to incorrect interpret suggestions in the
AC spec as being requirements on XHR2 implementations, possibly
misunderstanding that XHR2 itself clearly specifies all the requiremenets
unambiguously for the cross-domain case and the same-domain case.)


> Even if current vulnerabilities like exposure to Time of Check, Time of
> Use, DNS Rebinding attacks, and URL path canonicalization issues can be
> patched (rather than ignored)

This is again FUD. Your team has been vaguely saying that these threats
exist in the XHR2/AC proposal since last year, and yet nobody from
Microsoft has ever actually shown a clear vulnerability. Reciting a litany
of threat model terms without showing actual attack scenarios is not any
kind of reasonable argument.


> We want to be extremely clear that XDR is most definitely NOT, in our
> opinion, a “slightly different API that solves nearly the same
> problem” – neither is it “different for no extra benefit.” [3]
> [3] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0205.html

It is clearly not radically different. It has almost the same method
names, for instance. It is indeed different for no extra benefit. It is in
fact a subset of the behaviour possible with XHR2.

(It's also worth reiterating the point made in the e-mail you cite above,
namely that XDR has a slew of security problems itself, unlike the XHR2+AC
proposal, despite your implication that XDR is "secure by design" and that
XHR2+AC is "dangerous".)


> Nor is it an “incompatible proposal,” [4] since it’s not intended
> to be merged with XHR or Access Control; it can happily coexist.
> [4] http://lists.w3.org/Archives/Public/public-webapi/2008May/0028.html

It is incompatible because it has slightly different semantics, meaning
that an implementation of one would not trivially be portable to an
implementation of the other. It is also incompatible from an author
mindshare point of view.

(For other parties who haven't realised what's going on here: the idea is
that by introducing new and subtly different APIs in the Web platform, in
the guise of providing "next enabling needs" functionality, authors will
find the Web platform to be more confusing and thus less attractive than,
say, Silverlight. It's an obvious "poison pill" play.)


> As for the XHR2+AC draft itself, I don't believe we intended anything we
> ever said to equate to “XHR2+AC is good;" I challenge the assertion of
> “Microsoft reviews W3C spec as good” [5] as an accurate
> generalization of what has been said [6].
> [5] http://www.w3.org/2008/Talks/0421-ac-tbl/#(4)
> [6] http://lists.w3.org/Archives/Public/public-appformats/2007May/0029.html

"Eric, who is one of our networking experts, and I have reviewed the draft
and we think it looks good" is pretty unambiguous.


> Microsoft has had increasing concerns over the security of the design of
> this proposal.  These concerns come from painfully learned lessons about
> browser security, as we have seen many examples of how violating some
> basic security principles has led to vulnerabilities in the past.

I think it is pretty poor form to imply that Microsoft, who have only just
returned to the browser space, somehow has experience that outweighs the
experience of the three other browser vendors who are involved in the
development of this specification, especially since those vendors have
been active for far longer, and have a far better track record of security
with their browsers.


> Finally, we disagree that the security concerns about XHR2+AC can be
> addressed by mere tweaks to the technical details.

It's hard for us to know whether they could or not since you and your team
has continually failed to actually precisely specify what the security
concerns _are_, despite promising them for six months!


> For example, I pointed out that the flow of this design is inherently
> open to DNS rebinding attacks [9], as well as other issues we’ve
> pointed out.
> [9] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0114.html

This is further FUD. As Jonas pointed out in his reply to your e-mail, the
attack you describe doesn't actually have anything to do with XHR2 [9a],
and as he further describes in a later e-mail, the feature you incorrectly
say is vulnerable is in fact a security feature that is protecting against
attacks that XDR in fact has no protection against at all [9b].

I notice you didn't reply to either of those e-mails.

[9a] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0117.html
[9b] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0118.html


> The responses I’ve seen to the issues we have shared on this list have
> typically been dismissive that there is a problem – or presumptive
> that the problem can simply be spackled over.  When we do go down
> detailed discussions, the threads seem to disappear (e.g. [12]).  
> [12] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/050.html

Assuming you mean 0150, not 050 (which would never have been a valid
thread), that e-mail has two replies, neither of which got a further reply
from Microsoft. Similarly, the thread I cite above ([9a], [9b]) was a
reply to your e-mail, but there was no further reply from Microsoft. If
any threads are disappearing, I respectfully suggest the blame lies with
your team, not anyone else.


> I do want to be clear, since there was some confusion based on a
> conversation between Charles and Michael Champion – we will be
> shipping our XDR implementation in IE8 (modified by any feedback we
> might get before we must lock down for release).  As we’ve said, we'd
> welcome feedback on XDR, and if it is timely enough, it could be
> incorporated into our IE8 product.

It is such blatent disregard for the Web standards process that really
reinforces for us Microsoft's deep commitment to interoperability. Such
ultimatums are also not a very good way of obtaining cooperation from the
wider Web standards community -- if you wonder why you are often faced
with hostility and dismissal, I would suggest this attitude is the cause.


> We desire interoperability; we cannot enable that at the expense of
> security.

Given that XDR has had a number of very serious security vulnerabilities
described on this mailing list, you may wish to reconsider deploying XDR
if security really is a goal. At least the following security problems
have been detailed so far:

 * XDR allows POSTs of arbitrary content to intranet servers, without
   server-side opt-in.

 * XDR will foster an environment in which sites request user
   credentials for third-party sites from users (since it doesn't provide
   a way to do anything else), resulting in an environment where users
   blithely give their passwords to any sites that ask for them, causing
   phishing and fraud to skyrocket (we're already seeing the lack of a
   credential-capable cross-site API do this, e.g. see linkedin.com).

 * XDR forces all content sent in POST entity bodies to be labeled as
   Content-Type: text/plain, regardless of the type, forcing servers to
   ignore the Content-Type header and apply sniffing heuristics to detect
   the actual type of the content sent, potentially leading to privilege
   escalation attacks (e.g. if the user thinks he's uploading a PNG but
   the server sniffs it as an HTML file and sends it back as such).

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Reply | Threaded
Open this post in threaded view
|

RE: IE Team's Proposal for Cross Site Requests

Jon Ferraiolo-2
In reply to this post by Chris Wilson-12

Hi Chris,
Just to be clear, OpenAjax Alliance as an organization has not established a formal position on the debate of XHR2+AC, XDR or other similar cross-domain request proposals. The alliance isn't taking sides one way or the other, although we did hold a discussion at our face-to-face meeting in March involving several individuals with strong expertise in the area of web security, where the majority of those people felt at the time that XDR was preferred from a technical perspective due to security and simplicity concerns.

It sounds like MS will not ship XHR2+AC within IE8 and is planning to go ahead with XDR. IMO, not supporting XHR2 and AC in IE8 is understandable since both only working drafts and clearly MS has a number of important technical concerns, particularly relevant to security.

But for IE9/FF4/Safari4/Opera.NEXT, let's please get together on this issue. I call on a good faith effort by the principal parties in this discussion to meet face-to-face and start work to hammer out a unified proposal that is acceptable to all. My sense is that the principal parties are all trying to do the right thing for the Open Web, and the disagreements are purely technical, which means the fundamental requirements for compromise are present. Therefore, I suggest that sometime soon there be a special meeting (could be a segment of the next F2F) involving the primary contributors to AC along with the primary contributors to XDR, where people meet and agree to work honestly and openly towards a unified proposal. The first step is to get everyone in the room and establish a sense of trust and good faith, which I'm not sure exists yet. In order to bury the hatchets and proceed in an atmosphere of trust, it may be necessary to toss out both AC and XDR (at least temporarily), and establish process groundrules, and then review/update objectives, use cases, and requirements (particularly with security concerns), followed by an honest and open evaluation of existing proposals (XHR2+AC, JSONRequest, XDR, ...) against those UCs and requirements. Whether it is necessary to start from scratch probably can be determined at the first meeting. The ultimate goal should be to achieve the same sort of standards victory as is happening with postMessage(), where an important new bit of functionality is getting into all of the major browsers, but regarding the cross-site request feature, shoot for IE9/FF4/Safari4/Opera.NEXT since it is too late for the 2008 generation of browsers, which I would think means having a stable draft spec for the compromise technology by end of 2008. It might be good to designate two people as "drivers", where one of the two has been involved deeply with AC and the other has been involved deeply with XDR, and for them to submit jointly a compromise proposal (or proposals) that they think will sell to all of the principal parties.

Jon


Inactive hide details for Chris Wilson <Chris.Wilson@microsoft.com>Chris Wilson <[hidden email]>



To

"[hidden email]" <[hidden email]>, "[hidden email]" <[hidden email]>

cc

Eric Lawrence <[hidden email]>, Sunava Dutta <[hidden email]>, Michael Champion <[hidden email]>

Subject

RE: IE Team's Proposal for Cross Site Requests

Indeed, there has been a lot of back and forth on the topics of XDR and XHR2+AC over the last couple of weeks.  This message is not attempting to set forth in detail all the objections we have had; Sunava will deliver that in a concise form. From the comments in various responses in this topic, it is clear that expectations are extremely high for the level of detail in those objections; that takes much time to prepare, and involves a number of people here across multiple teams.  Some of these concerns are direct and technical, and might be fixed in the XHR2+AC draft; however, some of our most important concerns pertain to the approach of enabling cross-domain.

We are interested in participating in standardizing cross-domain access.  We believe quite strongly that cross-domain access is one of the next enabling needs of the web platform, and we are most interested in enabling that in an interoperable way.   However, we feel the design of grafting cross-domain access on to the already-existing XHR system is dangerous, and the current design is being arrived at by the method of discussing what developers want to do, then trying to make it safe, rather than starting with what is secure by principle and incrementally adding functionality.  Experience has taught us it is much easier to ship a system that is secure by design and add functionality than try to secure a implementation after it ships by rolling back features.  For example, today the current XHR draft proposes to block a list of headers that are unsafe only in a cross-domain context; however, this is difficult to deploy since XHR has already shipped, and challenging to imagine that there are no other headers in use by servers anywhere around the world that might not be good to access.

There are fundamental cross domain security principles that we firmly believe need to be guaranteed by a cross domain solution; otherwise, our experience leads us to believe there will be exploits found over time.  Cross-domain access in Flash has had a trail of bugs for these reasons [1].  Sunava will detail these security principles; I believe the XHR2+AC approach can currently be demonstrated to violate these. Even the AC draft itself has a list of security concerns and vague requirements as observed and discussed in the group [2].  Even if current vulnerabilities like exposure to Time of Check, Time of Use, DNS Rebinding attacks, and URL path canonicalization issues can be patched (rather than ignored), we are concerned that this approach to cross-domain access for the browser platform is not based first on security principles.  It is extremely difficult to add security in as a feature after the design is done without creating cracks in that security.  It is also quite difficult to add security on to an already-deployed API without creating large-scale incompatibilities with deployed uses.  For example, is there a blocklist of headers? If so, how will this be maintained as the list of discovered headers grows? Will patching existing implementations in place through an automatic updating mechanism be sufficient to keep customers secure?  In our opinion, one of the fundamental problems with the XHR2+AC proposal is that it blithely reuses an already-existing API for same-domain communication, and then attempts to patch the cracks that appear when it is used to perform cross-domain transfers.

We want to be extremely clear that XDR is most definitely NOT, in our opinion, a “slightly different API that solves nearly the same problem” – neither is it “different for no extra benefit.”   [3]  Nor is it an “incompatible proposal,” [4] since it’s not intended to be merged with XHR or Access Control; it can happily coexist.  XDR is not intended to be a competitor to XHR2+AC; it is different by design, and is focused on a much smaller set of cross-domain access needs.   We believe it a principled and focused design.  It is not, of course, the only principled, focused, or secure design that can be described.

As for the XHR2+AC draft itself, I don't believe we intended anything we ever said to equate to “XHR2+AC is good;" I challenge the assertion of “Microsoft reviews W3C spec as good” [5] as an accurate generalization of what has been said [6].  This message did not claim to reflect a deep technical analysis of its contents of the Access Control draft, but let’s lay aside that concern; it is far more germane that there was no indication that we saw at the time that this access control mechanism would be simply directly applied to the XMLHttpRequest object.  Even according to the designer of Access Control,  the feature was designed for non browser applications, and the idea of enabling AC for the browser platform by applying Access Control to XHR “came as an afterthought.” [7].   As the AC draft has changed over time, and as it was applied to XHR, Microsoft has had increasing concerns over the security of the design of this proposal.  These concerns come from painfully learned lessons about browser security, as we have seen many examples of how violating some basic security principles has led to vulnerabilities in the past.

We’ve given the feedback that we believe this approach to enabling cross-domain is inherently insecure, but unfortunately the working group has not been receptive to these lessons we have learned from our experience.  For example, one response was: “I'm also not sure how you could be surprised by the WGs vote not to replace years worth of work with a completely different and incompatible proposal.  Especially when any security concerns could have been addressed by tweaks to the existing specification.”  [8]  In my opinion, this response is flawed on multiple levels; first, because we had never recommended throwing away all work on XHR2+AC and replacing it with XDR; we’ve suggested that XDR is a focused subset of cross-domain functionality that we believe is securable today.  Certainly, XHR2+AC attempts to enable a lot more functionality; that would assure its place in the future.  Secondly, I would think that issues of security in design would make it obvious that more work is necessary; just because something has been around for a year doesn’t mean it’s right, or that it is the best way of doing something.  Finally, we disagree that the security concerns about XHR2+AC can be addressed by mere tweaks to the technical details.  For example, I pointed out that the flow of this design is inherently open to DNS rebinding attacks [9], as well as other issues we’ve pointed out.  I believe we have several times laid out some of our concerns with the current XHR2+AC method of doing cross-domain; it continues to be claimed that “nobody has responded to the requests for a description of these problems” [10].  I don’t believe that’s appropriate; I think whenever we do describe where we see design flaws and potential exploit area (e.g. [11]), there is a flurry of discussion that results in claims that it’s really not so bad, the exploits can happen in other situations anyway so don’t worry about it; or that such power is needed, and any cross-domain access design that doesn’t enable everything is flawed.

The responses I’ve seen to the issues we have shared on this list have typically been dismissive that there is a problem – or presumptive that the problem can simply be spackled over.  When we do go down detailed discussions, the threads seem to disappear (e.g. [12]).  Alternately, the threads seem to devolve into acrimony, e.g. the back-and-forth over content-typing (where we are told “Stating this doesn’t make it true”). [13]  In short, the discussion has devolved into unsupported sniping [14], including claims that XDR is less secure, that it is “arbitrary,” and that XHR2+AC is technologically superior without any objective measure of such or definition of metrics.

At any rate, focusing on individual technical issues misses the point; spackling security over existing designs to extend them in ways they were not intended is very complex to get right.  We have been calling for simplicity in the underlying design, rather than trying to graft secure cross-domain on to the already-existing APIs; hard experience has led us to be cautious and conservative.  As Jon Ferraiolo of the OpenAjax Alliance said, “security trumps all others [concerns];”  it was gratifying to have his support on the principle of being conservative, and see that some others do recognize that adding incremental complexity to already-existing APIs adds up to “a small beast”. [15]

To address these concerns, we built a simpler, more focused API to enable some set of cross-domain access we felt could be secured, in the most focused way possible.  Unlike Access Control, XDR is modeled off the defacto security policy defined by HTML 4.0 – that is, the prohibition against HTTP methods other than GET and POST and limitations of HTTP headers are in the HTML 4.0 specification and widely used as Tyler Close from HP pointed out to the Web API mailing list.  [16]  Indeed, the Open Ajax Alliance claims that XDR promises to be simpler and more secure [17].

I do want to be clear, since there was some confusion based on a conversation between Charles and Michael Champion – we will be shipping our XDR implementation in IE8 (modified by any feedback we might get before we must lock down for release).  As we’ve said, we'd welcome feedback on XDR [18], and if it is timely enough, it could be incorporated into our IE8 product.   We would of course be happy if this minimal, secure subset were to be accepted as a submission by the WG, turned into a deliverable and improved by an open standards process – and if that were the case, I believe it would be our responsibility to modify our implementation to comply with the (eventual) standard.  However, we recognize that the Web API WG has voted informally to not pursue the XDR submission; in our view that makes it more imperative that the WebAPI’s design be made really secure if it is to be a W3C Recommendation and the only way to interoperably enable access across domains; but this does not change the customer need for us to ship a secure subset of cross-domain capabilities in this release of IE.

We will of course continue to participate in the Web API WG’s work on cross-domain access, and I hope that work can be made secure to our satisfaction (and therefore implementable in IE); but we simply cannot implement APIs that we believe expose customers to security exploits.  We desire interoperability; we cannot enable that at the expense of security.

-Chris

[1]
http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html
[2]
http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0150.html
[3]
http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0205.html
[4]
http://lists.w3.org/Archives/Public/public-webapi/2008May/0028.html
[5]
http://www.w3.org/2008/Talks/0421-ac-tbl/#(4)
[6]
http://lists.w3.org/Archives/Public/public-appformats/2007May/0029.html
[7]
http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0154.html
[8]
http://lists.w3.org/Archives/Public/public-webapi/2008May/0028.html
[9]
http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0114.html
[10]
http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0209.html
[11]
http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0114.html
[12]
http://lists.w3.org/Archives/Public/public-webapi/2008Mar/050.html
[13]
http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0211.html
[14]
http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0206.html
[15]
http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0099.html
[16]
http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0095.html
[17]
http://www.regdeveloper.co.uk/2008/03/28/openajax_alliance_internet_explorer_eight/
[18]
http://lists.w3.org/Archives/Public/public-appformats/2008Mar/0017.html


-----Original Message-----
From: Charles McCathieNevile [[hidden email]]
Sent: Monday, May 05, 2008 7:30 AM
To: Sunava Dutta
Cc: Chris Wilson; Web API WG (public); [hidden email]; Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
Subject: Re: IE Team's Proposal for Cross Site Requests

There has been rather more to-ing and fro-ing than actual work, it seems.

I am happy to schedule a teleconference, and to ensure that Anne is
available (as editor of XHR I think he is a critical resource). But we
need to establish an agenda. (I am also trying to organise a face to face
meeting to ensure that we can work as rapidly as possible - people are
implementing stuff now and I would hate things to slow down to the point
where people effectively opt out of the standards process and just ship
something different).

Before trying to schedule a teleconference, we need an agenda. As Maciej
and others have noted, these are potentially complicated issues and we
need to have reading time before the meeting in order to avoid wasting
valuable teleconference time.

The results of the survey on simply sopting IE's approach were pretty
conclusive. The reasons given seem pretty clear, such as a desire not to
fork requests in the first place, a belief that moving security risk from
the implementation of requests to each specific use of a request actually
increases the risk for end-users.

Microsoft apparently feels that there are reasons to implement something
other than the standard approach being developed, since they did so and I
presume it was not from bloody-mindedness or ignorance. In order to
usefully address these issues we need to understand them. Which means we
are waiting on Microsoft to provide written feedback.

Given the months that elapsed between the last time feedback was promised
and when it was delivereed, I am reluctant to schedule teleconferences
before such feedback is provided, at least sufficient to justify holding a
teleconference.

cheers

Chaals (as chair, webapi woring group)

On Sat, 03 May 2008 00:51:27 +0100, Sunava Dutta
<[hidden email]> wrote:

> Maciej wrote:
> " I would also prefer to see a clear statement of Microsoft's position
> in written form ahead of the telecon. By their nature, these are
> issues that need careful analysis, and cannot be evaluated fully in
> the context of a teleconference."
>
> I think the request will help discussion. Yes, we will be making our
> position and points that need further deliberation available in a
> written form prior to the teleconference.
>
> -----Original Message-----
> From: Maciej Stachowiak [[hidden email]]
> Sent: Tuesday, April 29, 2008 5:01 PM
> To: Ian Hickson
> Cc: Chris Wilson; Anne van Kesteren; Sunava Dutta; Web API WG (public);
> [hidden email]; Eric Lawrence; Zhenbin Xu; Gideon Cohn;
> Sharath Udupa; Doug Stamper; Marc Silbey
> Subject: Re: IE Team's Proposal for Cross Site Requests
>
>
> On Apr 29, 2008, at 2:14 PM, Ian Hickson wrote:
>
>>
>> On Tue, 29 Apr 2008, Chris Wilson wrote:
>>>
>>> Given the multitude of issues raised, and the obvious back-and-forth
>>> that denotes many differing opinions, I'd suggest having a telecom to
>>> discuss these questions, and make sure that Sunava, Eric and myself
>>> can
>>> attend.
>>
>> I'm with Anne on this. Please reply to the e-mails before convening a
>> telecon. It is very difficult to carefully consider feedback in the
>> context of a telecon.
>>
>> The problem isn't "back-and-forth" denoting "many differing
>> opinions", the
>> problem is that we don't know what Microsoft's opinion _is_.
>>
>> Telecons are by their nature much less open, and minutes are almost
>> uniformly so poor that it is hard to impossible to get precise
>> technical
>> details out of telecons. A telecon would not be appropriate at this
>> point.
>
> I would also prefer to see a clear statement of Microsoft's position
> in written form ahead of the telecon. By their nature, these are
> issues that need careful analysis, and cannot be evaluated fully in
> the context of a teleconference.
>
> Regards,
> Maciej
>
>
>



--
Charles McCathieNevile  Opera Software, Standards Group
    je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com


pic09515.gif (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Charles McCathieNevile-2

On Mon, 12 May 2008 18:43:51 +0200, Jon Ferraiolo <[hidden email]>  
wrote:

> Hi Chris,
> Just to be clear, OpenAjax Alliance as an organization has not  
> established a formal position on the debate of XHR2+AC, XDR or other
> similar cross-domain request proposals.
...
> But for IE9/FF4/Safari4/Opera.NEXT, let's please get together on this
> issue. I call on a good faith effort by the principal parties in this
> discussion to meet face-to-face and start work to hammer out a unified
> proposal that is acceptable to all.

This is in fact one of two items for the next face to face. The other,  
hopefully secondary, is cleaning up any outstanding issues in XHR1 (since  
XHR2 depends on that in any case, and since there are several  
critical-path folks who are the same person).

Of course, the meeting relies on timely input. We are waiting on Microsoft  
to raise specific issues so we can analyse them and put them on the  
agenda. I am hopeful that having scheduled a face to face meeting a couple  
of months away isn't taken as a reason not to continue the more aggressive  
process that would have been required to justify holding telecons, as  
Microsoft originally requested - there is certainly no barrier to holding  
telconferences before the meeting.

cheers

Chaals

--
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Reply | Threaded
Open this post in threaded view
|

RE: IE Team's Proposal for Cross Site Requests

Chris Wilson-12
In reply to this post by Ian Hickson
Ian, in your response you claim four separate times that my statements are "FUD".  (I presume you mean http://en.wikipedia.org/wiki/Fear%2C_uncertainty_and_doubt.)  I'll address those individually below, but your invective seems to confuse "Chris has different opinions/beliefs than me" with "Chris is distorting truth to try to game the system," or perhaps that's just the way you would like to paint me.

You claimed my message contained an "ultimatum" - defined by Webster's Revised Unabridged Dictionary as "A final proposition, concession, or condition; especially, the final propositions, conditions, or terms, offered by either of the parties in a diplomatic negotiation; the most favorable terms a negotiator can offer, the rejection of which usually puts an end to the hesitation."  (Webster's Revised Unabridged Dictionary, © 1996, 1998 MICRA, Inc.)

You are quite clearly incorrect in applying that word, as I stated no proposition, demanded no concession; and at any rate clearly stated that we plan to continue to participate in the cross-domain effort currently active in the WG regardless of the decisions made, in the hopes that Access Control + XHR can be improved; in fact, I stated no terms nor hesitation.  That time is clearly past.  I was correcting a misunderstanding.

You accuse us of blatant disregard for Web standards process, presumably if we ship XDR in IE.  I disagree.  We are ALLOWED, in fact, to disagree; in fact, if we believe a developing standard is a bad idea, we SHOULD speak up.  We are also NOT, in fact, required to have every feature we ship be based on an approved standard (or do I need to write out the list of features that are not in approved standards, but are in shipping versions of other browsers?  Isn't think how innovations like <canvas> happen?).  I do believe we must have good reasons to choose to go down a different path than a current standards effort - in this case, we believe we have quite good reason.

You appear to be unable to be objective about this matter, and would rather be indignant and self-righteous at our missteps than accept that perhaps, every once in a while, those complete dunces at Microsoft might just possibly have a point.  It's somewhat amusing to see how you react to proposals (even radical ones in conflict with current status quo) from people OTHER than Microsoft, e.g. Google's Blob proposal that overlaps with Opera and Mozilla work in the same area (http://lists.w3.org/Archives/Public/public-webapi/2008May/0106.html).

In your invective, you also (for the benefit of "other parties" not as clued in, apparently, as yourself) liken "what's going on here" to a poison pill, which I fail to understand.  http://en.wikipedia.org/wiki/Poison_pill would seem to suggest that you think Microsoft is taking some action that harms both us and the standards effort; however, I would point out 1) XDR doesn't harm Microsoft. 2) I just stated that we will continue working on the Web API group's proposal, in the hopes that it can become implementable for us in the future.

I want to be clear that the following paragraph is a personal statement by me, and should not be representing in any way to reflect the opinions, values or plans of Microsoft, nor should it reflect on them in any way.

I believe you just accused me personally of "poison pill" tactics to further the interests of Silverlight.  I will be offended by your accusation of moral bankruptcy once I stop laughing at the idea that I personally would do such a thing, given my personal feelings on Silverlight.  At any rate, please don't claim to be "explaining the situation" to anyone else when you have it so completely wrong, and don't impugn my moral character unless you really intend to do so.

Back to being a Microsoft employee: to address your individual statements:

>Sunava said last November that
>this feedback would be sent as soon as possible. As far as I know, nobody
>else spent six months writing up their feedback.

And we are to blame for that delay, yes.  However, despite your claims that we have not shared our concerns, I believe we have been sharing them, just at a higher level than you apparently want.

>> For example, today the current XHR draft proposes to block a list of
>> headers that are unsafe only in a cross-domain context; however, this is
>> difficult to deploy since XHR has already shipped
>
>This is FUD -- there is nothing difficult to deploy about this, since
>cross-site XHR has never been available before.

You seem to equate "deploying" with "writing code," rather than any kind of understanding of the effects that deploying that code into markets that already use your software might have.  Shipping releases of IE to half a billion customers tends to give us that understanding in spades.

>> and [it is] challenging to imagine that there are no other headers in
>> use by servers anywhere around the world that might not be good to
>> access.
>
>Actually the great thing about the way the AC spec is designed is that we
>don't have to imagine this -- we can guarantee it. No headers under author
>control are ever sent to a server until the server opts in to this
>cross-domain mechanism explicitly.

You are presuming that all server implementations will understand the implications of this fully before they turn on cross-domain.

>This is all FUD -- the Flash issue is irrelevant here as we are by design
>avoding the policy file problem altogether (so we couldn't even have the
>old Flash 9 vulnerabilities if we tried),

I would point to the "DNS hardening" section of that post, and say yes you do have issues here.  It's not "the policy file issue," presuming you're referring to the policy file control issue, but the AC design does in fact have some other problems here.

>and the e-mail you cite above is
>just an e-mail from your team with vague unspecified security concerns,
>not a citation of vague requirements in the spec. (For example, Sunava in
>that e-mail suggests that same-site and cross-site XHR having different
>behaviour is bad design,

You seem to be missing the point, though I think Sunava actually said it fairly clearly in that post.  The problem is that XHR is one object; it works different vis-à-vis security depending on whether it's being used in a cross-domain or same-domain way.  That kind of switch has shown to be bad secure coding practice to us before, so we avoid designs with that potential vulnerable spot whenever possible.

>> Even if current vulnerabilities like exposure to Time of Check, Time of
>> Use, DNS Rebinding attacks, and URL path canonicalization issues can be
>> patched (rather than ignored)
>
>This is again FUD. Your team has been vaguely saying that these threats
>exist in the XHR2/AC proposal since last year, and yet nobody from
>Microsoft has ever actually shown a clear vulnerability. Reciting a litany
>of threat model terms without showing actual attack scenarios is not any
>kind of reasonable argument.

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]?  Have you threat-modelled the intersection of AC and XHR2?  Are you aware that waiting until there's a clear code exploit is a bad time to start planning for a secure design?

>It is indeed different for no extra benefit.

I understand that you think there is no extra benefit.

>It is in fact a subset of the behaviour possible with XHR2.

That *IS* a benefit, when the superset includes potential security attack surface area, and even the smaller set is done in a way that has additional threats.

>(It's also worth reiterating the point made in the e-mail you cite above,
>namely that XDR has a slew of security problems itself, unlike the XHR2+AC
>proposal, despite your implication that XDR is "secure by design" and that
>XHR2+AC is "dangerous".)

I'm not getting into your mud-slinging campaign.

>> Microsoft has had increasing concerns over the security of the design of
>> this proposal.  These concerns come from painfully learned lessons about
>> browser security, as we have seen many examples of how violating some
>> basic security principles has led to vulnerabilities in the past.
>
>I think it is pretty poor form to imply that Microsoft, who have only just
>returned to the browser space, somehow has experience that outweighs the
>experience of the three other browser vendors who are involved in the
>development of this specification, especially since those vendors have
>been active for far longer, and have a far better track record of security
>with their browsers.

Well, then there we disagree.  We have been shipping IE to more customers than all the other browsers put together for over a decade now.  We have had exponentially more security researchers focused on us than anyone else, because they follow the money, and the money goes with the user market.  We have spent tremendous amounts of effort and money restructuring our entire way of writing software in order to respond to these new aspects of our business.  You seem to think these experiences count for nothing, and we are a bunch of ignorant inexperienced wonks, rather than assuming that perhaps we've learned a few lessons given our unique experiences.

>> Finally, we disagree that the security concerns about XHR2+AC can be
>> addressed by mere tweaks to the technical details.
>
>It's hard for us to know whether they could or not since you and your team
>has continually failed to actually precisely specify what the security
>concerns _are_, despite promising them for six months!

Let's start with where I took this:

>> For example, I pointed out that the flow of this design is inherently
>> open to DNS rebinding attacks [9], as well as other issues we’ve
>> pointed out.
>> [9] http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0114.html
>
>This is further FUD. As Jonas pointed out in his reply to your e-mail, the
>attack you describe doesn't actually have anything to do with XHR2 [9a],

No, I think Jonas misunderstood how one would use DNS rebinding to create an attack.  In short, relying on cached credentials with no guarantee you're not talking to a different server is a bad idea.  XHR2+AC does this; XDR does not.  Is this unclear?

>Assuming you mean 0150, not 050 (which would never have been a valid

Yes, sorry, c&p error.

>thread), that e-mail has two replies, neither of which got a further reply
>from Microsoft.

Neither of which addressed the main issues from that post.  I would have expected either "oh yeah, that issue's on the list here: [blah]" or "that's not actually an issue, and here's why."

>Given that XDR has had a number of very serious security vulnerabilities
>described on this mailing list, you may wish to reconsider deploying XDR
>if security really is a goal. At least the following security problems
>have been detailed so far:

Sunava will address these issues.

-Chris

[1] http://www.amazon.com/Writing-Secure-Second-Michael-Howard/dp/0735617228/ref=pd_bbs_sr_3?ie=UTF8&s=books&qid=1210787965&sr=8-3

Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Bjoern Hoehrmann

* 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:[hidden email] · 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/ 

Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Arun Ranganathan-2
In reply to this post by Sunava Dutta

Chris,

Thanks for the email. A few points below:

 >This message is not attempting to set forth in detail all the
objections we have had; Sunava will >deliver that in a concise form.

Can you give us a ballpark ETA on this?

 >For example, today the current XHR draft proposes to block a list of
headers that are unsafe >only in a cross-domain context; however, this
is difficult to deploy since XHR has already >shipped, and challenging
to imagine that there are no other headers in use by servers anywhere
 >around the world that might not be good to access.

Microsoft feedback on proposals such as

http://lists.w3.org/Archives/Public/public-appformats/2008May/0034.html

are welcome. Also, I'm not averse to discussing a restricted list of
headers that the XHR API *should* support rather than a block list.

 >There are fundamental cross domain security principles that we firmly
believe need to be >guaranteed by a cross domain solution; otherwise,
our experience leads us to believe there will >be exploits found over
time. Cross-domain access in Flash has had a trail of bugs for these
 >reasons [1]. Sunava will detail these security principles;

*In particular* what is the direct parallel you are drawing between the
Flash approach and the XHR2+AC approach? Sunava's commentary eagerly
awaited. In this message

http://lists.w3.org/Archives/Public/public-webapi/2008May/0196.html

you suggest we look at "DNS Hardening" for "clues." Can you be a bit
more specific here, if possible?

 >Even if current vulnerabilities like exposure to Time of Check, Time
of Use, >DNS Rebinding >attacks, and URL path canonicalization issues
can be patched (rather than >ignored),

I think we ought to make spec. language and related docs. good for
server-side deployment of the Access-Control scheme as well, and
encourage good Web architecture. DNS Rebinding is a generally powerful
attack that creates a fair number of vulnerabilities outside the scope
of XHR+AC, and we should encourage servers to respect origin headers
and/or use TLS, but I'm still trying to figure out your notions of a
demonstrable vulnerability that is specific to our approach within XHR2+AC.

Regarding URL Canonicalization, a proposal to address URL
canonicalization problems by disabling Access-Control-Policy-Path:

http://lists.w3.org/Archives/Public/public-appformats/2008May/0037.html

has been put on the table.

 > For example, is there a blocklist of headers? If so, how will this be
maintained as the list of >discovered headers grows?

Again, feedback on an "acceptable headers to exchange" component of AC
is welcome. Also again: I'm not averse to discussion of using a
restricted list of headers in lieu of blocked ones, if you think that
will help.

 >XDR is not intended to be a competitor >to XHR2+AC; it is different by
design, and is >focused on a much smaller set of cross-domain >access
needs.

<snip />

 >I do want to be clear, since there was some confusion based on a
conversation between Charles >and Michael Champion – we will be shipping
our XDR implementation in IE8 (modified by >any fsafeedback we might get
before we must lock down for release). As we’ve said, we'd >welcome
feedback on XDR [18], and if it is timely enough, it could be
incorporated into our >IE8 product.

All things being equal, it is likely that XDR and XHR2+AC will co-exist,
and the major JS libraries can probably straddle the difference. Of
course, I'd prefer it if we had a single API that addressed the more
robust needs of web applications, including Cookies, etc. :)

But IE8 beta does support postMessage, just as other UAs do. And it
would seem that postMessage will be used for cross-site requests because
of the widespread support across UAs, modulo caller/callee understanding
across sites (e.g. there's likely to be a propagation of iframe-based
APIs which can be requested with Cookies, Auth, etc. and on which other
sites will call .postMessage). This would have well-known limitations.
Coming to the table and commenting on proposals will create better
solutions for developers.


 >We will of course continue to participate in the Web API WG’s work on
cross-domain access, >and I hope that work can be made secure to our
satisfaction (and therefore implementable in >IE); but we simply cannot
implement APIs that we believe expose customers to security >exploits.
We desire interoperability; we cannot enable that at the expense of
security.

We desire this also. Specifics help illustrate points best.

-- A*


Reply | Threaded
Open this post in threaded view
|

RE: IE Team's Proposal for Cross Site Requests

Sunava Dutta


> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of Arun Ranganathan
> Sent: Wednesday, May 14, 2008 7:01 PM
> To: [hidden email]; [hidden email]
> Subject: Re: IE Team's Proposal for Cross Site Requests
>
>
> Chris,
>
> Thanks for the email. A few points below:
>
>  >This message is not attempting to set forth in detail all the
> objections we have had; Sunava will >deliver that in a concise form.
>
> Can you give us a ballpark ETA on this?

[Sunava Dutta] Sure, I'm compiling this as we speak. I expect this to be ready and available to the Web API by mid June in the latest. (Sorry for the time, my resources are spread thin over several AJAX features) I don't think there should be any surprises here as we have communicated our concerns before. However, there does seem to be the scope to provide specific concerns which we will do where we can or elaborate on a few, as well as our security principles for a good cross domain solution and where AC fails or meets them. This does not change what Chris said though. Just because there are not existing threats (although the URL canonicalization issue as Eric Lawrence discovered is currently open?) does not mean that AC is safe. We can present threats and they can be patched. That's just not something we recommend. A good threat modeled solution I'm sure many of us will agree is secure by design. That's our overarching point we've been trying to get across.

>
>  >For example, today the current XHR draft proposes to block a list of
> headers that are unsafe >only in a cross-domain context; however, this
> is difficult to deploy since XHR has already >shipped, and challenging
> to imagine that there are no other headers in use by servers anywhere
>  >around the world that might not be good to access.
>
> Microsoft feedback on proposals such as
>
> http://lists.w3.org/Archives/Public/public-appformats/2008May/0034.html
>
> are welcome. Also, I'm not averse to discussing a restricted list of
> headers that the XHR API *should* support rather than a block list.

[Sunava Dutta] You're missing the point. I'm agnostic to a block or allow list. What I've been asking for in case it's not been clear is the rationale as to why these are blocked in the spec. There are threads going on regarding this. My point is that blocking headers on shipped implementations is hard, since it's difficult for us to patch legacy versions. The current XHR spec should not be an academic exercise and should rightfully model existing UA's. That said doing the right thing for security is important, but we need to have good justifications. Currently that is absent in the case of the blocked headers.

>
>  >There are fundamental cross domain security principles that we firmly
> believe need to be >guaranteed by a cross domain solution; otherwise,
> our experience leads us to believe there will >be exploits found over
> time. Cross-domain access in Flash has had a trail of bugs for these
>  >reasons [1]. Sunava will detail these security principles;
>
> *In particular* what is the direct parallel you are drawing between the
> Flash approach and the XHR2+AC approach? Sunava's commentary eagerly
> awaited. In this message
>
[Sunava Dutta] Wildcarding was a problem in Flash (one of many?). I'm not sure if AC is vulnerable to that but it certainly seems possible? The point here is that a number of developers won't ready the security notes on the docs and inadvertently expose their services. Solutions should be coded for the lowest common denominator. That's hard to understand given that most Web API participants are quite technical.
http://jeremiahgrossman.blogspot.com/2006/10/crossdomainxml-statistics.html

> http://lists.w3.org/Archives/Public/public-webapi/2008May/0196.html
>
> you suggest we look at "DNS Hardening" for "clues." Can you be a bit
> more specific here, if possible?
>
[Sunava Dutta] The write-up I'm compiling will investigate the DNS rebinding issue in more detail. I think that's fair. If DS rebinding is raised as a concern, we should be able to give a specific threat or in the minimum a potential mechanism. I'm not a security guru here and I expect my security team can give me a proper assessment of the risk of AC here, although it seems with the two step request here and the requirement of sites to validate the host header, TOCTOU and DNS rebinding risks are high.

>  >Even if current vulnerabilities like exposure to Time of Check, Time
> of Use, >DNS Rebinding >attacks, and URL path canonicalization issues
> can be patched (rather than >ignored),
>
> I think we ought to make spec. language and related docs. good for
> server-side deployment of the Access-Control scheme as well, and
> encourage good Web architecture. DNS Rebinding is a generally powerful
> attack that creates a fair number of vulnerabilities outside the scope
> of XHR+AC, and we should encourage servers to respect origin headers
> and/or use TLS, but I'm still trying to figure out your notions of a
> demonstrable vulnerability that is specific to our approach within
> XHR2+AC.

[Sunava Dutta] Fair enough. As mentioned, the IE sec team will try to detail the exact risk if any (for DNS Rebinding) or give a risk assessment here by June 15th.

>
> Regarding URL Canonicalization, a proposal to address URL
> canonicalization problems by disabling Access-Control-Policy-Path:
>
> http://lists.w3.org/Archives/Public/public-appformats/2008May/0037.html
>
> has been put on the table.
>
>  > For example, is there a blocklist of headers? If so, how will this be
> maintained as the list of >discovered headers grows?
>
> Again, feedback on an "acceptable headers to exchange" component of AC
> is welcome. Also again: I'm not averse to discussion of using a
> restricted list of headers in lieu of blocked ones, if you think that
> will help.

[Sunava Dutta] Both having a restricted list or an allow list is challenging. My point is, block allowing script to send http headers cross domain. A restricted list needs to grow with time as more are discovered. Browsers need to deploy patches to service existing versions.
An allow list that can send headers cross domain CANNOT guarantee that services today may not expect this come from XHR and consequently assume it's same origin.
If one takes into account 'new cross domain behaviors' are potentially scary by themselves, it gets even worse when one models the intersection of them. (For example, have the AC proposers modeled the affects of looking at sending cross domain headers, credentials etc holistically?)

>
>  >XDR is not intended to be a competitor >to XHR2+AC; it is different by
> design, and is >focused on a much smaller set of cross-domain >access
> needs.
>
> <snip />
>
>  >I do want to be clear, since there was some confusion based on a
> conversation between Charles >and Michael Champion - we will be shipping
> our XDR implementation in IE8 (modified by >any fsafeedback we might get
> before we must lock down for release). As we've said, we'd >welcome
> feedback on XDR [18], and if it is timely enough, it could be
> incorporated into our >IE8 product.
>
> All things being equal, it is likely that XDR and XHR2+AC will co-exist,
> and the major JS libraries can probably straddle the difference. Of
> course, I'd prefer it if we had a single API that addressed the more
> robust needs of web applications, including Cookies, etc. :)
>
[Sunava Dutta] If we can agree on the security principles (hopefully the F2F) hopefully a safe way to do AC can be developed. These are certainly scenarios that this feature is useful for that's why we're proposed XDR alongside. Although we invented XHR here we've been concerned about using it cross domain as mentioned before. I think the uber point with CS-XHR is the behavior is different in the two modes (same site and cross domain). That's confusing enough.

> But IE8 beta does support postMessage, just as other UAs do. And it
> would seem that postMessage will be used for cross-site requests because
> of the widespread support across UAs, modulo caller/callee understanding
> across sites (e.g. there's likely to be a propagation of iframe-based
> APIs which can be requested with Cookies, Auth, etc. and on which other
> sites will call .postMessage). This would have well-known limitations.
> Coming to the table and commenting on proposals will create better
> solutions for developers.
>
[Sunava Dutta] Agreed.

>
>  >We will of course continue to participate in the Web API WG's work on
> cross-domain access, >and I hope that work can be made secure to our
> satisfaction (and therefore implementable in >IE); but we simply cannot
> implement APIs that we believe expose customers to security >exploits.
> We desire interoperability; we cannot enable that at the expense of
> security.
>
> We desire this also. Specifics help illustrate points best.
>
[Sunava Dutta] Again, specifics will be provided however I reiterate, don't expect a stream of specifics to ensure that solution is ready to ship. Taking a few steps back and looking at what's possible today and what a secure cross domain solution should guarantee is more important. (A long long time ago, the IE team thought that having no active threats for the product covered us from the security front for shipping. That was not a good strategy -:))

> -- A*
>
>


Reply | Threaded
Open this post in threaded view
|

Moving forward with XHR2 and AC

Ian Hickson

On Thu, 15 May 2008, Sunava Dutta wrote:
>
> I expect this to be ready and available to the Web API by mid June in
> the latest.

Cool.

Anne, can you summarise what needs doing to XHR2 and AC to move them
forwards to last call? Is there a list of outstanding comments anywhere?

If there's anything I can do to help I'd be happy to do so. I would like
to see this draft reach last call this month if possible.

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

Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Jonas Sicking-2
In reply to this post by Sunava Dutta

Sunava Dutta wrote:
>>  >This message is not attempting to set forth in detail all the
>> objections we have had; Sunava will >deliver that in a concise form.
>>
>> Can you give us a ballpark ETA on this?
>
 > [Sunava Dutta] Sure, I'm compiling this as we speak. I expect this to
 > be ready and available to the Web API by mid June in the latest.

Wow, this is really bad news that we won't get this feedback until just
two weeks before the face to face meeting. Especially given the numerous
delays in getting this feedback in the past I am very worried that there
will be further delays. Are you absolutely certain that won't happen again?

Even just having two weeks in order to discuss this feedback prior to
the meeting seems like very short on time.

I would really encourage you to consider providing this feedback more
promptly. I do not wish to attend a face to face meeting solely to
discuss new feedback which we have not had the opportunity to research
and cannot usefully discuss. I also hope to cover much more than
microsofts feedback during the meeting.

 > I don't think there should be any surprises here as we have
 > communicated our concerns before.

I most certainly do expect there to be plenty of surprises here. I and
many others have had a very difficult time understanding the concerns
that microsoft has had so I hope that most of what you will be providing
will be new information.

> [Sunava Dutta] Wildcarding was a problem in Flash (one of many?). I'm not sure if AC is vulnerable to that but it certainly seems possible? The point here is that a number of developers won't ready the security notes on the docs and inadvertently expose their services. Solutions should be coded for the lowest common denominator. That's hard to understand given that most Web API participants are quite technical.
> http://jeremiahgrossman.blogspot.com/2006/10/crossdomainxml-statistics.html

Please note that that article does not point out a single site that is
in fact vulnerable. It does seem to say that 1 site out of fortune 500
and 2 out of the alexa top 100 sites has a wildcarded crossdomain.xml
policy. It does not say if any of those sites actually host sensitive
information.

However I do agree that crossdomain.xml is a very interesting case
study. We should make sure to study that and learn from any mistakes
made there.

> [Sunava Dutta] If we can agree on the security principles (hopefully
> the F2F) hopefully a safe way to do AC can be developed.

First off, i certainly hope that we will be discussing the security
principles before the F2F. I am very glad to see that microsoft recently
have become active on this mailing list and hope that that will not stop.

The more we can discuss the issues before the F2F the more productive we
can be at the meeting.

> These are
> certainly scenarios that this feature is useful for that's why we're
> proposed XDR alongside. Although we invented XHR here we've been
> concerned about using it cross domain as mentioned before. I think the
> uber point with CS-XHR is the behavior is different in the two modes
> (same site and cross domain). That's confusing enough.

While this is certainly an interesting discussion to have, I'm not sure
I see the security implications between using an old API with new
restrictions vs. creating a new API.

This rather simply seems like a DOM API issue rather than a security
model issue.

>> We desire this also. Specifics help illustrate points best.
>>
> [Sunava Dutta] Again, specifics will be provided however I reiterate, don't expect a stream of specifics to ensure that solution is ready to ship.

I'm not sure I follow what you are saying here. Is your email on June
15th not going to include enough specifics to be able to discuss needed
changes to the spec? That would seem very very unfortunate.

/ Jonas

Reply | Threaded
Open this post in threaded view
|

Re: Moving forward with XHR2 and AC

Anne van Kesteren-2
In reply to this post by Ian Hickson

On Fri, 16 May 2008 02:07:57 +0200, Ian Hickson <[hidden email]> wrote:
> Anne, can you summarise what needs doing to XHR2 and AC to move them
> forwards to last call? Is there a list of outstanding comments anywhere?

XMLHttpRequest Level 2

* Depends on XMLHttpRequest Level 1 feedback:  
http://dev.w3.org/2006/webapi/XMLHttpRequest/disposition-of-comments-2
* It needs an introduction at some point. (Though not per se for Last Call  
I suppose.)


Access Control for Cross-Site Requests

* Need to deal with Access-Control-Policy-Path normalization
* Need to figure out if we want the server to whitelist headers/methods  
(we had methods before and then dropped it)
* Need to figure out if we want the server to opt in to cookies/credentials


> If there's anything I can do to help I'd be happy to do so. I would like
> to see this draft reach last call this month if possible.

If you have any ideas on how to solve the non-obvious bits of the above  
that would help.

Personally:

* Discouraging the use of Access-Control-Policy-Path other than with a  
value of / for IIS works for me.

* Adding the Access-Control-Headers and Access-Control-Methods  
conditionals is fine with me.

* I don't think we need to add opt in for cookies/credentials given that  
for GET such requests are already possible and for non-GET there's an  
OPTIONS opt-in request.


--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Reply | Threaded
Open this post in threaded view
|

Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

Arthur Barstow
In reply to this post by Jonas Sicking-2

Sunava - I tend to agree with Jonas re the timing of MS' response/
feedback.

Given the f2f meeting is now about six weeks away, can you commit to  
and deliver on an earlier deadline, no later than June 6?

-Regards, Art Barstow


On May 15, 2008, at 10:39 PM, ext Jonas Sicking wrote:

>
> Sunava Dutta wrote:
>>>  >This message is not attempting to set forth in detail all the
>>> objections we have had; Sunava will >deliver that in a concise form.
>>>
>>> Can you give us a ballpark ETA on this?
> > [Sunava Dutta] Sure, I'm compiling this as we speak. I expect  
> this to
> > be ready and available to the Web API by mid June in the latest.
>
> Wow, this is really bad news that we won't get this feedback until  
> just two weeks before the face to face meeting. Especially given  
> the numerous delays in getting this feedback in the past I am very  
> worried that there will be further delays. Are you absolutely  
> certain that won't happen again?
>
> Even just having two weeks in order to discuss this feedback prior  
> to the meeting seems like very short on time.
>
> I would really encourage you to consider providing this feedback  
> more promptly. I do not wish to attend a face to face meeting  
> solely to discuss new feedback which we have not had the  
> opportunity to research and cannot usefully discuss. I also hope to  
> cover much more than microsofts feedback during the meeting.


Reply | Threaded
Open this post in threaded view
|

RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

Sunava Dutta

Sure. I've talked to my team and June 6 is OK.

> -----Original Message-----
> From: Arthur Barstow [mailto:[hidden email]]
> Sent: Friday, May 16, 2008 5:06 AM
> To: ext Jonas Sicking; Sunava Dutta
> Cc: [hidden email]; [hidden email] WG (public); public-
> [hidden email]; IE8 Core AJAX SWAT Team; Eric Lawrence; Chris Wilson;
> David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> Subject: Seeking earlier feedback from MS [Was: IE Team's Proposal for
> Cross Site Requests]
>
> Sunava - I tend to agree with Jonas re the timing of MS' response/
> feedback.
>
> Given the f2f meeting is now about six weeks away, can you commit to
> and deliver on an earlier deadline, no later than June 6?
>
> -Regards, Art Barstow
>
>
> On May 15, 2008, at 10:39 PM, ext Jonas Sicking wrote:
>
> >
> > Sunava Dutta wrote:
> >>>  >This message is not attempting to set forth in detail all the
> >>> objections we have had; Sunava will >deliver that in a concise form.
> >>>
> >>> Can you give us a ballpark ETA on this?
> > > [Sunava Dutta] Sure, I'm compiling this as we speak. I expect
> > this to
> > > be ready and available to the Web API by mid June in the latest.
> >
> > Wow, this is really bad news that we won't get this feedback until
> > just two weeks before the face to face meeting. Especially given
> > the numerous delays in getting this feedback in the past I am very
> > worried that there will be further delays. Are you absolutely
> > certain that won't happen again?
> >
> > Even just having two weeks in order to discuss this feedback prior
> > to the meeting seems like very short on time.
> >
> > I would really encourage you to consider providing this feedback
> > more promptly. I do not wish to attend a face to face meeting
> > solely to discuss new feedback which we have not had the
> > opportunity to research and cannot usefully discuss. I also hope to
> > cover much more than microsofts feedback during the meeting.


1234567