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: IE Team's Proposal for Cross Site Requests

Jonas Sicking-2

Laurens Holst wrote:

> Laurens Holst schreef:
>> Or, if you really do not want to increase the attack surface, you
>> should always send the content type application/x-www-form-urlencoded,
>> and only allow request entities constructed through an API. Because
>> servers only expect x-www-form-urlencoded and not text/plain, and
>> servers might have parsing issues if the POST body is malformed, both
>> leading to changes from what is currently possible with HTML and thus,
>> security risks.
>
> Sorry, apparantly this is a misconception of mine, using
> encoding="text/plain" you can apparantly already send arbitrary
> requests. So ignore this paragraph please :). The rest does still apply.
>
> By the way, I do not see how requiring servers to ignore the request
> entity content type and forcing them to do content sniffing makes things
> more secure, instead of less.

Though to be honest I would really like to figure out a way to disable
cross-site POSTs even from forms. CSRF is a big problem with tons of
sites vulnerable today.

So I'd really like to not perpetuate the model of allowing cross-site
POSTs. An interesting first step in that direction would be to disallow
cross-site text/plain posts since they are so rare that it'd likely not
affect many sites.

/ Jonas

Reply | Threaded
Open this post in threaded view
|

What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Arthur Barstow
In reply to this post by Sunava Dutta

[[ My apologies for the late response to this thread (I was OOO last  
week). ]]

Sunava, All,

Would you please elaborate on Microsoft's intent with XDR with regard  
to W3C? For example is it being proposed as a new (Rec-track) spec  
for the Web API WG; is it a counter proposal for the WAF WG's AC4CSR  
spec; something else?

Regards, Art Barstow
---


On Mar 13, 2008, at 11:46 PM, ext Sunava Dutta wrote:

> Purpose
>
> XDR helps web developers to create secure mashups, replacing less  
> secure or non-performant approaches, including SCRIPT SRC’ing  
> content or IFRAME injection.
>
> Microsoft would like to submit XDR to the W3C for standardization  
> so that other browsers can benefit from this technology.


Reply | Threaded
Open this post in threaded view
|

RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Sunava Dutta

IE would like to propose XDR as a new (Rec-track) spec for the Web API WG. We think there is a place for both implementations within the charter of the Web API. Here's a re-summary of why that I've extracted from our proposal and our responses. For more details please refer to our proposal and the mail conversations on the topic:

- XDR is provably secure and does not introduce new surface area of attack compared to HTML Forms.
- It's really simple to program against.
- It accommodates several scenarios around public data aggregation.
- There may be a place for an access control model today, especially around RESTful services. The model is extensible and powerful however for the draft itself it will need more design thought to build a secure implementation.
- While the existing proposal can do what XDR does and more, it is complicated with XHR and also tricky to implement. As we mentioned before, authentication scenarios behave differently compared to XHR and so do headers. Editing the policy also quickly gets tricky as the number of rules increase. For public data aggregation scenarios web developers would benefit from the simple and secure XDR object.
If I'm not mistaken this model currently exists within the framework of the W3C in the form of the HTML 5.0 DOM Store Spec that's simple and it's bigger brother with a larger scope, the SQL based storage.

Along those lines, we are more than glad to pickup editorship here.
Cheers,
-Sunava

-----Original Message-----
From: Arthur Barstow [mailto:[hidden email]]
Sent: Monday, March 24, 2008 4:52 AM
To: Sunava Dutta
Cc: Web API WG (public); [hidden email]; Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
Subject: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

[[ My apologies for the late response to this thread (I was OOO last
week). ]]

Sunava, All,

Would you please elaborate on Microsoft's intent with XDR with regard
to W3C? For example is it being proposed as a new (Rec-track) spec
for the Web API WG; is it a counter proposal for the WAF WG's AC4CSR
spec; something else?

Regards, Art Barstow
---


On Mar 13, 2008, at 11:46 PM, ext Sunava Dutta wrote:

> Purpose
>
> XDR helps web developers to create secure mashups, replacing less
> secure or non-performant approaches, including SCRIPT SRC'ing
> content or IFRAME injection.
>
> Microsoft would like to submit XDR to the W3C for standardization
> so that other browsers can benefit from this technology.



Reply | Threaded
Open this post in threaded view
|

RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Ian Hickson

On Wed, 26 Mar 2008, Sunava Dutta wrote:
>
> IE would like to propose XDR as a new (Rec-track) spec for the Web API
> WG. We think there is a place for both implementations within the
> charter of the Web API.

I think it would be very bad for the Web platform for there to be multiple
ways to achieve this. We need to keep the platform simple, making it more
complicated like this for no extra benefit merely acts as a "divide and
conquer" strategy for proprietary platforms.


> - XDR is provably secure and does not introduce new surface area of
> attack compared to HTML Forms.

This is blatently untrue, a number of serious security problems with XDR
have already been raised (such as the fact that it encourages content-type
sniffing, and the fact that it encourages people to pass their credentials
to untrusted third parties).


> - It's really simple to program against.

IMHO keeping the existing XHR API is far simpler than introducing a
slightly different API that solves nearly the same problem.


> - It accommodates several scenarios around public data aggregation.

It fails to address the majority of use cases for cross-domain data
transfer on the Web.


> - There may be a place for an access control model today, especially
> around RESTful services. The model is extensible and powerful however
> for the draft itself it will need more design thought to build a secure
> implementation.

I disagree, I think XHR and Access Control have been shown to be just as
secure as XDR, possibly more so since they don't require bad security
practices like XDR does.


I strongly object to the Web API working group adopting a proprietary
solution developed by one vendor with no external consultation, when the
group has already spent several man-years' worth of time on a
technologically superior, safer, and more comprehensive solution that has
as much implementation experience and significantly more authoring
experience, based on extending existing APIs instead of arbitarily
introducing new, incompatible APIs.

--
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: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Sunava Dutta

Adding my team back on the thread...

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Ian Hickson
Sent: Wednesday, March 26, 2008 2:22 PM
To: Web API WG (public); [hidden email]
Subject: RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]


On Wed, 26 Mar 2008, Sunava Dutta wrote:
>
> IE would like to propose XDR as a new (Rec-track) spec for the Web API
> WG. We think there is a place for both implementations within the
> charter of the Web API.

I think it would be very bad for the Web platform for there to be multiple
ways to achieve this. We need to keep the platform simple, making it more
complicated like this for no extra benefit merely acts as a "divide and
conquer" strategy for proprietary platforms.


> - XDR is provably secure and does not introduce new surface area of
> attack compared to HTML Forms.

This is blatently untrue, a number of serious security problems with XDR
have already been raised (such as the fact that it encourages content-type
sniffing, and the fact that it encourages people to pass their credentials
to untrusted third parties).


> - It's really simple to program against.

IMHO keeping the existing XHR API is far simpler than introducing a
slightly different API that solves nearly the same problem.


> - It accommodates several scenarios around public data aggregation.

It fails to address the majority of use cases for cross-domain data
transfer on the Web.


> - There may be a place for an access control model today, especially
> around RESTful services. The model is extensible and powerful however
> for the draft itself it will need more design thought to build a secure
> implementation.

I disagree, I think XHR and Access Control have been shown to be just as
secure as XDR, possibly more so since they don't require bad security
practices like XDR does.


I strongly object to the Web API working group adopting a proprietary
solution developed by one vendor with no external consultation, when the
group has already spent several man-years' worth of time on a
technologically superior, safer, and more comprehensive solution that has
as much implementation experience and significantly more authoring
experience, based on extending existing APIs instead of arbitarily
introducing new, incompatible APIs.

--
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: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Travis Leithead
In reply to this post by Ian Hickson

>I strongly object to the Web API working group adopting a proprietary
>solution developed by one vendor with no external consultation, when the
>group has already spent several man-years' worth of time on a
>technologically superior, safer, and more comprehensive solution that has
>as much implementation experience and significantly more authoring
>experience, based on extending existing APIs instead of arbitarily
>introducing new, incompatible APIs.

I don't see how introducing a new object is 'incompatible'. It seems to have the same degree of 'compatibility' as introducing new APIs on the XHR object.

Reply | Threaded
Open this post in threaded view
|

Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Ian Hickson


On Mar 26, 2008, at 14:36, Travis Leithead  
<[hidden email]> wrote:

>> I strongly object to the Web API working group adopting a proprietary
>> solution developed by one vendor with no external consultation,  
>> when the
>> group has already spent several man-years' worth of time on a
>> technologically superior, safer, and more comprehensive solution  
>> that has
>> as much implementation experience and significantly more authoring
>> experience, based on extending existing APIs instead of arbitarily
>> introducing new, incompatible APIs.
>
> I don't see how introducing a new object is 'incompatible'. It seems  
> to have the same degree of 'compatibility' as introducing new APIs  
> on the XHR object.

The XHR2 proposal isn't a new API. It's the same API for same-domain  
as cross-domain requests.

--
Ian Hickson

Reply | Threaded
Open this post in threaded view
|

Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

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

Sunava Dutta wrote:
> IE would like to propose XDR as a new (Rec-track) spec for the Web API WG. We think there is a place for both implementations within the charter of the Web API. Here's a re-summary of why that I've extracted from our proposal and our responses. For more details please refer to our proposal and the mail conversations on the topic:
>
> - XDR is provably secure and does not introduce new surface area of attack compared to HTML Forms.

Like Hixie raised, this has been shown to be untrue. The XDR proposal
let you POST data with any content-type to intranet servers, something
which is not possible today.

> - It's really simple to program against.

I don't see that XDR is any simpler than access-control. To enable GET
requests for XDR the server sends:

XDomainRequestAllowed: 1

With access-control:

Access-Control: allow <*>

Neither of these look significantly simpler than the other.

POST requests in XDR isn't safe (see above) so it's not really
interesting to compare simplicity.

Also, with XDR users have to learn a new API. With access-control you
simply use the same APIs as you always have.

> - While the existing proposal can do what XDR does and more, it is complicated with XHR and also tricky to implement.

It took me about 2 days to implement the majority of access-control.
This went up to maybe a week as more features were added. This is hardly
significant time for any UA vendor.

> As we mentioned before, authentication scenarios behave differently compared to XHR and so do headers.

This is also untrue.

When it comes to headers the difference between XHR and AC+XHR is much
smaller than the difference between XHR and XDR.

Authentication in XDR is significantly different from how authentication
is done today as any authentication tokens have to be sent as part of
the request body, so again XDR is much more different from XHR than
AC+XHR is.

> Editing the policy also quickly gets tricky as the number of rules increase. For public data aggregation scenarios web developers would benefit from the simple and secure XDR object.

Again, to get equivalent level of functionality the only difference is
XDomainRequestAllowed: 1
vs
Access-Control: allow <*>

so I don't see how XDR is simpler than XHR.

Yes, if you want to use a larger feature set than what is supplied by
XDR things get more complicated. But that doesn't seem like a useful
comparison.

So all in all i'm opposed picking up XDR into W3C. It currently suffers
from bad security issues which I suspect would make most UA vendors not
want to implement it, and it's a less useful subset of a spec that is
already in development.

Best Regards,
Jonas Sicking

Reply | Threaded
Open this post in threaded view
|

RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Eric Lawrence-4
In reply to this post by Sunava Dutta

Ian--

Thanks for sharing your opinions.  I'd like to take the opportunity to clarify a few points of confusion.

<<This is blatently untrue, a number of serious security problems with XDR
have already been raised (such as the fact that it encourages content-type
sniffing

It's possible that you overlooked some mails on the thread?

Vis-à-vis content-type sniffing, it was plainly stated that Content-Type sniffing is neither recommended, nor necessary.  Any service which requires a client-sent Content-Type must be aware of the threat that the Content-Type header so sent is misleading and represents an attempt to attack the server.  As XDR will not allow setting of the header (a change made based on feedback from this group), there is no possibility that a service developer will mistake the request header as authoritative.  When this change is made, XDR will be unable to emit anything which could not have been sent by HTML forms.  In this way, we can demonstrate that XDR does not introduce new attack surface in the browser platform.

<<the fact that it encourages people to pass their credentials
to untrusted third parties).>>

XDR is a truly anonymous request and does not send credentials to ANY site (1st party, 3rd party), trustworthy or not.  In this way, we have high confidence that there is no possibility of executing a CSRF attack against an unsuspecting legacy server which uses cookies or HTTP authentication.

This can be contrasted with the CS-XHR proposal, in which credentials ARE automatically passed to 3rd party servers.

<<It fails to address the majority of use cases for cross-domain data
transfer on the Web.>>

I think this will prove to be a difficult statement to prove one way or another.  It is always challenging to enumerate the universe of current use-cases, let alone accurately predict those which will arise in the future.  We absolutely agree that it is possible to define use cases that XDR does not accommodate.  We believe that XDR enables the most common cross-domain scenarios with negligible impact to the attack surface of existing servers and the browser.

We have been contributing to the Access Control spec for some time, and we recognize the work that has gone into the CS-XHR proposal.

We have been monitoring the work on Access Control, CS-XHR, JSONRequest, and related proposals to ensure that XDR is secure against the various security threats the community has identified and has labored to block in the CS-XHR specifications.  We are now offering the results of our work (XDR) back to the community in the hope that all will benefit.


-Eric Lawrence
Internet Explorer
Security Program Manager


-----Original Message-----
From: Sunava Dutta
Sent: Wednesday, March 26, 2008 2:29 PM
To: Ian Hickson; Web API WG (public); [hidden email]
Cc: Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey; David Ross; Nikhil Kothari
Subject: RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Adding my team back on the thread...

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Ian Hickson
Sent: Wednesday, March 26, 2008 2:22 PM
To: Web API WG (public); [hidden email]
Subject: RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]


On Wed, 26 Mar 2008, Sunava Dutta wrote:
>
> IE would like to propose XDR as a new (Rec-track) spec for the Web API
> WG. We think there is a place for both implementations within the
> charter of the Web API.

I think it would be very bad for the Web platform for there to be multiple
ways to achieve this. We need to keep the platform simple, making it more
complicated like this for no extra benefit merely acts as a "divide and
conquer" strategy for proprietary platforms.


> - XDR is provably secure and does not introduce new surface area of
> attack compared to HTML Forms.

This is blatently untrue, a number of serious security problems with XDR
have already been raised (such as the fact that it encourages content-type
sniffing, and the fact that it encourages people to pass their credentials
to untrusted third parties).


> - It's really simple to program against.

IMHO keeping the existing XHR API is far simpler than introducing a
slightly different API that solves nearly the same problem.


> - It accommodates several scenarios around public data aggregation.

It fails to address the majority of use cases for cross-domain data
transfer on the Web.


> - There may be a place for an access control model today, especially
> around RESTful services. The model is extensible and powerful however
> for the draft itself it will need more design thought to build a secure
> implementation.

I disagree, I think XHR and Access Control have been shown to be just as
secure as XDR, possibly more so since they don't require bad security
practices like XDR does.


I strongly object to the Web API working group adopting a proprietary
solution developed by one vendor with no external consultation, when the
group has already spent several man-years' worth of time on a
technologically superior, safer, and more comprehensive solution that has
as much implementation experience and significantly more authoring
experience, based on extending existing APIs instead of arbitarily
introducing new, incompatible APIs.

--
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: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Ian Hickson
On Wed, 26 Mar 2008, Eric Lawrence wrote (reformatted to follow Internet
standards for mail quoting):
> >
> > This is blatently untrue, a number of serious security problems with
> > XDR have already been raised (such as the fact that it encourages
> > content-type sniffing
>
> Vis-à-vis content-type sniffing, it was plainly stated that Content-Type
> sniffing is neither recommended, nor necessary.

Stating this doesn't make it true. You are requiring that content be sent
as text/plain regardless of the actual content type. This is a blatent
violation of HTTP semantics, and requires that servers use non-standard
methods (such as sniffing or assumption) to determine the type of data
being sent. This is a security vulnerability. Given the number of times IE
has been the subject of security flaws due to Content-Type sniffing, one
would have thought you'd be more sensitive to this issue. :-)


> In this way, we can demonstrate that XDR does not introduce new attack
> surface in the browser platform.

This has been repeatedly shown to be untrue.


> > the fact that it encourages people to pass their credentials to
> > untrusted third parties).
>
> XDR is a truly anonymous request and does not send credentials to ANY
> site (1st party, 3rd party), trustworthy or not.

Exactly. This thus requires that if a page on host A wants to contact host
B on behalf of the user, host A needs to ask the user for his credentials
on host B, an extremely dangerous practice.

A _safe_ mechanism would allow the user to give the credentials to host B
directly without host A having to ask the user for those credentials.


> In this way, we have high confidence that there is no possibility of
> executing a CSRF attack against an unsuspecting legacy server which uses
> cookies or HTTP authentication.

But, as Jonas has pointed out, it is, in addition to the two problems I've
listed above, also vulnerable to CSRF in intranet environments, which is
possibly even more serious.


> This can be contrasted with the CS-XHR proposal, in which credentials
> ARE automatically passed to 3rd party servers.

This is, as the old adage goes, a feature, not a bug. It certainly isn't a
security issue -- XHR with Access-Control is not subject to CSRF, even on
intranets, due to the requirement that servers (host B) be contacted
first, before carrying out the request, to confirm that they are able to
handle data from the third party (host A).

--
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: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Jonas Sicking-2
In reply to this post by Eric Lawrence-4

Eric Lawrence wrote:

> Ian--
>
> Thanks for sharing your opinions.  I'd like to take the opportunity to clarify a few points of confusion.
>
> <<This is blatently untrue, a number of serious security problems with XDR
> have already been raised (such as the fact that it encourages content-type
> sniffing
>
> It's possible that you overlooked some mails on the thread?
>
> Vis-à-vis content-type sniffing, it was plainly stated that Content-Type sniffing is neither recommended, nor necessary.

I think you are misunderstanding the issues Ian has raised.

Since XDR does not let you set the Content-Type header, the server is in
fact required to sniff the content type. How else would the server
figure out the content type of the request body?

> Any service which requires a client-sent Content-Type must be aware of the threat that the Content-Type header so sent is misleading and represents an attempt to attack the server.  As XDR will not allow setting of the header (a change made based on feedback from this group), there is no possibility that a service developer will mistake the request header as authoritative.

I think you are misunderstanding the issues Ian has raised. The issue
isn't that the server treats the Content-Type as authoritative and then
trips over while trying to parse it, but rather that servers will sniff
the content, misunderstand what content type it really is, and then do
the wrong thing with it.

Off the top of my head I don't really see any security issues with the
sniffing (although sniffing is in general bad so I wouldn't be surprised
if there are any), but rather it just doesn't seem like a very robust
API and something that could loose out on functionality.

> When this change is made, XDR will be unable to emit anything which could not have been sent by HTML forms.  In this way, we can demonstrate that XDR does not introduce new attack surface in the browser platform.

As well as adding much less value.

> <<the fact that it encourages people to pass their credentials
> to untrusted third parties).>>
>
> XDR is a truly anonymous request and does not send credentials to ANY site (1st party, 3rd party), trustworthy or not.  In this way, we have high confidence that there is no possibility of executing a CSRF attack against an unsuspecting legacy server which uses cookies or HTTP authentication.

Again, this is not the concern. The concern is sites that do want to
transport private data. They are going to try to do this weather the
browser provides the API meant for this or not.

In fact, I would argue that XDR does encourage sending private data.
Most use cases for POST that I can think of involves knowing who the
data is coming from. Or have you had other use cases in mind?

The simplest way to authenticate fetching private data using XDR is to
ask the user for his/her credentials and then include that as part of
the uri in a GET request. This has two problems.

1. It means that the user will have to give his/her credentials to the
requesting site. This fosters a culture where you hand out your password
to 3rd party sites, something that is really unsafe.
2. Including the credentials in the uri will most likely mean that it
will get logged in various places along the way. For example proxies as
well as browser extensions often track uris of loaded resources.

Sure, you can say "hey, we said you shouldn't fetch private data using
XDR, it's your own fault for doing so". However that doesn't really help
anyone.

Additionally, it is not true that no authorization credentials is being
sent. Intranet sites might authorize simply based on the fact that you
can connect to the intranet server. I have still not seen anything in
the XDR spec to prevent internet->interanet POSTs so this still seems to
be the case.

> This can be contrasted with the CS-XHR proposal, in which credentials ARE automatically passed to 3rd party servers.

But the credentials are kept away from the 3rd party site as well as
kept out of server logs.

> <<It fails to address the majority of use cases for cross-domain data
> transfer on the Web.>>
>
> I think this will prove to be a difficult statement to prove one way or another.  It is always challenging to enumerate the universe of current use-cases, let alone accurately predict those which will arise in the future.  We absolutely agree that it is possible to define use cases that XDR does not accommodate.  We believe that XDR enables the most common cross-domain scenarios with negligible impact to the attack surface of existing servers and the browser.
>
> We have been contributing to the Access Control spec for some time, and we recognize the work that has gone into the CS-XHR proposal.

I definitely appreciate all the work that Microsoft has put into the
spec, but am saddened that there was no mention about XDR in any of the
numerous posts from anyone at microsoft.

/ Jonas

Reply | Threaded
Open this post in threaded view
|

Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Stewart Brodie
In reply to this post by Sunava Dutta

Sunava Dutta <[hidden email]> wrote:

> IE would like to propose XDR as a new (Rec-track) spec for the Web API WG.

Whatever you decide to do, please could you choose a different acronym, as
XDR is already used for encoding in RPC.

--
Stewart Brodie
Software Engineer
ANT Software Limited

Reply | Threaded
Open this post in threaded view
|

RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Sunava Dutta

Agreed. I think it's entirely reasonable to call XDR by its full DOM name, XDomainRequest.

-----Original Message-----
From: Stewart Brodie [mailto:[hidden email]]
Sent: Thursday, March 27, 2008 3:47 AM
To: Sunava Dutta
Cc: Web API WG (public)
Subject: Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Sunava Dutta <[hidden email]> wrote:

> IE would like to propose XDR as a new (Rec-track) spec for the Web API WG.

Whatever you decide to do, please could you choose a different acronym, as
XDR is already used for encoding in RPC.

--
Stewart Brodie
Software Engineer
ANT Software Limited


Reply | Threaded
Open this post in threaded view
|

XDR and bike sheds Re: What is Microsoft's intent...

Charles McCathieNevile-2

On Fri, 28 Mar 2008 02:22:41 +0100, Sunava Dutta  
<[hidden email]> wrote:

> Agreed. I think it's entirely reasonable to call XDR by its full DOM  
> name, XDomainRequest.

Which, just as XMLHttpRequest is habitually shortened to XHR, will be  
shortened to XDR in the real world.

I don't think we can avoid all name clashes - we should look at the one  
that are close in functionality and try to avoid those in particular.

cheers

Chaals

> -----Original Message-----
> From: Stewart Brodie [mailto:[hidden email]]
> Sunava Dutta <[hidden email]> wrote:
>
>> IE would like to propose XDR as a new (Rec-track) spec for the Web API  
>> WG.
>
> Whatever you decide to do, please could you choose a different acronym,  
> as XDR is already used for encoding in RPC.



--
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: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Close, Tyler J.
In reply to this post by Jonas Sicking-2

I think the XDR proposal is pretty good and is the best of the current proposals to push forward to standardization. I hope Microsoft finds a way to make that happen.

Some responses to Jonas' comments are inline below...

Jonas Sicking wrote:

> Eric Lawrence wrote:
> > Ian--
> >
> > Thanks for sharing your opinions.  I'd like to take the
> opportunity to clarify a few points of confusion.
> >
> > <<This is blatently untrue, a number of serious security
> problems with XDR
> > have already been raised (such as the fact that it
> encourages content-type
> > sniffing
> >
> > It's possible that you overlooked some mails on the thread?
> >
> > Vis-à-vis content-type sniffing, it was plainly stated that
> Content-Type sniffing is neither recommended, nor necessary.
>
> I think you are misunderstanding the issues Ian has raised.
>
> Since XDR does not let you set the Content-Type header, the
> server is in
> fact required to sniff the content type. How else would the server
> figure out the content type of the request body?

I think Eric's point is that the client specified Content-Type header cannot be trusted to accurately describe the content, so the server must parse the content under the assumption that the header is misleading. Given that status-quo, and assuming the resource only accepts one Content-Type, omitting the header doesn't seem to change the server's responsibilities.

There could be a danger when the resource accepts more than one media type and the server determines that the client sent a different media type than the client thought it was sending. In this case, the server sees the client as saying something that the client didn't mean to say. To avoid this scenario, there would have to be some mechanism agreed to between the client and the server for specifying the intended media type. This role is precisely what the Content-Type header was created for, but it has unfortunately been overloaded with security implications. Having client and server coordinate the media type based on a URL query string argument seems like the best alternative.

> > XDR is a truly anonymous request and does not send
> credentials to ANY site (1st party, 3rd party), trustworthy
> or not.  In this way, we have high confidence that there is
> no possibility of executing a CSRF attack against an
> unsuspecting legacy server which uses cookies or HTTP authentication.
>
> Again, this is not the concern. The concern is sites that do want to
> transport private data. They are going to try to do this weather the
> browser provides the API meant for this or not.

Sending the user's cookies, as AC4CSR does, is just not a viable design, since the target resource cannot determine whether or not the user consented to the request. I've posted several explanations of the attacks enabled by this use of ambient authority, and, in my opinion, the issues are still outstanding. The use of ambient authority in AC4CSR is a show-stopper, as reflected in the decision Mozilla announced on this mailing list.

> In fact, I would argue that XDR does encourage sending private data.
> Most use cases for POST that I can think of involves knowing who the
> data is coming from. Or have you had other use cases in mind?

There are many other ways to authorize a request, other than sending the user's credentials, which is among the worst ways.

> Additionally, it is not true that no authorization
> credentials is being
> sent. Intranet sites might authorize simply based on the fact that you
> can connect to the intranet server. I have still not seen anything in
> the XDR spec to prevent internet->interanet POSTs so this
> still seems to
> be the case.

Currently, an HTML form can POST internet->intranet with Content-Type of "application/x-www-form-urlencoded" or "text/plain". The XDR proposal adds a third case of no specified Content-Type (but with no cookies or custom headers). It seems highly unlikely that an intranet resource correctly defends against the first two cases, but is vulnerable to the third. I would rather bet on this than work through all the things that might go wrong with AC4CSR's pre-flight request, caching, ACLs and use of ambient authority.

> I definitely appreciate all the work that Microsoft has put into the
> spec, but am saddened that there was no mention about XDR in
> any of the
> numerous posts from anyone at microsoft.

I think the AC4CSR spec is a goner, and so appreciate Microsoft stepping up with a proposal that seems more likely to survive study and deployment. Given the Mozilla announcement, now seems like the right time to move on from the AC4CSR proposal.

--Tyler

"IHTMLXDomainRequest Interface ()"
<http://msdn2.microsoft.com/en-us/library/cc288108(VS.85).aspx>

"Access Control for Cross-site Requests"
<http://www.w3.org/TR/access-control/>

Reply | Threaded
Open this post in threaded view
|

Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Boris Zbarsky

Close, Tyler J. wrote:
> I think Eric's point is that the client specified Content-Type header cannot
> be trusted to accurately describe the content, so the server must parse the
> content under the assumption that the header is misleading.

I don't think anyone is arguing about that.

> There could be a danger when the resource accepts more than one media type
> and the server determines that the client sent a different media type than
> the client thought it was sending.

Actually, the danger is when the resource accepts more that one media type,
there is a proxy or firewall that filters which types are allowed (possibly
depending on the origin), and the sniffing on the server and firewall is not
exactly identical.

This is the most common security issue with content-type sniffing: one program
trying to protect another from certain types of content, and failing because the
type-identification algorithms are not precisely identical.

The proposal of communicating the type via some mechanism other than
Content-Type would work to address this issue if the firewall is aware of that
mechanism and has exactly the same implementation for type detection as the
resource.  It seems to me that this is barely less fragile as relying on content
sniffing...

-Boris

Reply | Threaded
Open this post in threaded view
|

Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Maciej Stachowiak
In reply to this post by Close, Tyler J.


On Apr 2, 2008, at 4:52 PM, Close, Tyler J. wrote:

>
> Sending the user's cookies, as AC4CSR does, is just not a viable  
> design, since the target resource cannot determine whether or not  
> the user consented to the request. I've posted several explanations  
> of the attacks enabled by this use of ambient authority, and, in my  
> opinion, the issues are still outstanding. The use of ambient  
> authority in AC4CSR is a show-stopper, as reflected in the decision  
> Mozilla announced on this mailing list.

Can you please post these examples again, or pointers to where you  
posted them? I believe they have not been previously seen on the Web  
API list. A number of people have mentioned that the AC approach to  
cross-site XHR is insecure (or that XDR is somehow more secure), but I  
have not yet seen any examples of specific attacks. I would love to  
see this information. If I do not see a description of a specific  
attack soon I will assume these claims are just FUD.

Note also that sending of cookies is not an essential feature of  
AC4CSR; certainly it could be a viable spec with that feature removed.  
Do you believe there are any other showstopper issues?

Regards,
Maciej


Reply | Threaded
Open this post in threaded view
|

RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Close, Tyler J.


Maciej Stachowiak wrote:

> On Apr 2, 2008, at 4:52 PM, Close, Tyler J. wrote:
>
> >
> > Sending the user's cookies, as AC4CSR does, is just not a viable
> > design, since the target resource cannot determine whether or not
> > the user consented to the request. I've posted several explanations
> > of the attacks enabled by this use of ambient authority, and, in my
> > opinion, the issues are still outstanding. The use of ambient
> > authority in AC4CSR is a show-stopper, as reflected in the decision
> > Mozilla announced on this mailing list.
>
> Can you please post these examples again, or pointers to where you
> posted them? I believe they have not been previously seen on the Web
> API list.

I've written several messages to the appformats mailing list. I suggest reading all of them. The most detailed description of the attacks are in the message at:

http://www.w3.org/mid/C7B67062D31B9E459128006BAAD0DC3D074F8B6507@...

with a correction at:

http://www.w3.org/mid/C7B67062D31B9E459128006BAAD0DC3D074F8B650D@...


> A number of people have mentioned that the AC approach to
> cross-site XHR is insecure (or that XDR is somehow more secure), but I
> have not yet seen any examples of specific attacks. I would love to
> see this information. If I do not see a description of a specific
> attack soon I will assume these claims are just FUD.

I think we've met before at a SHDH event. That was a more pleasant conversation. Hopefully, we'll be able to regain that tone.

> Note also that sending of cookies is not an essential feature of
> AC4CSR; certainly it could be a viable spec with that feature removed.
> Do you believe there are any other showstopper issues?

Possibly. There is a lot of complexity in the AC4CSR proposal. I've been writing about the most severe things as I find them.

--Tyler

Reply | Threaded
Open this post in threaded view
|

RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Ian Hickson

On Thu, 3 Apr 2008, Close, Tyler J. wrote:

> Maciej Stachowiak wrote:
> >
> > Can you please post these examples again, or pointers to where you
> > posted them? I believe they have not been previously seen on the Web
> > API list.
>
> I've written several messages to the appformats mailing list. I suggest
> reading all of them. The most detailed description of the attacks are in
> the message at:
>
> http://www.w3.org/mid/C7B67062D31B9E459128006BAAD0DC3D074F8B6507@...
>
> with a correction at:
>
> http://www.w3.org/mid/C7B67062D31B9E459128006BAAD0DC3D074F8B650D@...

As noted here:

   http://lists.w3.org/Archives/Public/public-appformats/2008Feb/0138.html

...these are not problems with the Access Control and XXX specs. XDR is
just as susceptible to these problems.

The above e-mail also describes ways to mitigate these problems.

--
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: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]

Maciej Stachowiak
In reply to this post by Close, Tyler J.


Hi Tyler,

On Apr 2, 2008, at 6:08 PM, Close, Tyler J. wrote:

>
> Maciej Stachowiak wrote:
>> On Apr 2, 2008, at 4:52 PM, Close, Tyler J. wrote:
>>
>>>
>>> Sending the user's cookies, as AC4CSR does, is just not a viable
>>> design, since the target resource cannot determine whether or not
>>> the user consented to the request. I've posted several explanations
>>> of the attacks enabled by this use of ambient authority, and, in my
>>> opinion, the issues are still outstanding. The use of ambient
>>> authority in AC4CSR is a show-stopper, as reflected in the decision
>>> Mozilla announced on this mailing list.
>>
>> Can you please post these examples again, or pointers to where you
>> posted them? I believe they have not been previously seen on the Web
>> API list.
>
> I've written several messages to the appformats mailing list. I  
> suggest reading all of them.

W3C's search finds the following 50 messages from you:

http://www.w3.org/Search/Mail/Public/search?hdr-1-name=from&hdr-1-query=tyler.close%40hp.com&index-grp=Public__FULL&index-type=t&type-index=public-appformats&resultsperpage=20&sortby=date&page=2

Can you help me out with finding which contain descriptions of  
security flaws in the spec (which have not yet been addressed through  
spec changes)? The first three I looked at randomly did not contain  
any descriptions of security flaws.

> The most detailed description of the attacks are in the message at:
>
> http://www.w3.org/mid/C7B67062D31B9E459128006BAAD0DC3D074F8B6507@...
>
> with a correction at:
>
> http://www.w3.org/mid/C7B67062D31B9E459128006BAAD0DC3D074F8B650D@...

Thanks for stepping up with some actual specific attacks. I will read  
them carefully and respond soon with my analysis (also in light of  
Ian's reply to you).

>
>> A number of people have mentioned that the AC approach to
>> cross-site XHR is insecure (or that XDR is somehow more secure),  
>> but I
>> have not yet seen any examples of specific attacks. I would love to
>> see this information. If I do not see a description of a specific
>> attack soon I will assume these claims are just FUD.
>
> I think we've met before at a SHDH event. That was a more pleasant  
> conversation. Hopefully, we'll be able to regain that tone.

Sorry for tossing you in the same bucket as those making (so far)  
unsubstantiated claims. I'm not trying to be unfriendly here, I'm just  
trying to get us to objective facts about security, which so far have  
been lacking in this discussion. This is very frustrating to me,  
because saying a spec is insecure without giving details is just  
yelling fire in a crowded theater. Whereas describing specific attacks  
is very helpful, so thank you for doing so.

>
>> Note also that sending of cookies is not an essential feature of
>> AC4CSR; certainly it could be a viable spec with that feature  
>> removed.
>> Do you believe there are any other showstopper issues?
>
> Possibly. There is a lot of complexity in the AC4CSR proposal. I've  
> been writing about the most severe things as I find them.

Now would be a great time to collapse the wave function on that  
"possibly". I have been trying to think of attack models against both  
AC and XDR myself and so far have not come up with anything that holds  
water (I did mistakenly think AC had a DNS rebinding vulnerability,  
but I was wrong). We must carefully identify the security issues  
(including second-order effects that may result from limiting  
capabilities) to make informed decisions about this technology area.

Regards,
Maciej


1234567