IE Team's Proposal for Cross Site Requests

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

IE Team's Proposal for Cross Site Requests

Sunava Dutta

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.

 

 

XDomainRequest (XDR)

Table of Contents

1.0   Summary

2.0   Background: Overview of how XDR allows cross site requests

3.0   API Documentation: Lists the programming interface/methods/properties

4.0   Security Model Flowchart: Highlights the security checks that IE8 makes for an XDR Request.

5.0   Sample Site and Script: For developers wishing to create an XDR page.

6.0   Developer Benefits of using XDR: Covers XDR’s strengths by demonstrating XDR’s goals of security and simplicity.

7.0   Developer Release Notes: A short bulleted list of issues developers should we aware of when using the object and a summary of what XDR cannot do.

1.0 Summary

With Cross Domain Request (XDR) developers can create cross site data aggregation scenarios. Similar to the XMLHttpRequest object  but with a simpler programming model, this request, called XDomainRequest, is an easy way to make anonymous requests to third party sites that support XDR and opt in to making their data available across domains. Three lines of code will have you making basic cross site requests. This will ensure data aggregation for public sites such as blogs etc will be simple, secure and fast. XDR is an approach designed from the grounds up with a focus on security. We understand the current cross domain XMLHTTPRequest proposal and recognize its ability to provide a broader set of services particularly around declarative auditing for access control based scenarios and authenticated connections. It does however come at the risk of more complexity and surface area of attack. While these are certainly compelling scenarios we realize that existing implementations have bugs (linked 1, 2), some of which are resolved from the past like TOUCTOU and others like DNS Rebinding remain mostly unaddressed. In addition, maintaining configuration is challenging post deployment as Flash has encountered (wildcarding) in the past. The IE team is not comfortable implementing a feature with a high surface area of attack and open/incoming security issues and proposes XDR as a safer alternative.

 

2.0 Background

 

 

Browsers enforce the same site origin policy, which blocks web pages from accessing data from another domain. Websites often work around this policy by having their server request content from another site’s server in the backend, thus circumventing the check within the browser.

 


 


 

 

 

 

 

Text Box: Figure 1 – IE7 and below need to make a request to the mashup server which then needs to be proxied to the web server.

 

In IE8 web pages can simply make a cross domain data request within the browser using the new XDomainRequest object instead of a server-to-server requests.

Cross domain requests require mutual consent between the webpage and server. You can initiate a cross domain request in your webpage by creating a xdomainrequest object off the window object and opening a connection to a particular domain. The browser will request data from the domain’s server by sending a XDomainRequest: 1 header. It will only complete the connection if the server responds with a XDomainRequestAllowed header with the value “1” for true.

 

For example, a server’s asp page includes the following response header:

Response.AppendHeader("XDomainRequestAllowed","1");

 

 

 

Security note: 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.

 


3.0 API Documentation

 

 

Methods

Once you create a xdomainrequest object, you can use the open() method to open a connection with a domain’s server. This method supports the GET and POST HTTP methods and takes the URL to connect to as a parameter. Once you’ve opened a connection, you can use the send() method to send a data string to the server for processing if needed. For example:

 

// 1. Create XDR object

xdr = new XDomainRequest();

 

//2. Open connection with server using POST method

xdr.open(“POST”, “http://www.contoso.com/xdr.txt”)

 

//3. Send string data to server

xdr.send(“data to be processed”)

 

XDR also has an abort() method to cancel an active request, which takes no parameters. Data is not available on an abort.

 

Properties

·         responseText - After the server responds, you can retrieve the data string through the read-only responseText property.

·         timeout - You can use the timeout property to set or retrieve the number of milliseconds the browser should wait for a server to respond.   IE defaults to no timeout if this property is not explicitly set. If the request times out, data is not available.

·         contentType – If you are posting data to the server, use the contentType property to define the content type string that will be sent to the server. If you are using a GET then this property will allow you to read the content type.

 

Events

XDR has the following events:

·         onerror – this event fires when there is an error and the request cannot be completed. For example, the network is not available

·         ontimeout – this event fires when the request reaches its timeout as defined by the above timeOut property. If the request times out data is not available.

·         onprogress – this event fires while the server responds to the request by streaming data back to the browser.

·         onload – this event fires when the cross domain request is complete and data is available.

 

Security note: Cross domain requests can only be sent and received from a web page to URLs in the following IE zones. We discourage Intranet sites from making XDR data available to help prevent intranet data from leaking to malicious Internet sites.

 

 

 

Webpage equests data from a URL in the following zone:

 

 

Local

Intranet

Trusted (Intranet)

Trusted (Internet)

Internet

Restricted

Webpage is in the following zone:

Local

Allow

Allow

Allow

Allow

Allow

Block

Intranet

Block

Allow

Allow

Allow

Allow

Block

Trusted (Intranet)

Block

Allow

Allow

Allow

Allow

Block

Trusted (Internet)

Block

Block

Block

Allow

Allow

Block

Internet

Block

Block

Block

Allow

Allow

Block

Restricted

Block

Block

Block

Block

Block

Block

 

Security note: When using these XDR, safely handling data provided by another web application is a critical operation.

 

For instance, the response could be parsed directly by Javascript, or it could be evaluated with a freely available JSON parser (see http://www.json.org/) or it could be inserted into a DOM as static text (using .innerText).

 

 

 

Server Side

The browser will request data from the domain’s server by sending a XDomainRequest: 1 header. It will only complete the connection if the server responds with an XDomainRequestAllowed header with the value “1” for true.

For example, a server’s asp page includes the following response header:

Response.AppendHeader("XDomainRequestAllowed","1");

This can be done in IIS, for example, using an ASP.NET page. The line of code below can be embedded in your ASP page to return the header.

 

<<% Response.AddHeader  "XDomainRequestAllowed","1" %>Data

 

 

4.0 Security Model Flowchart

XDR Flowchart

5.0 Sample Site and Script

 

Please refer to the AJAX Hands on Labs on MSDN for demo script. This will need to be set up on your machine from the resource files.

 

6.0 Other Developer Benefits of Using XDR

1.        Simple development model.

a.        On the server, the server operator must simply add one new header to his HTTP response indicating that cross-domain sources may receive the data.  HTTP Headers can be added by any CGI-style process (PHP/ASPNET/etc) or by the web server software (Apache/IIS/etc) itself.

b.        On the client, the XDR object is all about cross-domain-requests.  Because XDR is a new object we are not forced to “bolt on” cross-domain security.  For example, XDR has no means of adding a custom header, because custom headers are dangerous for cross-domain security as the current web model does not expect a custom header being sent across domains. We’ve encountered experiences when web applications in the past if encountering a custom header using XHR assume it’s coming from the same site.

 

2.        Provably secure

a.        The XDR security model is simple.  The client sends a request that clearly identifies its cross-domain nature, and the server must respond in kind for the Same-Origin-Policy to be relaxed such that the client can read the response.  If the server does not set the response header (a “non-participating” server), the client script is not permitted to read the response or determine anything about the target server.

 

b.        XDR is very tightly scoped to minimize the risk of increasing security exposure of the browser.

1.        Specifically, any request sent by XDR could also be emitted by a properly coded HTML FORM object.  Hence, any “non-participating” web server put at risk by XDR is also at risk from simple HTML.

 

Note: The only additional exposure XDR adds is the ability of the client to set a specific Content-Type header.

 

2.        As XDR strips all credentials and cookies, it prevents even less attack surface for use in a Cross-Site-Request-Forgery (CSRF) attack than a HTML Form.

 

c.        XDR attempts to block cross-zone/protocol requests, an ASR which exceeds that undertaken elsewhere in the browser (e.g. SCRIPT SRC) due to compatibility concerns.

 

3.        Improved Access  Control “Locality”

a.        Unlike policy file-based security, the XDR handshake is a part of the HTTP request and response.  This means that XDR is not at risk from DNS-Rebinding or Time-of-Check-Time-of-Use attacks.

b.        Policy files must be located in a particular location on the server, which may cause operational problems for users with limited permissions on the server.  For example, consider the shared hosting case, where only one admin may write to the server root, but many users have permissions to write to sub-folders.  The users must petition the admin for an update to the policy file.

 

4.        Access-Control Flexibility

a.        As Access-Control is based on a per-response basis, the server may choose to allow or deny access based upon any criteria desired.  For instance, Referer of client, time of day, number of requests per hour, etc, etc.

b.        The XDR security model prevents attackers from easily determining the access control rules of the server.  The server may keep their rules as a trade secret.

 

7.0 Developer Release Notes

·         Not yet available across browsers; not a W3C standard.

·         Services must be explicitly coded to operate with XDR. 

·         As HTTP Methods are deliberately limited, standard REST-based interop is not possible.

·         As credentials are not provided by the browser, the client must transmit them in the request body.  This typically should not be a problem but this could prevent use of the HttpOnly attribute on cookies that must be sent for credentials.

·         The XDR handshake is HTTP-specific and cannot be directly translated for reuse in other protocols or situations (E.g. raw socket access). 

 

 

 

--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer

One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418

FAX# (425) 936-7329

 


image001.png (41K) Download Attachment
image004.png (36K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Jonas Sicking-2

How do you define the "Intranet", "Internet", "Restricted" etc zones?
Without correct definitions for these zones it seems possible to attack
intranet servers by sending unsafe (such as POST or DELETE) requests to
intranet servers from internet pages.

I'd also recommend sending this to the web applications formats group
since they have been working on a very similar security proposal.

/ Jonas

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.
>
>  
>
>  
>
> XDomainRequest (XDR)
>
>
>     Table of Contents
>
> 1.0   Summary
>
> 2.0   Background: /Overview of how XDR allows cross site requests/
>
> 3.0   API Documentation: /Lists the programming
> interface/methods/properties/
>
> 4.0   Security Model Flowchart: /Highlights the security checks that IE8
> makes for an XDR Request./
>
> 5.0   Sample Site and Script: /For developers wishing to create an XDR
> page./
>
> 6.0   Developer Benefits of using XDR: /Covers XDR’s strengths by
> demonstrating XDR’s goals of security and simplicity./
>
> 7.0   Developer Release Notes: /A short bulleted list of issues
> developers should we aware of when using the object and a summary of
> what XDR cannot do./
>
> 1.0 Summary
>
> /With* Cross Domain Request* *(XDR)* developers can create cross site
> data aggregation scenarios. Similar to the XMLHttpRequest object  but
> with a simpler programming model, this request, called XDomainRequest,
> is an easy way to make anonymous requests to third party sites that
> support XDR and opt in to making their data available across domains.
> Three lines of code will have you making basic cross site requests. This
> will ensure data aggregation for public sites such as blogs etc will be
> simple, secure and fast. XDR is an approach designed from the grounds up
> with a focus on security. We understand the current cross domain
> XMLHTTPRequest proposal and recognize its ability to provide a broader
> set of services particularly around declarative auditing for access
> control based scenarios and authenticated connections. It does however
> come at the risk of more complexity and surface area of attack. While
> these are certainly compelling scenarios we realize that existing
> implementations have bugs (linked 1
> <http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html>,
> 2 <https://bugzilla.mozilla.org/show_bug.cgi?id=389508>), some of which
> are resolved from the past like TOUCTOU and others like DNS Rebinding
> remain mostly unaddressed. In addition, maintaining configuration is
> challenging post deployment as Flash has encountered
> <http://blog.monstuff.com/archives/000302.html> (wildcarding) in the
> past. The IE team is not comfortable implementing a feature with a high
> surface area of attack and open/incoming security issues and proposes
> XDR as a safer alternative.///
>
>  
>
> 2.0 Background
>
>  
>
>  
>
> Browsers enforce the same site origin policy, which blocks web pages
> from accessing data from another domain. Websites often work around this
> policy by having their server request content from another site’s server
> in the backend, thus circumventing the check within the browser.
>
>  
>
>
>  
>
>
>
>
>  
>
>  
>
>  
>
>  
>
>  
>
> Text Box: Figure 1 – IE7 and below need to make a request to the mashup
> server which then needs to be proxied to the web server.
>
>
>  
>
> In IE8 web pages can simply make a cross domain data request within the
> browser using the new /XDomainRequest/ object instead of a
> server-to-server requests.
>
> Cross domain requests require mutual consent between the webpage and
> server. You can initiate a cross domain request in your webpage by
> creating a /xdomainrequest /object off the window object and opening a
> connection to a particular domain. The browser will request data from
> the domain’s server by sending a /XDomainRequest: 1 /header. It will
> only complete the connection if the server responds with a
> XDomainRequestAllowed header with the value “1” for true.
>
>  
>
> For example, a server’s asp page includes the following response header:
>
> Response.AppendHeader("XDomainRequestAllowed","1");
>
>  
>
>  
>
>  
>
> *Security note: *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.
>
>  
>
>
>
>
> 3.0 API Documentation
>
>  
>
> * *
>
> *Methods*
>
> Once you create a xdomainrequest object, you can use the /open()/ method
> to open a connection with a domain’s server. This method supports the
> GET and POST HTTP methods and takes the URL to connect to as a
> parameter. Once you’ve opened a connection, you can use the /send()/
> method to send a data string to the server for processing if needed. For
> example:
>
>  
>
> // 1. Create XDR object
>
> xdr = new XDomainRequest();
>
>  
>
> //2. Open connection with server using POST method
>
> xdr.open(“POST”, “http://www.contoso.com/xdr.txt”)
>
>  
>
> //3. Send string data to server
>
> xdr.send(“data to be processed”)
>
>  
>
> XDR also has an /abort() /method to cancel an active request, which
> takes no parameters. Data is not available on an abort.
>
> * *
>
> *Properties*
>
> ·         *responseText - *After the server responds, you can retrieve
> the data string through the read-only /responseText /property.
>
> ·         *timeout - *You can use the /timeout /property to set or
> retrieve the number of milliseconds the browser should wait for a server
> to respond.   IE defaults to no timeout if this property is not
> explicitly set. If the request times out, data is not available.
>
> ·         *contentType *– If you are posting data to the server, use the
> /contentType /property to define the content type string that will be
> sent to the server. If you are using a GET then this property will allow
> you to read the content type.
>
>  
>
> *Events*
>
> XDR has the following events:
>
> ·         *onerror* – this event fires when there is an error and the
> request cannot be completed. For example, the network is not available
>
> ·         *ontimeout *– this event fires when the request reaches its
> timeout as defined by the above timeOut property. If the request times
> out data is not available.
>
> ·         *onprogress –* this event fires while the server responds to
> the request by streaming data back to the browser.
>
> ·         *onload *– this event fires when the cross domain request is
> complete and data is available.
>
>  
>
> *Security note: *Cross domain requests can only be sent and received
> from a web page to URLs in the following IE zones. We discourage
> Intranet sites from making XDR data available to help prevent intranet
> data from leaking to malicious Internet sites.
>
>  
>
>  
>
>
>
>  
>
>
>
> *Webpage equests data from a URL in the following zone:*
>
>  
>
>
>
>  
>
>
>
> Local
>
>
>
> Intranet
>
>
>
> Trusted (Intranet)
>
>
>
> Trusted (Internet)
>
>
>
> Internet
>
>
>
> Restricted
>
> *Webpage is in the following zone:*
>
>
>
> Local
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Block
>
> Intranet
>
>
>
> Block
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Block
>
> Trusted (Intranet)
>
>
>
> Block
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Block
>
> Trusted (Internet)
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Block
>
> Internet
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Block
>
> Restricted
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
> * *
>
> *Security note: *When using these XDR, safely handling data provided by
> another web application is a critical operation.
>
>  
>
> For instance, the response could be parsed directly by Javascript, or it
> could be evaluated with a freely available JSON parser (see
> http://www.json.org/) or it could be inserted into a DOM as static text
> (using .innerText).
>
> * *
>
> * *
>
> * *
>
> *Server Side*
>
> The browser will request data from the domain’s server by sending a
> /XDomainRequest: 1 /header. It will only complete the connection if the
> server responds with an XDomainRequestAllowed header with the value “1”
> for true.
>
> For example, a server’s asp page includes the following response header:
>
> *Response.AppendHeader("XDomainRequestAllowed","1");*
>
> This can be done in IIS, for example, using an ASP.NET page. The line of
> code below can be embedded in your ASP page to return the header.
>
>  
>
> *<<% Response.AddHeader  "XDomainRequestAllowed","1" %>Data*
>
> * *
>
> * *
>
> 4.0 Security Model Flowchart
>
> XDR Flowchart
>
> 5.0 Sample Site and Script
>
>  
>
> Please refer to the AJAX Hands on Labs
> <http://code.msdn.microsoft.com/iemix08labs/Release/ProjectReleases.aspx?ReleaseId=590>
> on MSDN for demo script. This will need to be set up on your machine
> from the resource files.
>
>  
>
> 6.0 Other Developer Benefits of Using XDR
>
> 1.        Simple development model.
>
> a.        On the server, the server operator must simply add one new
> header to his HTTP response indicating that cross-domain sources may
> receive the data.  HTTP Headers can be added by any CGI-style process
> (PHP/ASPNET/etc) or by the web server software (Apache/IIS/etc) itself.
>
> b.        On the client, the XDR object is all about
> cross-domain-requests.  Because XDR is a new object we are not forced to
> “bolt on” cross-domain security.  For example, XDR has no means of
> adding a custom header, because custom headers are dangerous for
> cross-domain security as the current web model does not expect a custom
> header being sent across domains. We’ve encountered experiences when web
> applications in the past if encountering a custom header using XHR
> assume it’s coming from the same site.
>
>  
>
> 2.        Provably secure
>
> a.        The XDR security model is simple.  The client sends a request
> that clearly identifies its cross-domain nature, and the server must
> respond in kind for the Same-Origin-Policy to be relaxed such that the
> client can read the response.  If the server does not set the response
> header (a “non-participating” server), the client script is not
> permitted to read the response or determine anything about the target
> server.
>
>  
>
> b.        XDR is very tightly scoped to minimize the risk of increasing
> security exposure of the browser.
>
> 1.        Specifically, any request sent by XDR could also be emitted by
> a properly coded HTML FORM object.  Hence, any “non-participating” web
> server put at risk by XDR is also at risk from simple HTML.
>
>  
>
> Note: The only additional exposure XDR adds is the ability of the client
> to set a specific Content-Type header.
>
>  
>
> 2.        As XDR strips all credentials and cookies, it prevents even
> less attack surface for use in a Cross-Site-Request-Forgery (CSRF)
> <http://en.wikipedia.org/wiki/Cross-site_request_forgery> attack than a
> HTML Form.
>
>  
>
> c.        XDR attempts to block cross-zone/protocol requests, an ASR
> which exceeds that undertaken elsewhere in the browser (e.g. SCRIPT SRC)
> due to compatibility concerns.
>
>  
>
> 3.        Improved Access  Control “Locality”
>
> a.        Unlike policy file-based security, the XDR handshake is a part
> of the HTTP request and response.  This means that XDR is not at risk
> from DNS-Rebinding <http://en.wikipedia.org/wiki/DNS_rebinding> or
> Time-of-Check-Time-of-Use
> <http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use> attacks.
>
> b.        Policy files must be located in a particular location on the
> server, which may cause operational problems for users with limited
> permissions on the server.  For example, consider the shared hosting
> case, where only one admin may write to the server root, but many users
> have permissions to write to sub-folders.  The users must petition the
> admin for an update to the policy file.
>
>  
>
> 4.        Access-Control Flexibility
>
> a.        As Access-Control is based on a per-response basis, the server
> may choose to allow or deny access based upon any criteria desired.  For
> instance, Referer of client, time of day, number of requests per hour,
> etc, etc.
>
> b.        The XDR security model prevents attackers from easily
> determining the access control rules of the server.  The server may keep
> their rules as a trade secret.
>
>  
>
> 7.0 Developer Release Notes
>
> ·         Not yet available across browsers; not a W3C standard.
>
> ·         Services must be explicitly coded to operate with XDR.
>
> ·         As HTTP Methods are deliberately limited, standard REST-based
> interop is not possible.
>
> ·         As credentials are not provided by the browser, the client
> must transmit them in the request body.  This typically should not be a
> problem but this could prevent use of the HttpOnly attribute on cookies
> that must be sent for credentials.
>
> ·         The XDR handshake is HTTP-specific and cannot be directly
> translated for reuse in other protocols or situations (E.g. raw socket
> access).
>
>  
>
>  
>
>  
>
> --
> *Sunava D*utta
> Program Manager (AJAX) - Developer Experience Team, Internet Explorer
>
> One Microsoft Way, Redmond WA 98052
> TEL# (425) 705-1418
>
> FAX# (425) 936-7329
>
>  
>


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 Sunava Dutta

Adding the WAF group since they have also been working on a similar technology.

 

From: Sunava Dutta
Sent: Thursday, March 13, 2008 8:47 PM
To: Sunava Dutta; Web API WG (public)
Cc: Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
Subject: IE Team's Proposal for Cross Site Requests

 

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.

 

 

XDomainRequest (XDR)

Table of Contents

1.0   Summary

2.0   Background: Overview of how XDR allows cross site requests

3.0   API Documentation: Lists the programming interface/methods/properties

4.0   Security Model Flowchart: Highlights the security checks that IE8 makes for an XDR Request.

5.0   Sample Site and Script: For developers wishing to create an XDR page.

6.0   Developer Benefits of using XDR: Covers XDR’s strengths by demonstrating XDR’s goals of security and simplicity.

7.0   Developer Release Notes: A short bulleted list of issues developers should we aware of when using the object and a summary of what XDR cannot do.

1.0 Summary

With Cross Domain Request (XDR) developers can create cross site data aggregation scenarios. Similar to the XMLHttpRequest object  but with a simpler programming model, this request, called XDomainRequest, is an easy way to make anonymous requests to third party sites that support XDR and opt in to making their data available across domains. Three lines of code will have you making basic cross site requests. This will ensure data aggregation for public sites such as blogs etc will be simple, secure and fast. XDR is an approach designed from the grounds up with a focus on security. We understand the current cross domain XMLHTTPRequest proposal and recognize its ability to provide a broader set of services particularly around declarative auditing for access control based scenarios and authenticated connections. It does however come at the risk of more complexity and surface area of attack. While these are certainly compelling scenarios we realize that existing implementations have bugs (linked 1, 2), some of which are resolved from the past like TOUCTOU and others like DNS Rebinding remain mostly unaddressed. In addition, maintaining configuration is challenging post deployment as Flash has encountered (wildcarding) in the past. The IE team is not comfortable implementing a feature with a high surface area of attack and open/incoming security issues and proposes XDR as a safer alternative.

 

2.0 Background

 

 

Browsers enforce the same site origin policy, which blocks web pages from accessing data from another domain. Websites often work around this policy by having their server request content from another site’s server in the backend, thus circumventing the check within the browser.

 


 


 

 

 

 

 

Text Box: Figure 1 – IE7 and below need to make a request to the mashup server which then needs to be proxied to the web server.

 

In IE8 web pages can simply make a cross domain data request within the browser using the new XDomainRequest object instead of a server-to-server requests.

Cross domain requests require mutual consent between the webpage and server. You can initiate a cross domain request in your webpage by creating a xdomainrequest object off the window object and opening a connection to a particular domain. The browser will request data from the domain’s server by sending a XDomainRequest: 1 header. It will only complete the connection if the server responds with a XDomainRequestAllowed header with the value “1” for true.

 

For example, a server’s asp page includes the following response header:

Response.AppendHeader("XDomainRequestAllowed","1");

 

 

 

Security note: 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.

 


3.0 API Documentation

 

 

Methods

Once you create a xdomainrequest object, you can use the open() method to open a connection with a domain’s server. This method supports the GET and POST HTTP methods and takes the URL to connect to as a parameter. Once you’ve opened a connection, you can use the send() method to send a data string to the server for processing if needed. For example:

 

// 1. Create XDR object

xdr = new XDomainRequest();

 

//2. Open connection with server using POST method

xdr.open(“POST”, “http://www.contoso.com/xdr.txt”)

 

//3. Send string data to server

xdr.send(“data to be processed”)

 

XDR also has an abort() method to cancel an active request, which takes no parameters. Data is not available on an abort.

 

Properties

·         responseText - After the server responds, you can retrieve the data string through the read-only responseText property.

·         timeout - You can use the timeout property to set or retrieve the number of milliseconds the browser should wait for a server to respond.   IE defaults to no timeout if this property is not explicitly set. If the request times out, data is not available.

·         contentType – If you are posting data to the server, use the contentType property to define the content type string that will be sent to the server. If you are using a GET then this property will allow you to read the content type.

 

Events

XDR has the following events:

·         onerror – this event fires when there is an error and the request cannot be completed. For example, the network is not available

·         ontimeout – this event fires when the request reaches its timeout as defined by the above timeOut property. If the request times out data is not available.

·         onprogress – this event fires while the server responds to the request by streaming data back to the browser.

·         onload – this event fires when the cross domain request is complete and data is available.

 

Security note: Cross domain requests can only be sent and received from a web page to URLs in the following IE zones. We discourage Intranet sites from making XDR data available to help prevent intranet data from leaking to malicious Internet sites.

 

 

 

Webpage equests data from a URL in the following zone:

 

 

Local

Intranet

Trusted (Intranet)

Trusted (Internet)

Internet

Restricted

Webpage is in the following zone:

Local

Allow

Allow

Allow

Allow

Allow

Block

Intranet

Block

Allow

Allow

Allow

Allow

Block

Trusted (Intranet)

Block

Allow

Allow

Allow

Allow

Block

Trusted (Internet)

Block

Block

Block

Allow

Allow

Block

Internet

Block

Block

Block

Allow

Allow

Block

Restricted

Block

Block

Block

Block

Block

Block

 

Security note: When using these XDR, safely handling data provided by another web application is a critical operation.

 

For instance, the response could be parsed directly by Javascript, or it could be evaluated with a freely available JSON parser (see http://www.json.org/) or it could be inserted into a DOM as static text (using .innerText).

 

 

 

Server Side

The browser will request data from the domain’s server by sending a XDomainRequest: 1 header. It will only complete the connection if the server responds with an XDomainRequestAllowed header with the value “1” for true.

For example, a server’s asp page includes the following response header:

Response.AppendHeader("XDomainRequestAllowed","1");

This can be done in IIS, for example, using an ASP.NET page. The line of code below can be embedded in your ASP page to return the header.

 

<<% Response.AddHeader  "XDomainRequestAllowed","1" %>Data

 

 

4.0 Security Model Flowchart

XDR Flowchart

5.0 Sample Site and Script

 

Please refer to the AJAX Hands on Labs on MSDN for demo script. This will need to be set up on your machine from the resource files.

 

6.0 Other Developer Benefits of Using XDR

1.        Simple development model.

a.        On the server, the server operator must simply add one new header to his HTTP response indicating that cross-domain sources may receive the data.  HTTP Headers can be added by any CGI-style process (PHP/ASPNET/etc) or by the web server software (Apache/IIS/etc) itself.

b.        On the client, the XDR object is all about cross-domain-requests.  Because XDR is a new object we are not forced to “bolt on” cross-domain security.  For example, XDR has no means of adding a custom header, because custom headers are dangerous for cross-domain security as the current web model does not expect a custom header being sent across domains. We’ve encountered experiences when web applications in the past if encountering a custom header using XHR assume it’s coming from the same site.

 

2.        Provably secure

a.        The XDR security model is simple.  The client sends a request that clearly identifies its cross-domain nature, and the server must respond in kind for the Same-Origin-Policy to be relaxed such that the client can read the response.  If the server does not set the response header (a “non-participating” server), the client script is not permitted to read the response or determine anything about the target server.

 

b.        XDR is very tightly scoped to minimize the risk of increasing security exposure of the browser.

1.        Specifically, any request sent by XDR could also be emitted by a properly coded HTML FORM object.  Hence, any “non-participating” web server put at risk by XDR is also at risk from simple HTML.

 

Note: The only additional exposure XDR adds is the ability of the client to set a specific Content-Type header.

 

2.        As XDR strips all credentials and cookies, it prevents even less attack surface for use in a Cross-Site-Request-Forgery (CSRF) attack than a HTML Form.

 

c.        XDR attempts to block cross-zone/protocol requests, an ASR which exceeds that undertaken elsewhere in the browser (e.g. SCRIPT SRC) due to compatibility concerns.

 

3.        Improved Access  Control “Locality”

a.        Unlike policy file-based security, the XDR handshake is a part of the HTTP request and response.  This means that XDR is not at risk from DNS-Rebinding or Time-of-Check-Time-of-Use attacks.

b.        Policy files must be located in a particular location on the server, which may cause operational problems for users with limited permissions on the server.  For example, consider the shared hosting case, where only one admin may write to the server root, but many users have permissions to write to sub-folders.  The users must petition the admin for an update to the policy file.

 

4.        Access-Control Flexibility

a.        As Access-Control is based on a per-response basis, the server may choose to allow or deny access based upon any criteria desired.  For instance, Referer of client, time of day, number of requests per hour, etc, etc.

b.        The XDR security model prevents attackers from easily determining the access control rules of the server.  The server may keep their rules as a trade secret.

 

7.0 Developer Release Notes

·         Not yet available across browsers; not a W3C standard.

·         Services must be explicitly coded to operate with XDR. 

·         As HTTP Methods are deliberately limited, standard REST-based interop is not possible.

·         As credentials are not provided by the browser, the client must transmit them in the request body.  This typically should not be a problem but this could prevent use of the HttpOnly attribute on cookies that must be sent for credentials.

·         The XDR handshake is HTTP-specific and cannot be directly translated for reuse in other protocols or situations (E.g. raw socket access). 

 

 

 

--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer

One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418

FAX# (425) 936-7329

 


image001.png (41K) Download Attachment
image009.png (36K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Maciej Stachowiak
In reply to this post by Sunava Dutta

On Mar 13, 2008, at 8:46 PM, 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.


How does this compare to the Cross-Site Extensions for XMLHttpRequest standard that is being developed by Web API and Web App Formats (and as implemented in Firefox betas)? From Apple's point of view we would like to have a unified standard in this area.

Regards,
Maciej

 
 

XDomainRequest (XDR)

Table of Contents

1.0   Summary

2.0   Background: Overview of how XDR allows cross site requests

3.0   API Documentation: Lists the programming interface/methods/properties

4.0   Security Model Flowchart: Highlights the security checks that IE8 makes for an XDR Request.

5.0   Sample Site and Script: For developers wishing to create an XDR page.

6.0   Developer Benefits of using XDR: Covers XDR’s strengths by demonstrating XDR’s goals of security and simplicity.

7.0   Developer Release Notes: A short bulleted list of issues developers should we aware of when using the object and a summary of what XDR cannot do.

1.0 Summary
With Cross Domain Request (XDR) developers can create cross site data aggregation scenarios. Similar to the XMLHttpRequest object  but with a simpler programming model, this request, called XDomainRequest, is an easy way to make anonymous requests to third party sites that support XDR and opt in to making their data available across domains. Three lines of code will have you making basic cross site requests. This will ensure data aggregation for public sites such as blogs etc will be simple, secure and fast. XDR is an approach designed from the grounds up with a focus on security. We understand the current cross domain XMLHTTPRequest proposal and recognize its ability to provide a broader set of services particularly around declarative auditing for access control based scenarios and authenticated connections. It does however come at the risk of more complexity and surface area of attack. While these are certainly compelling scenarios we realize that existing implementations have bugs (linked 1, 2), some of which are resolved from the past like TOUCTOU and others like DNS Rebinding remain mostly unaddressed. In addition, maintaining configuration is challenging post deployment as Flash hasencountered (wildcarding) in the past. The IE team is not comfortable implementing a feature with a high surface area of attack and open/incoming security issues and proposes XDR as a safer alternative.
 
2.0 Background
 
 
Browsers enforce the same site origin policy, which blocks web pages from accessing data from another domain. Websites often work around this policy by having their server request content from another site’s server in the backend, thus circumventing the check within the browser.
 

 
<image002.png>

 
 
 
 
 
<image003.png>

 
In IE8 web pages can simply make a cross domain data request within the browser using the new XDomainRequest object instead of a server-to-server requests.
Cross domain requests require mutual consent between the webpage and server. You can initiate a cross domain request in your webpage by creating a xdomainrequest object off the window object and opening a connection to a particular domain. The browser will request data from the domain’s server by sending a XDomainRequest: 1 header. It will only complete the connection if the server responds with a XDomainRequestAllowed header with the value “1” for true.
 
For example, a server’s asp page includes the following response header:
Response.AppendHeader("XDomainRequestAllowed","1");
 
 
 
Security note: 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.
 
<image005.png>

3.0 API Documentation
 
 
Methods
Once you create a xdomainrequest object, you can use the open() method to open a connection with a domain’s server. This method supports the GET and POST HTTP methods and takes the URL to connect to as a parameter. Once you’ve opened a connection, you can use the send() method to send a data string to the server for processing if needed. For example:
 
// 1. Create XDR object
xdr = new XDomainRequest();
 
//2. Open connection with server using POST method
xdr.open(“POST”, “http://www.contoso.com/xdr.txt”)
 
//3. Send string data to server
xdr.send(“data to be processed”)
 
XDR also has an abort() method to cancel an active request, which takes no parameters. Data is not available on an abort.
 
Properties

·         responseText - After the server responds, you can retrieve the data string through the read-only responseText property.

·         timeout - You can use the timeout property to set or retrieve the number of milliseconds the browser should wait for a server to respond.   IE defaults to no timeout if this property is not explicitly set. If the request times out, data is not available.

·         contentType – If you are posting data to the server, use the contentType property to define the content type string that will be sent to the server. If you are using a GET then this property will allow you to read the content type.

 
Events
XDR has the following events:
·         onerror – this event fires when there is an error and the request cannot be completed. For example, the network is not available
·         ontimeout – this event fires when the request reaches its timeout as defined by the above timeOut property. If the request times out data is not available.
·         onprogress – this event fires while the server responds to the request by streaming data back to the browser.
·         onload – this event fires when the cross domain request is complete and data is available.
 
Security note: Cross domain requests can only be sent and received from a web page to URLs in the following IE zones. We discourage Intranet sites from making XDR data available to help prevent intranet data from leaking to malicious Internet sites.
 
 
 
Webpage equests data from a URL in the following zone:
 
 
Local
Intranet
Trusted (Intranet)
Trusted (Internet)
Internet
Restricted
Webpage is in the following zone:
Local
Allow
Allow
Allow
Allow
Allow
Block
Intranet
Block
Allow
Allow
Allow
Allow
Block
Trusted (Intranet)
Block
Allow
Allow
Allow
Allow
Block
Trusted (Internet)
Block
Block
Block
Allow
Allow
Block
Internet
Block
Block
Block
Allow
Allow
Block
Restricted
Block
Block
Block
Block
Block
Block
 
Security note: When using these XDR, safely handling data provided by another web application is a critical operation.
 
For instance, the response could be parsed directly by Javascript, or it could be evaluated with a freely available JSON parser (see http://www.json.org/) or it could be inserted into a DOM as static text (using .innerText).
 
 
 
Server Side
The browser will request data from the domain’s server by sending a XDomainRequest: 1 header. It will only complete the connection if the server responds with an XDomainRequestAllowed header with the value “1” for true.
For example, a server’s asp page includes the following response header:
Response.AppendHeader("XDomainRequestAllowed","1");
This can be done in IIS, for example, using an ASP.NET page. The line of code below can be embedded in your ASP page to return the header.
 
<<% Response.AddHeader  "XDomainRequestAllowed","1" %>Data
 
 
4.0 Security Model Flowchart

<image007.jpg>
5.0 Sample Site and Script
 
Please refer to the AJAX Hands on Labs on MSDN for demo script. This will need to be set up on your machine from the resource files.
 
6.0 Other Developer Benefits of Using XDR
1.        Simple development model.
a.        On the server, the server operator must simply add one new header to his HTTP response indicating that cross-domain sources may receive the data.  HTTP Headers can be added by any CGI-style process (PHP/ASPNET/etc) or by the web server software (Apache/IIS/etc) itself.
b.        On the client, the XDR object is all about cross-domain-requests.  Because XDR is a new object we are not forced to “bolt on” cross-domain security.  For example, XDR has no means of adding a custom header, because custom headers are dangerous for cross-domain security as the current web model does not expect a custom header being sent across domains. We’ve encountered experiences when web applications in the past if encountering a custom header using XHR assume it’s coming from the same site.
 
2.        Provably secure
a.        The XDR security model is simple.  The client sends a request that clearly identifies its cross-domain nature, and the server must respond in kind for the Same-Origin-Policy to be relaxed such that the client can read the response.  If the server does not set the response header (a “non-participating” server), the client script is not permitted to read the response or determine anything about the target server.
 
b.        XDR is very tightly scoped to minimize the risk of increasing security exposure of the browser.
1.        Specifically, any request sent by XDR could also be emitted by a properly coded HTML FORM object.  Hence, any “non-participating” web server put at risk by XDR is also at risk from simple HTML.
 
Note: The only additional exposure XDR adds is the ability of the client to set a specific Content-Type header.
 
2.        As XDR strips all credentials and cookies, it prevents even less attack surface for use in a Cross-Site-Request-Forgery (CSRF) attack than a HTML Form.
 
c.        XDR attempts to block cross-zone/protocol requests, an ASR which exceeds that undertaken elsewhere in the browser (e.g. SCRIPT SRC) due to compatibility concerns.
 
3.        Improved Access  Control “Locality”
a.        Unlike policy file-based security, the XDR handshake is a part of the HTTP request and response.  This means that XDR is not at risk from DNS-Rebinding orTime-of-Check-Time-of-Use attacks.
b.        Policy files must be located in a particular location on the server, which may cause operational problems for users with limited permissions on the server.  For example, consider the shared hosting case, where only one admin may write to the server root, but many users have permissions to write to sub-folders.  The users must petition the admin for an update to the policy file.
 
4.        Access-Control Flexibility
a.        As Access-Control is based on a per-response basis, the server may choose to allow or deny access based upon any criteria desired.  For instance, Referer of client, time of day, number of requests per hour, etc, etc.
b.        The XDR security model prevents attackers from easily determining the access control rules of the server.  The server may keep their rules as a trade secret.
 
7.0 Developer Release Notes
·         Not yet available across browsers; not a W3C standard.
·         Services must be explicitly coded to operate with XDR. 
·         As HTTP Methods are deliberately limited, standard REST-based interop is not possible.
·         As credentials are not provided by the browser, the client must transmit them in the request body.  This typically should not be a problem but this could prevent use of the HttpOnly attribute on cookies that must be sent for credentials.
·         The XDR handshake is HTTP-specific and cannot be directly translated for reuse in other protocols or situations (E.g. raw socket access). 
 
 
 
-- 
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer
One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418
FAX# (425) 936-7329
 

Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Laurens Holst-2
In reply to this post by Sunava Dutta
So, if I cannot set HTTP headers, how am I supposed to set an Accept
header to indicate that I e.g. want to receive application/xhtml+xml,
application/atom+xml, application/*rss*+xml, application/rdf+xml, etc.?
Your proposal is completely unfriendly to content negotiation. Also,
there are valid use cases for setting other headers.

I sincerely hope you will fix this issue by creating a blacklist of
headers instead of disallowing them entirely.

~Grauw

--
Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Laurens Holst, student, university of Utrecht, the Netherlands.
Website: www.grauw.nl. Backbase employee; www.backbase.com.


lholst.vcf (196 bytes) Download Attachment
smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Doug Schepers-3
In reply to this post by Sunava Dutta

Hi, Sunava-

Could you please resend this as an HTML attachment, rather than as the
body of the email?  Many people use text-based email clients (I myself
normally view emails as text-only, though I can switch on HTML), making
this very hard to read.  It also looks crummy in the archives:

   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0096.html

Thanks-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI

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 Jonas Sicking-2

Also, if you do have reliable definitions of the
"Intranet"/"Internet"/"Restricted" zones, what is the purpose of the
XDomainRequestAllowed header since presumably all servers in a zone
could just read data directly from each other without regard for the
XDomainRequestAllowed header.

/ Jonas

Jonas Sicking wrote:

>
> How do you define the "Intranet", "Internet", "Restricted" etc zones?
> Without correct definitions for these zones it seems possible to attack
> intranet servers by sending unsafe (such as POST or DELETE) requests to
> intranet servers from internet pages.
>
> I'd also recommend sending this to the web applications formats group
> since they have been working on a very similar security proposal.
>
> / Jonas
>
> 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.
>>
>>  
>>
>>  
>>
>> XDomainRequest (XDR)
>>
>>
>>     Table of Contents
>>
>> 1.0   Summary
>>
>> 2.0   Background: /Overview of how XDR allows cross site requests/
>>
>> 3.0   API Documentation: /Lists the programming
>> interface/methods/properties/
>>
>> 4.0   Security Model Flowchart: /Highlights the security checks that
>> IE8 makes for an XDR Request./
>>
>> 5.0   Sample Site and Script: /For developers wishing to create an XDR
>> page./
>>
>> 6.0   Developer Benefits of using XDR: /Covers XDR’s strengths by
>> demonstrating XDR’s goals of security and simplicity./
>>
>> 7.0   Developer Release Notes: /A short bulleted list of issues
>> developers should we aware of when using the object and a summary of
>> what XDR cannot do./
>>
>> 1.0 Summary
>>
>> /With* Cross Domain Request* *(XDR)* developers can create cross site
>> data aggregation scenarios. Similar to the XMLHttpRequest object  but
>> with a simpler programming model, this request, called XDomainRequest,
>> is an easy way to make anonymous requests to third party sites that
>> support XDR and opt in to making their data available across domains.
>> Three lines of code will have you making basic cross site requests.
>> This will ensure data aggregation for public sites such as blogs etc
>> will be simple, secure and fast. XDR is an approach designed from the
>> grounds up with a focus on security. We understand the current cross
>> domain XMLHTTPRequest proposal and recognize its ability to provide a
>> broader set of services particularly around declarative auditing for
>> access control based scenarios and authenticated connections. It does
>> however come at the risk of more complexity and surface area of
>> attack. While these are certainly compelling scenarios we realize that
>> existing implementations have bugs (linked 1
>> <http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html>,
>> 2 <https://bugzilla.mozilla.org/show_bug.cgi?id=389508>), some of
>> which are resolved from the past like TOUCTOU and others like DNS
>> Rebinding remain mostly unaddressed. In addition, maintaining
>> configuration is challenging post deployment as Flash has encountered
>> <http://blog.monstuff.com/archives/000302.html> (wildcarding) in the
>> past. The IE team is not comfortable implementing a feature with a
>> high surface area of attack and open/incoming security issues and
>> proposes XDR as a safer alternative.///
>>
>>  
>>
>> 2.0 Background
>>
>>  
>>
>>  
>>
>> Browsers enforce the same site origin policy, which blocks web pages
>> from accessing data from another domain. Websites often work around
>> this policy by having their server request content from another site’s
>> server in the backend, thus circumventing the check within the browser.
>>
>>  
>>
>>
>>  
>>
>>    
>>
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>  
>>
>>     Text Box: Figure 1 – IE7 and below need to make a request to the
>> mashup server which then needs to be proxied to the web server.
>>
>>
>>  
>>
>> In IE8 web pages can simply make a cross domain data request within
>> the browser using the new /XDomainRequest/ object instead of a
>> server-to-server requests.
>>
>> Cross domain requests require mutual consent between the webpage and
>> server. You can initiate a cross domain request in your webpage by
>> creating a /xdomainrequest /object off the window object and opening a
>> connection to a particular domain. The browser will request data from
>> the domain’s server by sending a /XDomainRequest: 1 /header. It will
>> only complete the connection if the server responds with a
>> XDomainRequestAllowed header with the value “1” for true.
>>
>>  
>>
>> For example, a server’s asp page includes the following response header:
>>
>> Response.AppendHeader("XDomainRequestAllowed","1");
>>
>>  
>>
>>  
>>
>>  
>>
>> *Security note: *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.
>>
>>  
>>
>>    
>>
>>
>> 3.0 API Documentation
>>
>>  
>>
>> * *
>>
>> *Methods*
>>
>> Once you create a xdomainrequest object, you can use the /open()/
>> method to open a connection with a domain’s server. This method
>> supports the GET and POST HTTP methods and takes the URL to connect to
>> as a parameter. Once you’ve opened a connection, you can use the
>> /send()/ method to send a data string to the server for processing if
>> needed. For example:
>>
>>  
>>
>> // 1. Create XDR object
>>
>> xdr = new XDomainRequest();
>>
>>  
>>
>> //2. Open connection with server using POST method
>>
>> xdr.open(“POST”, “http://www.contoso.com/xdr.txt”)
>>
>>  
>>
>> //3. Send string data to server
>>
>> xdr.send(“data to be processed”)
>>
>>  
>>
>> XDR also has an /abort() /method to cancel an active request, which
>> takes no parameters. Data is not available on an abort.
>>
>> * *
>>
>> *Properties*
>>
>> ·         *responseText - *After the server responds, you can retrieve
>> the data string through the read-only /responseText /property.
>>
>> ·         *timeout - *You can use the /timeout /property to set or
>> retrieve the number of milliseconds the browser should wait for a
>> server to respond.   IE defaults to no timeout if this property is not
>> explicitly set. If the request times out, data is not available.
>>
>> ·         *contentType *– If you are posting data to the server, use
>> the /contentType /property to define the content type string that will
>> be sent to the server. If you are using a GET then this property will
>> allow you to read the content type.
>>
>>  
>>
>> *Events*
>>
>> XDR has the following events:
>>
>> ·         *onerror* – this event fires when there is an error and the
>> request cannot be completed. For example, the network is not available
>>
>> ·         *ontimeout *– this event fires when the request reaches its
>> timeout as defined by the above timeOut property. If the request times
>> out data is not available.
>>
>> ·         *onprogress –* this event fires while the server responds to
>> the request by streaming data back to the browser.
>>
>> ·         *onload *– this event fires when the cross domain request is
>> complete and data is available.
>>
>>  
>>
>> *Security note: *Cross domain requests can only be sent and received
>> from a web page to URLs in the following IE zones. We discourage
>> Intranet sites from making XDR data available to help prevent intranet
>> data from leaking to malicious Internet sites.
>>
>>  
>>
>>  
>>
>>    
>>
>>  
>>
>>    
>>
>> *Webpage equests data from a URL in the following zone:*
>>
>>  
>>
>>    
>>
>>  
>>
>>    
>>
>> Local
>>
>>    
>>
>> Intranet
>>
>>    
>>
>> Trusted (Intranet)
>>
>>    
>>
>> Trusted (Internet)
>>
>>    
>>
>> Internet
>>
>>    
>>
>> Restricted
>>
>> *Webpage is in the following zone:*
>>
>>    
>>
>> Local
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Block
>>
>> Intranet
>>
>>    
>>
>> Block
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Block
>>
>> Trusted (Intranet)
>>
>>    
>>
>> Block
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Block
>>
>> Trusted (Internet)
>>
>>    
>>
>> Block
>>
>>    
>>
>> Block
>>
>>    
>>
>> Block
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Block
>>
>> Internet
>>
>>    
>>
>> Block
>>
>>    
>>
>> Block
>>
>>    
>>
>> Block
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Allow
>>
>>    
>>
>> Block
>>
>> Restricted
>>
>>    
>>
>> Block
>>
>>    
>>
>> Block
>>
>>    
>>
>> Block
>>
>>    
>>
>> Block
>>
>>    
>>
>> Block
>>
>>    
>>
>> Block
>>
>> * *
>>
>> *Security note: *When using these XDR, safely handling data provided
>> by another web application is a critical operation.
>>
>>  
>>
>> For instance, the response could be parsed directly by Javascript, or
>> it could be evaluated with a freely available JSON parser (see
>> http://www.json.org/) or it could be inserted into a DOM as static
>> text (using .innerText).
>>
>> * *
>>
>> * *
>>
>> * *
>>
>> *Server Side*
>>
>> The browser will request data from the domain’s server by sending a
>> /XDomainRequest: 1 /header. It will only complete the connection if
>> the server responds with an XDomainRequestAllowed header with the
>> value “1” for true.
>>
>> For example, a server’s asp page includes the following response header:
>>
>> *Response.AppendHeader("XDomainRequestAllowed","1");*
>>
>> This can be done in IIS, for example, using an ASP.NET page. The line
>> of code below can be embedded in your ASP page to return the header.
>>
>>  
>>
>> *<<% Response.AddHeader  "XDomainRequestAllowed","1" %>Data*
>>
>> * *
>>
>> * *
>>
>> 4.0 Security Model Flowchart
>>
>> XDR Flowchart
>>
>> 5.0 Sample Site and Script
>>
>>  
>>
>> Please refer to the AJAX Hands on Labs
>> <http://code.msdn.microsoft.com/iemix08labs/Release/ProjectReleases.aspx?ReleaseId=590>
>> on MSDN for demo script. This will need to be set up on your machine
>> from the resource files.
>>
>>  
>>
>> 6.0 Other Developer Benefits of Using XDR
>>
>> 1.        Simple development model.
>>
>> a.        On the server, the server operator must simply add one new
>> header to his HTTP response indicating that cross-domain sources may
>> receive the data.  HTTP Headers can be added by any CGI-style process
>> (PHP/ASPNET/etc) or by the web server software (Apache/IIS/etc) itself.
>>
>> b.        On the client, the XDR object is all about
>> cross-domain-requests.  Because XDR is a new object we are not forced
>> to “bolt on” cross-domain security.  For example, XDR has no means of
>> adding a custom header, because custom headers are dangerous for
>> cross-domain security as the current web model does not expect a
>> custom header being sent across domains. We’ve encountered experiences
>> when web applications in the past if encountering a custom header
>> using XHR assume it’s coming from the same site.
>>
>>  
>>
>> 2.        Provably secure
>>
>> a.        The XDR security model is simple.  The client sends a
>> request that clearly identifies its cross-domain nature, and the
>> server must respond in kind for the Same-Origin-Policy to be relaxed
>> such that the client can read the response.  If the server does not
>> set the response header (a “non-participating” server), the client
>> script is not permitted to read the response or determine anything
>> about the target server.
>>
>>  
>>
>> b.        XDR is very tightly scoped to minimize the risk of
>> increasing security exposure of the browser.
>>
>> 1.        Specifically, any request sent by XDR could also be emitted
>> by a properly coded HTML FORM object.  Hence, any “non-participating”
>> web server put at risk by XDR is also at risk from simple HTML.
>>
>>  
>>
>> Note: The only additional exposure XDR adds is the ability of the
>> client to set a specific Content-Type header.
>>
>>  
>>
>> 2.        As XDR strips all credentials and cookies, it prevents even
>> less attack surface for use in a Cross-Site-Request-Forgery (CSRF)
>> <http://en.wikipedia.org/wiki/Cross-site_request_forgery> attack than
>> a HTML Form.
>>
>>  
>>
>> c.        XDR attempts to block cross-zone/protocol requests, an ASR
>> which exceeds that undertaken elsewhere in the browser (e.g. SCRIPT
>> SRC) due to compatibility concerns.
>>
>>  
>>
>> 3.        Improved Access  Control “Locality”
>>
>> a.        Unlike policy file-based security, the XDR handshake is a
>> part of the HTTP request and response.  This means that XDR is not at
>> risk from DNS-Rebinding <http://en.wikipedia.org/wiki/DNS_rebinding>
>> or Time-of-Check-Time-of-Use
>> <http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use> attacks.
>>
>> b.        Policy files must be located in a particular location on the
>> server, which may cause operational problems for users with limited
>> permissions on the server.  For example, consider the shared hosting
>> case, where only one admin may write to the server root, but many
>> users have permissions to write to sub-folders.  The users must
>> petition the admin for an update to the policy file.
>>
>>  
>>
>> 4.        Access-Control Flexibility
>>
>> a.        As Access-Control is based on a per-response basis, the
>> server may choose to allow or deny access based upon any criteria
>> desired.  For instance, Referer of client, time of day, number of
>> requests per hour, etc, etc.
>>
>> b.        The XDR security model prevents attackers from easily
>> determining the access control rules of the server.  The server may
>> keep their rules as a trade secret.
>>
>>  
>>
>> 7.0 Developer Release Notes
>>
>> ·         Not yet available across browsers; not a W3C standard.
>>
>> ·         Services must be explicitly coded to operate with XDR.
>> ·         As HTTP Methods are deliberately limited, standard
>> REST-based interop is not possible.
>>
>> ·         As credentials are not provided by the browser, the client
>> must transmit them in the request body.  This typically should not be
>> a problem but this could prevent use of the HttpOnly attribute on
>> cookies that must be sent for credentials.
>>
>> ·         The XDR handshake is HTTP-specific and cannot be directly
>> translated for reuse in other protocols or situations (E.g. raw socket
>> access).
>>  
>>
>>  
>>
>>  
>>
>> --
>> *Sunava D*utta
>> Program Manager (AJAX) - Developer Experience Team, Internet Explorer
>>
>> One Microsoft Way, Redmond WA 98052
>> TEL# (425) 705-1418
>>
>> FAX# (425) 936-7329
>>
>>  
>>
>
>


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

I’d move half the summary section up front to make it clear why we’re not wild about x-domain XHR.  You need to lead with that.

 

From: Sunava Dutta
Sent: Thursday, March 13, 2008 8:47 PM
To: Sunava Dutta; Web API WG (public)
Cc: Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
Subject: IE Team's Proposal for Cross Site Requests

 

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.

 

 

XDomainRequest (XDR)

Table of Contents

1.0   Summary

2.0   Background: Overview of how XDR allows cross site requests

3.0   API Documentation: Lists the programming interface/methods/properties

4.0   Security Model Flowchart: Highlights the security checks that IE8 makes for an XDR Request.

5.0   Sample Site and Script: For developers wishing to create an XDR page.

6.0   Developer Benefits of using XDR: Covers XDR’s strengths by demonstrating XDR’s goals of security and simplicity.

7.0   Developer Release Notes: A short bulleted list of issues developers should we aware of when using the object and a summary of what XDR cannot do.

1.0 Summary

With Cross Domain Request (XDR) developers can create cross site data aggregation scenarios. Similar to the XMLHttpRequest object  but with a simpler programming model, this request, called XDomainRequest, is an easy way to make anonymous requests to third party sites that support XDR and opt in to making their data available across domains. Three lines of code will have you making basic cross site requests. This will ensure data aggregation for public sites such as blogs etc will be simple, secure and fast. XDR is an approach designed from the grounds up with a focus on security. We understand the current cross domain XMLHTTPRequest proposal and recognize its ability to provide a broader set of services particularly around declarative auditing for access control based scenarios and authenticated connections. It does however come at the risk of more complexity and surface area of attack. While these are certainly compelling scenarios we realize that existing implementations have bugs (linked 1, 2), some of which are resolved from the past like TOUCTOU and others like DNS Rebinding remain mostly unaddressed. In addition, maintaining configuration is challenging post deployment as Flash has encountered (wildcarding) in the past. The IE team is not comfortable implementing a feature with a high surface area of attack and open/incoming security issues and proposes XDR as a safer alternative.

 

2.0 Background

 

 

Browsers enforce the same site origin policy, which blocks web pages from accessing data from another domain. Websites often work around this policy by having their server request content from another site’s server in the backend, thus circumventing the check within the browser.

 


 


 

 

 

 

 

Text Box: Figure 1 – IE7 and below need to make a request to the mashup server which then needs to be proxied to the web server.

 

In IE8 web pages can simply make a cross domain data request within the browser using the new XDomainRequest object instead of a server-to-server requests.

Cross domain requests require mutual consent between the webpage and server. You can initiate a cross domain request in your webpage by creating a xdomainrequest object off the window object and opening a connection to a particular domain. The browser will request data from the domain’s server by sending a XDomainRequest: 1 header. It will only complete the connection if the server responds with a XDomainRequestAllowed header with the value “1” for true.

 

For example, a server’s asp page includes the following response header:

Response.AppendHeader("XDomainRequestAllowed","1");

 

 

 

Security note: 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.

 


3.0 API Documentation

 

 

Methods

Once you create a xdomainrequest object, you can use the open() method to open a connection with a domain’s server. This method supports the GET and POST HTTP methods and takes the URL to connect to as a parameter. Once you’ve opened a connection, you can use the send() method to send a data string to the server for processing if needed. For example:

 

// 1. Create XDR object

xdr = new XDomainRequest();

 

//2. Open connection with server using POST method

xdr.open(“POST”, “http://www.contoso.com/xdr.txt”)

 

//3. Send string data to server

xdr.send(“data to be processed”)

 

XDR also has an abort() method to cancel an active request, which takes no parameters. Data is not available on an abort.

 

Properties

·         responseText - After the server responds, you can retrieve the data string through the read-only responseText property.

·         timeout - You can use the timeout property to set or retrieve the number of milliseconds the browser should wait for a server to respond.   IE defaults to no timeout if this property is not explicitly set. If the request times out, data is not available.

·         contentType – If you are posting data to the server, use the contentType property to define the content type string that will be sent to the server. If you are using a GET then this property will allow you to read the content type.

 

Events

XDR has the following events:

·         onerror – this event fires when there is an error and the request cannot be completed. For example, the network is not available

·         ontimeout – this event fires when the request reaches its timeout as defined by the above timeOut property. If the request times out data is not available.

·         onprogress – this event fires while the server responds to the request by streaming data back to the browser.

·         onload – this event fires when the cross domain request is complete and data is available.

 

Security note: Cross domain requests can only be sent and received from a web page to URLs in the following IE zones. We discourage Intranet sites from making XDR data available to help prevent intranet data from leaking to malicious Internet sites.

 

 

 

Webpage equests data from a URL in the following zone:

 

 

Local

Intranet

Trusted (Intranet)

Trusted (Internet)

Internet

Restricted

Webpage is in the following zone:

Local

Allow

Allow

Allow

Allow

Allow

Block

Intranet

Block

Allow

Allow

Allow

Allow

Block

Trusted (Intranet)

Block

Allow

Allow

Allow

Allow

Block

Trusted (Internet)

Block

Block

Block

Allow

Allow

Block

Internet

Block

Block

Block

Allow

Allow

Block

Restricted

Block

Block

Block

Block

Block

Block

 

Security note: When using these XDR, safely handling data provided by another web application is a critical operation.

 

For instance, the response could be parsed directly by Javascript, or it could be evaluated with a freely available JSON parser (see http://www.json.org/) or it could be inserted into a DOM as static text (using .innerText).

 

 

 

Server Side

The browser will request data from the domain’s server by sending a XDomainRequest: 1 header. It will only complete the connection if the server responds with an XDomainRequestAllowed header with the value “1” for true.

For example, a server’s asp page includes the following response header:

Response.AppendHeader("XDomainRequestAllowed","1");

This can be done in IIS, for example, using an ASP.NET page. The line of code below can be embedded in your ASP page to return the header.

 

<<% Response.AddHeader  "XDomainRequestAllowed","1" %>Data

 

 

4.0 Security Model Flowchart

XDR Flowchart

5.0 Sample Site and Script

 

Please refer to the AJAX Hands on Labs on MSDN for demo script. This will need to be set up on your machine from the resource files.

 

6.0 Other Developer Benefits of Using XDR

1.        Simple development model.

a.        On the server, the server operator must simply add one new header to his HTTP response indicating that cross-domain sources may receive the data.  HTTP Headers can be added by any CGI-style process (PHP/ASPNET/etc) or by the web server software (Apache/IIS/etc) itself.

b.        On the client, the XDR object is all about cross-domain-requests.  Because XDR is a new object we are not forced to “bolt on” cross-domain security.  For example, XDR has no means of adding a custom header, because custom headers are dangerous for cross-domain security as the current web model does not expect a custom header being sent across domains. We’ve encountered experiences when web applications in the past if encountering a custom header using XHR assume it’s coming from the same site.

 

2.        Provably secure

a.        The XDR security model is simple.  The client sends a request that clearly identifies its cross-domain nature, and the server must respond in kind for the Same-Origin-Policy to be relaxed such that the client can read the response.  If the server does not set the response header (a “non-participating” server), the client script is not permitted to read the response or determine anything about the target server.

 

b.        XDR is very tightly scoped to minimize the risk of increasing security exposure of the browser.

1.        Specifically, any request sent by XDR could also be emitted by a properly coded HTML FORM object.  Hence, any “non-participating” web server put at risk by XDR is also at risk from simple HTML.

 

Note: The only additional exposure XDR adds is the ability of the client to set a specific Content-Type header.

 

2.        As XDR strips all credentials and cookies, it prevents even less attack surface for use in a Cross-Site-Request-Forgery (CSRF) attack than a HTML Form.

 

c.        XDR attempts to block cross-zone/protocol requests, an ASR which exceeds that undertaken elsewhere in the browser (e.g. SCRIPT SRC) due to compatibility concerns.

 

3.        Improved Access  Control “Locality”

a.        Unlike policy file-based security, the XDR handshake is a part of the HTTP request and response.  This means that XDR is not at risk from DNS-Rebinding or Time-of-Check-Time-of-Use attacks.

b.        Policy files must be located in a particular location on the server, which may cause operational problems for users with limited permissions on the server.  For example, consider the shared hosting case, where only one admin may write to the server root, but many users have permissions to write to sub-folders.  The users must petition the admin for an update to the policy file.

 

4.        Access-Control Flexibility

a.        As Access-Control is based on a per-response basis, the server may choose to allow or deny access based upon any criteria desired.  For instance, Referer of client, time of day, number of requests per hour, etc, etc.

b.        The XDR security model prevents attackers from easily determining the access control rules of the server.  The server may keep their rules as a trade secret.

 

7.0 Developer Release Notes

·         Not yet available across browsers; not a W3C standard.

·         Services must be explicitly coded to operate with XDR. 

·         As HTTP Methods are deliberately limited, standard REST-based interop is not possible.

·         As credentials are not provided by the browser, the client must transmit them in the request body.  This typically should not be a problem but this could prevent use of the HttpOnly attribute on cookies that must be sent for credentials.

·         The XDR handshake is HTTP-specific and cannot be directly translated for reuse in other protocols or situations (E.g. raw socket access). 

 

 

 

--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer

One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418

FAX# (425) 936-7329

 


image001.png (41K) Download Attachment
image009.png (36K) Download Attachment
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

Oops.  Obviously, this was not to go to the whole group.

 

I’ve been asked a lot, over the last week and a half, why we implemented XDR rather than the current cross-domain XHR proposals.  The short version is, as Sunava discusses in the summary of this mail, that x-domain XHR (and Flash’s approach, et al) is subject to specific x-domain injection attacks because of its persistent-allow design.

 

From: Chris Wilson
Sent: Friday, March 14, 2008 11:00 AM
To: Sunava Dutta; Web API WG (public)
Cc: Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
Subject: RE: IE Team's Proposal for Cross Site Requests

 

I’d move half the summary section up front to make it clear why we’re not wild about x-domain XHR.  You need to lead with that.

 

From: Sunava Dutta
Sent: Thursday, March 13, 2008 8:47 PM
To: Sunava Dutta; Web API WG (public)
Cc: Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
Subject: IE Team's Proposal for Cross Site Requests

 

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.

 

 

XDomainRequest (XDR)

Table of Contents

1.0   Summary

2.0   Background: Overview of how XDR allows cross site requests

3.0   API Documentation: Lists the programming interface/methods/properties

4.0   Security Model Flowchart: Highlights the security checks that IE8 makes for an XDR Request.

5.0   Sample Site and Script: For developers wishing to create an XDR page.

6.0   Developer Benefits of using XDR: Covers XDR’s strengths by demonstrating XDR’s goals of security and simplicity.

7.0   Developer Release Notes: A short bulleted list of issues developers should we aware of when using the object and a summary of what XDR cannot do.

1.0 Summary

With Cross Domain Request (XDR) developers can create cross site data aggregation scenarios. Similar to the XMLHttpRequest object  but with a simpler programming model, this request, called XDomainRequest, is an easy way to make anonymous requests to third party sites that support XDR and opt in to making their data available across domains. Three lines of code will have you making basic cross site requests. This will ensure data aggregation for public sites such as blogs etc will be simple, secure and fast. XDR is an approach designed from the grounds up with a focus on security. We understand the current cross domain XMLHTTPRequest proposal and recognize its ability to provide a broader set of services particularly around declarative auditing for access control based scenarios and authenticated connections. It does however come at the risk of more complexity and surface area of attack. While these are certainly compelling scenarios we realize that existing implementations have bugs (linked 1, 2), some of which are resolved from the past like TOUCTOU and others like DNS Rebinding remain mostly unaddressed. In addition, maintaining configuration is challenging post deployment as Flash has encountered (wildcarding) in the past. The IE team is not comfortable implementing a feature with a high surface area of attack and open/incoming security issues and proposes XDR as a safer alternative.

 

2.0 Background

 

 

Browsers enforce the same site origin policy, which blocks web pages from accessing data from another domain. Websites often work around this policy by having their server request content from another site’s server in the backend, thus circumventing the check within the browser.

 


 


 

 

 

 

 

Text Box: Figure 1 – IE7 and below need to make a request to the mashup server which then needs to be proxied to the web server.

 

In IE8 web pages can simply make a cross domain data request within the browser using the new XDomainRequest object instead of a server-to-server requests.

Cross domain requests require mutual consent between the webpage and server. You can initiate a cross domain request in your webpage by creating a xdomainrequest object off the window object and opening a connection to a particular domain. The browser will request data from the domain’s server by sending a XDomainRequest: 1 header. It will only complete the connection if the server responds with a XDomainRequestAllowed header with the value “1” for true.

 

For example, a server’s asp page includes the following response header:

Response.AppendHeader("XDomainRequestAllowed","1");

 

 

 

Security note: 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.

 


3.0 API Documentation

 

 

Methods

Once you create a xdomainrequest object, you can use the open() method to open a connection with a domain’s server. This method supports the GET and POST HTTP methods and takes the URL to connect to as a parameter. Once you’ve opened a connection, you can use the send() method to send a data string to the server for processing if needed. For example:

 

// 1. Create XDR object

xdr = new XDomainRequest();

 

//2. Open connection with server using POST method

xdr.open(“POST”, “http://www.contoso.com/xdr.txt”)

 

//3. Send string data to server

xdr.send(“data to be processed”)

 

XDR also has an abort() method to cancel an active request, which takes no parameters. Data is not available on an abort.

 

Properties

·         responseText - After the server responds, you can retrieve the data string through the read-only responseText property.

·         timeout - You can use the timeout property to set or retrieve the number of milliseconds the browser should wait for a server to respond.   IE defaults to no timeout if this property is not explicitly set. If the request times out, data is not available.

·         contentType – If you are posting data to the server, use the contentType property to define the content type string that will be sent to the server. If you are using a GET then this property will allow you to read the content type.

 

Events

XDR has the following events:

·         onerror – this event fires when there is an error and the request cannot be completed. For example, the network is not available

·         ontimeout – this event fires when the request reaches its timeout as defined by the above timeOut property. If the request times out data is not available.

·         onprogress – this event fires while the server responds to the request by streaming data back to the browser.

·         onload – this event fires when the cross domain request is complete and data is available.

 

Security note: Cross domain requests can only be sent and received from a web page to URLs in the following IE zones. We discourage Intranet sites from making XDR data available to help prevent intranet data from leaking to malicious Internet sites.

 

 

 

Webpage equests data from a URL in the following zone:

 

 

Local

Intranet

Trusted (Intranet)

Trusted (Internet)

Internet

Restricted

Webpage is in the following zone:

Local

Allow

Allow

Allow

Allow

Allow

Block

Intranet

Block

Allow

Allow

Allow

Allow

Block

Trusted (Intranet)

Block

Allow

Allow

Allow

Allow

Block

Trusted (Internet)

Block

Block

Block

Allow

Allow

Block

Internet

Block

Block

Block

Allow

Allow

Block

Restricted

Block

Block

Block

Block

Block

Block

 

Security note: When using these XDR, safely handling data provided by another web application is a critical operation.

 

For instance, the response could be parsed directly by Javascript, or it could be evaluated with a freely available JSON parser (see http://www.json.org/) or it could be inserted into a DOM as static text (using .innerText).

 

 

 

Server Side

The browser will request data from the domain’s server by sending a XDomainRequest: 1 header. It will only complete the connection if the server responds with an XDomainRequestAllowed header with the value “1” for true.

For example, a server’s asp page includes the following response header:

Response.AppendHeader("XDomainRequestAllowed","1");

This can be done in IIS, for example, using an ASP.NET page. The line of code below can be embedded in your ASP page to return the header.

 

<<% Response.AddHeader  "XDomainRequestAllowed","1" %>Data

 

 

4.0 Security Model Flowchart

XDR Flowchart

5.0 Sample Site and Script

 

Please refer to the AJAX Hands on Labs on MSDN for demo script. This will need to be set up on your machine from the resource files.

 

6.0 Other Developer Benefits of Using XDR

1.        Simple development model.

a.        On the server, the server operator must simply add one new header to his HTTP response indicating that cross-domain sources may receive the data.  HTTP Headers can be added by any CGI-style process (PHP/ASPNET/etc) or by the web server software (Apache/IIS/etc) itself.

b.        On the client, the XDR object is all about cross-domain-requests.  Because XDR is a new object we are not forced to “bolt on” cross-domain security.  For example, XDR has no means of adding a custom header, because custom headers are dangerous for cross-domain security as the current web model does not expect a custom header being sent across domains. We’ve encountered experiences when web applications in the past if encountering a custom header using XHR assume it’s coming from the same site.

 

2.        Provably secure

a.        The XDR security model is simple.  The client sends a request that clearly identifies its cross-domain nature, and the server must respond in kind for the Same-Origin-Policy to be relaxed such that the client can read the response.  If the server does not set the response header (a “non-participating” server), the client script is not permitted to read the response or determine anything about the target server.

 

b.        XDR is very tightly scoped to minimize the risk of increasing security exposure of the browser.

1.        Specifically, any request sent by XDR could also be emitted by a properly coded HTML FORM object.  Hence, any “non-participating” web server put at risk by XDR is also at risk from simple HTML.

 

Note: The only additional exposure XDR adds is the ability of the client to set a specific Content-Type header.

 

2.        As XDR strips all credentials and cookies, it prevents even less attack surface for use in a Cross-Site-Request-Forgery (CSRF) attack than a HTML Form.

 

c.        XDR attempts to block cross-zone/protocol requests, an ASR which exceeds that undertaken elsewhere in the browser (e.g. SCRIPT SRC) due to compatibility concerns.

 

3.        Improved Access  Control “Locality”

a.        Unlike policy file-based security, the XDR handshake is a part of the HTTP request and response.  This means that XDR is not at risk from DNS-Rebinding or Time-of-Check-Time-of-Use attacks.

b.        Policy files must be located in a particular location on the server, which may cause operational problems for users with limited permissions on the server.  For example, consider the shared hosting case, where only one admin may write to the server root, but many users have permissions to write to sub-folders.  The users must petition the admin for an update to the policy file.

 

4.        Access-Control Flexibility

a.        As Access-Control is based on a per-response basis, the server may choose to allow or deny access based upon any criteria desired.  For instance, Referer of client, time of day, number of requests per hour, etc, etc.

b.        The XDR security model prevents attackers from easily determining the access control rules of the server.  The server may keep their rules as a trade secret.

 

7.0 Developer Release Notes

·         Not yet available across browsers; not a W3C standard.

·         Services must be explicitly coded to operate with XDR. 

·         As HTTP Methods are deliberately limited, standard REST-based interop is not possible.

·         As credentials are not provided by the browser, the client must transmit them in the request body.  This typically should not be a problem but this could prevent use of the HttpOnly attribute on cookies that must be sent for credentials.

·         The XDR handshake is HTTP-specific and cannot be directly translated for reuse in other protocols or situations (E.g. raw socket access). 

 

 

 

--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer

One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418

FAX# (425) 936-7329

 


~WRD000.jpg (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Jonas Sicking-2

Can you describe what you mean by "persistent allow" design?

/ Jonas

Chris Wilson wrote:

> Oops.  Obviously, this was not to go to the whole group.
>
>  
>
> I’ve been asked a lot, over the last week and a half, why we implemented
> XDR rather than the current cross-domain XHR proposals.  The short
> version is, as Sunava discusses in the summary of this mail, that
> x-domain XHR (and Flash’s approach, et al) is subject to specific
> x-domain injection attacks because of its persistent-allow design.
>
>  
>
> *From:* Chris Wilson
> *Sent:* Friday, March 14, 2008 11:00 AM
> *To:* Sunava Dutta; Web API WG (public)
> *Cc:* Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug
> Stamper; Marc Silbey
> *Subject:* RE: IE Team's Proposal for Cross Site Requests
>
>  
>
> I’d move half the summary section up front to make it clear why we’re
> not wild about x-domain XHR.  You need to lead with that.
>
>  
>
> *From:* Sunava Dutta
> *Sent:* Thursday, March 13, 2008 8:47 PM
> *To:* Sunava Dutta; Web API WG (public)
> *Cc:* Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath
> Udupa; Doug Stamper; Marc Silbey
> *Subject:* IE Team's Proposal for Cross Site Requests
>
>  
>
> 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.
>
>  
>
>  
>
> XDomainRequest (XDR)
>
>
>     Table of Contents
>
> 1.0   Summary
>
> 2.0   Background: /Overview of how XDR allows cross site requests/
>
> 3.0   API Documentation: /Lists the programming
> interface/methods/properties/
>
> 4.0   Security Model Flowchart: /Highlights the security checks that IE8
> makes for an XDR Request./
>
> 5.0   Sample Site and Script: /For developers wishing to create an XDR
> page./
>
> 6.0   Developer Benefits of using XDR: /Covers XDR’s strengths by
> demonstrating XDR’s goals of security and simplicity./
>
> 7.0   Developer Release Notes: /A short bulleted list of issues
> developers should we aware of when using the object and a summary of
> what XDR cannot do./
>
> 1.0 Summary
>
> /With* Cross Domain Request* *(XDR)* developers can create cross site
> data aggregation scenarios. Similar to the XMLHttpRequest object  but
> with a simpler programming model, this request, called XDomainRequest,
> is an easy way to make anonymous requests to third party sites that
> support XDR and opt in to making their data available across domains.
> Three lines of code will have you making basic cross site requests. This
> will ensure data aggregation for public sites such as blogs etc will be
> simple, secure and fast. XDR is an approach designed from the grounds up
> with a focus on security. We understand the current cross domain
> XMLHTTPRequest proposal and recognize its ability to provide a broader
> set of services particularly around declarative auditing for access
> control based scenarios and authenticated connections. It does however
> come at the risk of more complexity and surface area of attack. While
> these are certainly compelling scenarios we realize that existing
> implementations have bugs (linked 1
> <http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html>,
> 2 <https://bugzilla.mozilla.org/show_bug.cgi?id=389508>), some of which
> are resolved from the past like TOUCTOU and others like DNS Rebinding
> remain mostly unaddressed. In addition, maintaining configuration is
> challenging post deployment as Flash has encountered
> <http://blog.monstuff.com/archives/000302.html> (wildcarding) in the
> past. The IE team is not comfortable implementing a feature with a high
> surface area of attack and open/incoming security issues and proposes
> XDR as a safer alternative.///
>
>  
>
> 2.0 Background
>
>  
>
>  
>
> Browsers enforce the same site origin policy, which blocks web pages
> from accessing data from another domain. Websites often work around this
> policy by having their server request content from another site’s server
> in the backend, thus circumventing the check within the browser.
>
>  
>
>
>  
>
>
>
>
>  
>
>  
>
>  
>
>  
>
>  
>
> Text Box: Figure 1 – IE7 and below need to make a request to the mashup
> server which then needs to be proxied to the web server.
>
>
>  
>
> In IE8 web pages can simply make a cross domain data request within the
> browser using the new /XDomainRequest/ object instead of a
> server-to-server requests.
>
> Cross domain requests require mutual consent between the webpage and
> server. You can initiate a cross domain request in your webpage by
> creating a /xdomainrequest /object off the window object and opening a
> connection to a particular domain. The browser will request data from
> the domain’s server by sending a /XDomainRequest: 1 /header. It will
> only complete the connection if the server responds with a
> XDomainRequestAllowed header with the value “1” for true.
>
>  
>
> For example, a server’s asp page includes the following response header:
>
> Response.AppendHeader("XDomainRequestAllowed","1");
>
>  
>
>  
>
>  
>
> *Security note: *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.
>
>  
>
>
>
>
> 3.0 API Documentation
>
>  
>
> * *
>
> *Methods*
>
> Once you create a xdomainrequest object, you can use the /open()/ method
> to open a connection with a domain’s server. This method supports the
> GET and POST HTTP methods and takes the URL to connect to as a
> parameter. Once you’ve opened a connection, you can use the /send()/
> method to send a data string to the server for processing if needed. For
> example:
>
>  
>
> // 1. Create XDR object
>
> xdr = new XDomainRequest();
>
>  
>
> //2. Open connection with server using POST method
>
> xdr.open(“POST”, “http://www.contoso.com/xdr.txt”)
>
>  
>
> //3. Send string data to server
>
> xdr.send(“data to be processed”)
>
>  
>
> XDR also has an /abort() /method to cancel an active request, which
> takes no parameters. Data is not available on an abort.
>
> * *
>
> *Properties*
>
> ·         *responseText - *After the server responds, you can retrieve
> the data string through the read-only /responseText /property.
>
> ·         *timeout - *You can use the /timeout /property to set or
> retrieve the number of milliseconds the browser should wait for a server
> to respond.   IE defaults to no timeout if this property is not
> explicitly set. If the request times out, data is not available.
>
> ·         *contentType *– If you are posting data to the server, use the
> /contentType /property to define the content type string that will be
> sent to the server. If you are using a GET then this property will allow
> you to read the content type.
>
>  
>
> *Events*
>
> XDR has the following events:
>
> ·         *onerror* – this event fires when there is an error and the
> request cannot be completed. For example, the network is not available
>
> ·         *ontimeout *– this event fires when the request reaches its
> timeout as defined by the above timeOut property. If the request times
> out data is not available.
>
> ·         *onprogress –* this event fires while the server responds to
> the request by streaming data back to the browser.
>
> ·         *onload *– this event fires when the cross domain request is
> complete and data is available.
>
>  
>
> *Security note: *Cross domain requests can only be sent and received
> from a web page to URLs in the following IE zones. We discourage
> Intranet sites from making XDR data available to help prevent intranet
> data from leaking to malicious Internet sites.
>
>  
>
>  
>
>
>
>  
>
>
>
> *Webpage equests data from a URL in the following zone:*
>
>  
>
>
>
>  
>
>
>
> Local
>
>
>
> Intranet
>
>
>
> Trusted (Intranet)
>
>
>
> Trusted (Internet)
>
>
>
> Internet
>
>
>
> Restricted
>
> *Webpage is in the following zone:*
>
>
>
> Local
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Block
>
> Intranet
>
>
>
> Block
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Block
>
> Trusted (Intranet)
>
>
>
> Block
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Block
>
> Trusted (Internet)
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Block
>
> Internet
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Block
>
> Restricted
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
> * *
>
> *Security note: *When using these XDR, safely handling data provided by
> another web application is a critical operation.
>
>  
>
> For instance, the response could be parsed directly by Javascript, or it
> could be evaluated with a freely available JSON parser (see
> http://www.json.org/) or it could be inserted into a DOM as static text
> (using .innerText).
>
> * *
>
> * *
>
> * *
>
> *Server Side*
>
> The browser will request data from the domain’s server by sending a
> /XDomainRequest: 1 /header. It will only complete the connection if the
> server responds with an XDomainRequestAllowed header with the value “1”
> for true.
>
> For example, a server’s asp page includes the following response header:
>
> *Response.AppendHeader("XDomainRequestAllowed","1");*
>
> This can be done in IIS, for example, using an ASP.NET page. The line of
> code below can be embedded in your ASP page to return the header.
>
>  
>
> *<<% Response.AddHeader  "XDomainRequestAllowed","1" %>Data*
>
> * *
>
> * *
>
> 4.0 Security Model Flowchart
>
> XDR Flowchart
>
> 5.0 Sample Site and Script
>
>  
>
> Please refer to the AJAX Hands on Labs
> <http://code.msdn.microsoft.com/iemix08labs/Release/ProjectReleases.aspx?ReleaseId=590>
> on MSDN for demo script. This will need to be set up on your machine
> from the resource files.
>
>  
>
> 6.0 Other Developer Benefits of Using XDR
>
> 1.        Simple development model.
>
> a.        On the server, the server operator must simply add one new
> header to his HTTP response indicating that cross-domain sources may
> receive the data.  HTTP Headers can be added by any CGI-style process
> (PHP/ASPNET/etc) or by the web server software (Apache/IIS/etc) itself.
>
> b.        On the client, the XDR object is all about
> cross-domain-requests.  Because XDR is a new object we are not forced to
> “bolt on” cross-domain security.  For example, XDR has no means of
> adding a custom header, because custom headers are dangerous for
> cross-domain security as the current web model does not expect a custom
> header being sent across domains. We’ve encountered experiences when web
> applications in the past if encountering a custom header using XHR
> assume it’s coming from the same site.
>
>  
>
> 2.        Provably secure
>
> a.        The XDR security model is simple.  The client sends a request
> that clearly identifies its cross-domain nature, and the server must
> respond in kind for the Same-Origin-Policy to be relaxed such that the
> client can read the response.  If the server does not set the response
> header (a “non-participating” server), the client script is not
> permitted to read the response or determine anything about the target
> server.
>
>  
>
> b.        XDR is very tightly scoped to minimize the risk of increasing
> security exposure of the browser.
>
> 1.        Specifically, any request sent by XDR could also be emitted by
> a properly coded HTML FORM object.  Hence, any “non-participating” web
> server put at risk by XDR is also at risk from simple HTML.
>
>  
>
> Note: The only additional exposure XDR adds is the ability of the client
> to set a specific Content-Type header.
>
>  
>
> 2.        As XDR strips all credentials and cookies, it prevents even
> less attack surface for use in a Cross-Site-Request-Forgery (CSRF)
> <http://en.wikipedia.org/wiki/Cross-site_request_forgery> attack than a
> HTML Form.
>
>  
>
> c.        XDR attempts to block cross-zone/protocol requests, an ASR
> which exceeds that undertaken elsewhere in the browser (e.g. SCRIPT SRC)
> due to compatibility concerns.
>
>  
>
> 3.        Improved Access  Control “Locality”
>
> a.        Unlike policy file-based security, the XDR handshake is a part
> of the HTTP request and response.  This means that XDR is not at risk
> from DNS-Rebinding <http://en.wikipedia.org/wiki/DNS_rebinding> or
> Time-of-Check-Time-of-Use
> <http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use> attacks.
>
> b.        Policy files must be located in a particular location on the
> server, which may cause operational problems for users with limited
> permissions on the server.  For example, consider the shared hosting
> case, where only one admin may write to the server root, but many users
> have permissions to write to sub-folders.  The users must petition the
> admin for an update to the policy file.
>
>  
>
> 4.        Access-Control Flexibility
>
> a.        As Access-Control is based on a per-response basis, the server
> may choose to allow or deny access based upon any criteria desired.  For
> instance, Referer of client, time of day, number of requests per hour,
> etc, etc.
>
> b.        The XDR security model prevents attackers from easily
> determining the access control rules of the server.  The server may keep
> their rules as a trade secret.
>
>  
>
> 7.0 Developer Release Notes
>
> ·         Not yet available across browsers; not a W3C standard.
>
> ·         Services must be explicitly coded to operate with XDR.
>
> ·         As HTTP Methods are deliberately limited, standard REST-based
> interop is not possible.
>
> ·         As credentials are not provided by the browser, the client
> must transmit them in the request body.  This typically should not be a
> problem but this could prevent use of the HttpOnly attribute on cookies
> that must be sent for credentials.
>
> ·         The XDR handshake is HTTP-specific and cannot be directly
> translated for reuse in other protocols or situations (E.g. raw socket
> access).
>
>  
>
>  
>
>  
>
> --
> *Sunava D*utta
> Program Manager (AJAX) - Developer Experience Team, Internet Explorer
>
> One Microsoft Way, Redmond WA 98052
> TEL# (425) 705-1418
>
> FAX# (425) 936-7329
>
>  
>


Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Maciej Stachowiak


On Mar 14, 2008, at 11:24 AM, Jonas Sicking wrote:

>
> Can you describe what you mean by "persistent allow" design?

Anne and I discussed this comment on IRC. One possible flaw is that  
the OPTIONS request to guard against an unaware server receiving cross-
domain POST or other methods is subject to a DNS rebinding attack  
(though this could be fixable by requiring the OPTIONS and the follow-
up request to go to the same IP or something along those lines). I'm  
not sure if this is the vulnerability Chris had in mind. I don't think  
XXX has the same vulnerabilities as Flash though, because the access-
control headers are not an out-of-band control file so the actual  
access control check can't be bypassed via DNS rebinding, only the  
method check.

  - Maciej

>
>
> / Jonas
>
> Chris Wilson wrote:
>> Oops.  Obviously, this was not to go to the whole group.
>> I’ve been asked a lot, over the last week and a half, why we  
>> implemented XDR rather than the current cross-domain XHR  
>> proposals.  The short version is, as Sunava discusses in the  
>> summary of this mail, that x-domain XHR (and Flash’s approach, et  
>> al) is subject to specific x-domain injection attacks because of  
>> its persistent-allow design.
>> *From:* Chris Wilson
>> *Sent:* Friday, March 14, 2008 11:00 AM
>> *To:* Sunava Dutta; Web API WG (public)
>> *Cc:* Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug  
>> Stamper; Marc Silbey
>> *Subject:* RE: IE Team's Proposal for Cross Site Requests
>> I’d move half the summary section up front to make it clear why  
>> we’re not wild about x-domain XHR.  You need to lead with that.
>> *From:* Sunava Dutta
>> *Sent:* Thursday, March 13, 2008 8:47 PM
>> *To:* Sunava Dutta; Web API WG (public)
>> *Cc:* Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath  
>> Udupa; Doug Stamper; Marc Silbey
>> *Subject:* IE Team's Proposal for Cross Site Requests
>> 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.
>>  XDomainRequest (XDR)
>>    Table of Contents
>> 1.0   Summary
>> 2.0   Background: /Overview of how XDR allows cross site requests/
>> 3.0   API Documentation: /Lists the programming interface/methods/
>> properties/
>> 4.0   Security Model Flowchart: /Highlights the security checks  
>> that IE8 makes for an XDR Request./
>> 5.0   Sample Site and Script: /For developers wishing to create an  
>> XDR page./
>> 6.0   Developer Benefits of using XDR: /Covers XDR’s strengths by  
>> demonstrating XDR’s goals of security and simplicity./
>> 7.0   Developer Release Notes: /A short bulleted list of issues  
>> developers should we aware of when using the object and a summary  
>> of what XDR cannot do./
>> 1.0 Summary
>> /With* Cross Domain Request* *(XDR)* developers can create cross  
>> site data aggregation scenarios. Similar to the XMLHttpRequest  
>> object  but with a simpler programming model, this request, called  
>> XDomainRequest, is an easy way to make anonymous requests to third  
>> party sites that support XDR and opt in to making their data  
>> available across domains. Three lines of code will have you making  
>> basic cross site requests. This will ensure data aggregation for  
>> public sites such as blogs etc will be simple, secure and fast. XDR  
>> is an approach designed from the grounds up with a focus on  
>> security. We understand the current cross domain XMLHTTPRequest  
>> proposal and recognize its ability to provide a broader set of  
>> services particularly around declarative auditing for access  
>> control based scenarios and authenticated connections. It does  
>> however come at the risk of more complexity and surface area of  
>> attack. While these are certainly compelling scenarios we realize  
>> that existing implementations have bugs (linked 1 <http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html 
>> >, 2 <https://bugzilla.mozilla.org/show_bug.cgi?id=389508>), some  
>> of which are resolved from the past like TOUCTOU and others like  
>> DNS Rebinding remain mostly unaddressed. In addition, maintaining  
>> configuration is challenging post deployment as Flash has  
>> encountered <http://blog.monstuff.com/archives/000302.html>  
>> (wildcarding) in the past. The IE team is not comfortable  
>> implementing a feature with a high surface area of attack and open/
>> incoming security issues and proposes XDR as a safer alternative.///
>> 2.0 Background
>>  Browsers enforce the same site origin policy, which blocks web  
>> pages from accessing data from another domain. Websites often work  
>> around this policy by having their server request content from  
>> another site’s server in the backend, thus circumventing the check  
>> within the browser.
>>  
>>     Text Box: Figure 1 – IE7 and below need to make a request to  
>> the mashup server which then needs to be proxied to the web server.
>> In IE8 web pages can simply make a cross domain data request within  
>> the browser using the new /XDomainRequest/ object instead of a  
>> server-to-server requests.
>> Cross domain requests require mutual consent between the webpage  
>> and server. You can initiate a cross domain request in your webpage  
>> by creating a /xdomainrequest /object off the window object and  
>> opening a connection to a particular domain. The browser will  
>> request data from the domain’s server by sending a /XDomainRequest:  
>> 1 /header. It will only complete the connection if the server  
>> responds with a XDomainRequestAllowed header with the value “1” for  
>> true.
>> For example, a server’s asp page includes the following response  
>> header:
>> Response.AppendHeader("XDomainRequestAllowed","1");
>>   *Security note: *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.
>>
>> 3.0 API Documentation
>> * *
>> *Methods*
>> Once you create a xdomainrequest object, you can use the /open()/  
>> method to open a connection with a domain’s server. This method  
>> supports the GET and POST HTTP methods and takes the URL to connect  
>> to as a parameter. Once you’ve opened a connection, you can use  
>> the /send()/ method to send a data string to the server for  
>> processing if needed. For example:
>> // 1. Create XDR object
>> xdr = new XDomainRequest();
>> //2. Open connection with server using POST method
>> xdr.open(“POST”, “http://www.contoso.com/xdr.txt”)
>> //3. Send string data to server
>> xdr.send(“data to be processed”)
>> XDR also has an /abort() /method to cancel an active request, which  
>> takes no parameters. Data is not available on an abort.
>> * *
>> *Properties*
>> ·         *responseText - *After the server responds, you can  
>> retrieve the data string through the read-only /responseText /
>> property.
>> ·         *timeout - *You can use the /timeout /property to set or  
>> retrieve the number of milliseconds the browser should wait for a  
>> server to respond.   IE defaults to no timeout if this property is  
>> not explicitly set. If the request times out, data is not available.
>> ·         *contentType *– If you are posting data to the server,  
>> use the /contentType /property to define the content type string  
>> that will be sent to the server. If you are using a GET then this  
>> property will allow you to read the content type.
>> *Events*
>> XDR has the following events:
>> ·         *onerror* – this event fires when there is an error and  
>> the request cannot be completed. For example, the network is not  
>> available
>> ·         *ontimeout *– this event fires when the request reaches  
>> its timeout as defined by the above timeOut property. If the  
>> request times out data is not available.
>> ·         *onprogress –* this event fires while the server responds  
>> to the request by streaming data back to the browser.
>> ·         *onload *– this event fires when the cross domain request  
>> is complete and data is available.
>> *Security note: *Cross domain requests can only be sent and  
>> received from a web page to URLs in the following IE zones. We  
>> discourage Intranet sites from making XDR data available to help  
>> prevent intranet data from leaking to malicious Internet sites.
>>  
>>
>> *Webpage equests data from a URL in the following zone:*
>>
>>
>> Local
>>
>> Intranet
>>
>> Trusted (Intranet)
>>
>> Trusted (Internet)
>>
>> Internet
>>
>> Restricted
>> *Webpage is in the following zone:*
>>
>> Local
>>
>> Allow
>>
>> Allow
>>
>> Allow
>>
>> Allow
>>
>> Allow
>>
>> Block
>> Intranet
>>
>> Block
>>
>> Allow
>>
>> Allow
>>
>> Allow
>>
>> Allow
>>
>> Block
>> Trusted (Intranet)
>>
>> Block
>>
>> Allow
>>
>> Allow
>>
>> Allow
>>
>> Allow
>>
>> Block
>> Trusted (Internet)
>>
>> Block
>>
>> Block
>>
>> Block
>>
>> Allow
>>
>> Allow
>>
>> Block
>> Internet
>>
>> Block
>>
>> Block
>>
>> Block
>>
>> Allow
>>
>> Allow
>>
>> Block
>> Restricted
>>
>> Block
>>
>> Block
>>
>> Block
>>
>> Block
>>
>> Block
>>
>> Block
>> * *
>> *Security note: *When using these XDR, safely handling data  
>> provided by another web application is a critical operation.
>> For instance, the response could be parsed directly by Javascript,  
>> or it could be evaluated with a freely available JSON parser (see http://www.json.org/)
>>  or it could be inserted into a DOM as static text  
>> (using .innerText).
>> * *
>> * *
>> * *
>> *Server Side*
>> The browser will request data from the domain’s server by sending  
>> a /XDomainRequest: 1 /header. It will only complete the connection  
>> if the server responds with an XDomainRequestAllowed header with  
>> the value “1” for true.
>> For example, a server’s asp page includes the following response  
>> header:
>> *Response.AppendHeader("XDomainRequestAllowed","1");*
>> This can be done in IIS, for example, using an ASP.NET page. The  
>> line of code below can be embedded in your ASP page to return the  
>> header.
>> *<<% Response.AddHeader  "XDomainRequestAllowed","1" %>Data*
>> * *
>> * *
>> 4.0 Security Model Flowchart
>> XDR Flowchart
>> 5.0 Sample Site and Script
>> Please refer to the AJAX Hands on Labs <http://code.msdn.microsoft.com/iemix08labs/Release/ProjectReleases.aspx?ReleaseId=590 
>> > on MSDN for demo script. This will need to be set up on your  
>> machine from the resource files.
>> 6.0 Other Developer Benefits of Using XDR
>> 1.        Simple development model.
>> a.        On the server, the server operator must simply add one  
>> new header to his HTTP response indicating that cross-domain  
>> sources may receive the data.  HTTP Headers can be added by any CGI-
>> style process (PHP/ASPNET/etc) or by the web server software  
>> (Apache/IIS/etc) itself.
>> b.        On the client, the XDR object is all about cross-domain-
>> requests.  Because XDR is a new object we are not forced to “bolt  
>> on” cross-domain security.  For example, XDR has no means of adding  
>> a custom header, because custom headers are dangerous for cross-
>> domain security as the current web model does not expect a custom  
>> header being sent across domains. We’ve encountered experiences  
>> when web applications in the past if encountering a custom header  
>> using XHR assume it’s coming from the same site.
>> 2.        Provably secure
>> a.        The XDR security model is simple.  The client sends a  
>> request that clearly identifies its cross-domain nature, and the  
>> server must respond in kind for the Same-Origin-Policy to be  
>> relaxed such that the client can read the response.  If the server  
>> does not set the response header (a “non-participating” server),  
>> the client script is not permitted to read the response or  
>> determine anything about the target server.
>> b.        XDR is very tightly scoped to minimize the risk of  
>> increasing security exposure of the browser.
>> 1.        Specifically, any request sent by XDR could also be  
>> emitted by a properly coded HTML FORM object.  Hence, any “non-
>> participating” web server put at risk by XDR is also at risk from  
>> simple HTML.
>> Note: The only additional exposure XDR adds is the ability of the  
>> client to set a specific Content-Type header.
>> 2.        As XDR strips all credentials and cookies, it prevents  
>> even less attack surface for use in a Cross-Site-Request-Forgery  
>> (CSRF) <http://en.wikipedia.org/wiki/Cross-site_request_forgery>  
>> attack than a HTML Form.
>> c.        XDR attempts to block cross-zone/protocol requests, an  
>> ASR which exceeds that undertaken elsewhere in the browser (e.g.  
>> SCRIPT SRC) due to compatibility concerns.
>> 3.        Improved Access  Control “Locality”
>> a.        Unlike policy file-based security, the XDR handshake is a  
>> part of the HTTP request and response.  This means that XDR is not  
>> at risk from DNS-Rebinding <http://en.wikipedia.org/wiki/DNS_rebinding 
>> > or Time-of-Check-Time-of-Use <http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use 
>> > attacks.
>> b.        Policy files must be located in a particular location on  
>> the server, which may cause operational problems for users with  
>> limited permissions on the server.  For example, consider the  
>> shared hosting case, where only one admin may write to the server  
>> root, but many users have permissions to write to sub-folders.  The  
>> users must petition the admin for an update to the policy file.
>> 4.        Access-Control Flexibility
>> a.        As Access-Control is based on a per-response basis, the  
>> server may choose to allow or deny access based upon any criteria  
>> desired.  For instance, Referer of client, time of day, number of  
>> requests per hour, etc, etc.
>> b.        The XDR security model prevents attackers from easily  
>> determining the access control rules of the server.  The server may  
>> keep their rules as a trade secret.
>> 7.0 Developer Release Notes
>> ·         Not yet available across browsers; not a W3C standard.
>> ·         Services must be explicitly coded to operate with XDR.  
>> ·         As HTTP Methods are deliberately limited, standard REST-
>> based interop is not possible.
>> ·         As credentials are not provided by the browser, the  
>> client must transmit them in the request body.  This typically  
>> should not be a problem but this could prevent use of the HttpOnly  
>> attribute on cookies that must be sent for credentials.
>> ·         The XDR handshake is HTTP-specific and cannot be directly  
>> translated for reuse in other protocols or situations (E.g. raw  
>> socket access).    --
>> *Sunava D*utta
>> Program Manager (AJAX) - Developer Experience Team, Internet Explorer
>> One Microsoft Way, Redmond WA 98052
>> TEL# (425) 705-1418
>> FAX# (425) 936-7329
>>
>
>


Reply | Threaded
Open this post in threaded view
|

RE: IE Team's Proposal for Cross Site Requests

Chris Wilson-12

Yes, DNS rebinding is one of the major attack vectors I was talking about.  If the access controls are negotiated independently of the actual request/response, this is nearly always a concern.  (Yes, you could require follow-ups to go to the same IP address; that's both a pain to actually implement (because a high-level request needs low-level access; typically, I don't believe we need to know about the IP address at the XHR level) and somewhat confusing (because it will break if there's normal, permitted DNS round-robin going on, e.g.).

Maciej, does XXX = XHR L2 or XDR?

-----Original Message-----
From: Maciej Stachowiak [mailto:[hidden email]]
Sent: Friday, March 14, 2008 1:25 PM
To: Jonas Sicking
Cc: Chris Wilson; Web API WG (public); Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
Subject: Re: IE Team's Proposal for Cross Site Requests


On Mar 14, 2008, at 11:24 AM, Jonas Sicking wrote:

>
> Can you describe what you mean by "persistent allow" design?

Anne and I discussed this comment on IRC. One possible flaw is that
the OPTIONS request to guard against an unaware server receiving cross-
domain POST or other methods is subject to a DNS rebinding attack
(though this could be fixable by requiring the OPTIONS and the follow-
up request to go to the same IP or something along those lines). I'm
not sure if this is the vulnerability Chris had in mind. I don't think
XXX has the same vulnerabilities as Flash though, because the access-
control headers are not an out-of-band control file so the actual
access control check can't be bypassed via DNS rebinding, only the
method check.

  - Maciej

>
>
> / Jonas
>
> Chris Wilson wrote:
>> Oops.  Obviously, this was not to go to the whole group.
>> I've been asked a lot, over the last week and a half, why we
>> implemented XDR rather than the current cross-domain XHR
>> proposals.  The short version is, as Sunava discusses in the
>> summary of this mail, that x-domain XHR (and Flash's approach, et
>> al) is subject to specific x-domain injection attacks because of
>> its persistent-allow design.
>> *From:* Chris Wilson
>> *Sent:* Friday, March 14, 2008 11:00 AM
>> *To:* Sunava Dutta; Web API WG (public)
>> *Cc:* Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug
>> Stamper; Marc Silbey
>> *Subject:* RE: IE Team's Proposal for Cross Site Requests
>> I'd move half the summary section up front to make it clear why
>> we're not wild about x-domain XHR.  You need to lead with that.
>> *From:* Sunava Dutta
>> *Sent:* Thursday, March 13, 2008 8:47 PM
>> *To:* Sunava Dutta; Web API WG (public)
>> *Cc:* Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath
>> Udupa; Doug Stamper; Marc Silbey
>> *Subject:* IE Team's Proposal for Cross Site Requests
>> 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.
>>  XDomainRequest (XDR)
>>    Table of Contents
>> 1.0   Summary
>> 2.0   Background: /Overview of how XDR allows cross site requests/
>> 3.0   API Documentation: /Lists the programming interface/methods/
>> properties/
>> 4.0   Security Model Flowchart: /Highlights the security checks
>> that IE8 makes for an XDR Request./
>> 5.0   Sample Site and Script: /For developers wishing to create an
>> XDR page./
>> 6.0   Developer Benefits of using XDR: /Covers XDR's strengths by
>> demonstrating XDR's goals of security and simplicity./
>> 7.0   Developer Release Notes: /A short bulleted list of issues
>> developers should we aware of when using the object and a summary
>> of what XDR cannot do./
>> 1.0 Summary
>> /With* Cross Domain Request* *(XDR)* developers can create cross
>> site data aggregation scenarios. Similar to the XMLHttpRequest
>> object  but with a simpler programming model, this request, called
>> XDomainRequest, is an easy way to make anonymous requests to third
>> party sites that support XDR and opt in to making their data
>> available across domains. Three lines of code will have you making
>> basic cross site requests. This will ensure data aggregation for
>> public sites such as blogs etc will be simple, secure and fast. XDR
>> is an approach designed from the grounds up with a focus on
>> security. We understand the current cross domain XMLHTTPRequest
>> proposal and recognize its ability to provide a broader set of
>> services particularly around declarative auditing for access
>> control based scenarios and authenticated connections. It does
>> however come at the risk of more complexity and surface area of
>> attack. While these are certainly compelling scenarios we realize
>> that existing implementations have bugs (linked 1 <http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html
>> >, 2 <https://bugzilla.mozilla.org/show_bug.cgi?id=389508>), some
>> of which are resolved from the past like TOUCTOU and others like
>> DNS Rebinding remain mostly unaddressed. In addition, maintaining
>> configuration is challenging post deployment as Flash has
>> encountered <http://blog.monstuff.com/archives/000302.html>
>> (wildcarding) in the past. The IE team is not comfortable
>> implementing a feature with a high surface area of attack and open/
>> incoming security issues and proposes XDR as a safer alternative.///
>> 2.0 Background
>>  Browsers enforce the same site origin policy, which blocks web
>> pages from accessing data from another domain. Websites often work
>> around this policy by having their server request content from
>> another site's server in the backend, thus circumventing the check
>> within the browser.
>>
>>      Text Box: Figure 1 - IE7 and below need to make a request to
>> the mashup server which then needs to be proxied to the web server.
>> In IE8 web pages can simply make a cross domain data request within
>> the browser using the new /XDomainRequest/ object instead of a
>> server-to-server requests.
>> Cross domain requests require mutual consent between the webpage
>> and server. You can initiate a cross domain request in your webpage
>> by creating a /xdomainrequest /object off the window object and
>> opening a connection to a particular domain. The browser will
>> request data from the domain's server by sending a /XDomainRequest:
>> 1 /header. It will only complete the connection if the server
>> responds with a XDomainRequestAllowed header with the value "1" for
>> true.
>> For example, a server's asp page includes the following response
>> header:
>> Response.AppendHeader("XDomainRequestAllowed","1");
>>   *Security note: *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.
>>
>> 3.0 API Documentation
>> * *
>> *Methods*
>> Once you create a xdomainrequest object, you can use the /open()/
>> method to open a connection with a domain's server. This method
>> supports the GET and POST HTTP methods and takes the URL to connect
>> to as a parameter. Once you've opened a connection, you can use
>> the /send()/ method to send a data string to the server for
>> processing if needed. For example:
>> // 1. Create XDR object
>> xdr = new XDomainRequest();
>> //2. Open connection with server using POST method
>> xdr.open("POST", "http://www.contoso.com/xdr.txt")
>> //3. Send string data to server
>> xdr.send("data to be processed")
>> XDR also has an /abort() /method to cancel an active request, which
>> takes no parameters. Data is not available on an abort.
>> * *
>> *Properties*
>> *         *responseText - *After the server responds, you can
>> retrieve the data string through the read-only /responseText /
>> property.
>> *         *timeout - *You can use the /timeout /property to set or
>> retrieve the number of milliseconds the browser should wait for a
>> server to respond.   IE defaults to no timeout if this property is
>> not explicitly set. If the request times out, data is not available.
>> *         *contentType *- If you are posting data to the server,
>> use the /contentType /property to define the content type string
>> that will be sent to the server. If you are using a GET then this
>> property will allow you to read the content type.
>> *Events*
>> XDR has the following events:
>> *         *onerror* - this event fires when there is an error and
>> the request cannot be completed. For example, the network is not
>> available
>> *         *ontimeout *- this event fires when the request reaches
>> its timeout as defined by the above timeOut property. If the
>> request times out data is not available.
>> *         *onprogress -* this event fires while the server responds
>> to the request by streaming data back to the browser.
>> *         *onload *- this event fires when the cross domain request
>> is complete and data is available.
>> *Security note: *Cross domain requests can only be sent and
>> received from a web page to URLs in the following IE zones. We
>> discourage Intranet sites from making XDR data available to help
>> prevent intranet data from leaking to malicious Internet sites.
>>
>>
>> *Webpage equests data from a URL in the following zone:*
>>
>>
>> Local
>>
>> Intranet
>>
>> Trusted (Intranet)
>>
>> Trusted (Internet)
>>
>> Internet
>>
>> Restricted
>> *Webpage is in the following zone:*
>>
>> Local
>>
>> Allow
>>
>> Allow
>>
>> Allow
>>
>> Allow
>>
>> Allow
>>
>> Block
>> Intranet
>>
>> Block
>>
>> Allow
>>
>> Allow
>>
>> Allow
>>
>> Allow
>>
>> Block
>> Trusted (Intranet)
>>
>> Block
>>
>> Allow
>>
>> Allow
>>
>> Allow
>>
>> Allow
>>
>> Block
>> Trusted (Internet)
>>
>> Block
>>
>> Block
>>
>> Block
>>
>> Allow
>>
>> Allow
>>
>> Block
>> Internet
>>
>> Block
>>
>> Block
>>
>> Block
>>
>> Allow
>>
>> Allow
>>
>> Block
>> Restricted
>>
>> Block
>>
>> Block
>>
>> Block
>>
>> Block
>>
>> Block
>>
>> Block
>> * *
>> *Security note: *When using these XDR, safely handling data
>> provided by another web application is a critical operation.
>> For instance, the response could be parsed directly by Javascript,
>> or it could be evaluated with a freely available JSON parser (see http://www.json.org/)
>>  or it could be inserted into a DOM as static text
>> (using .innerText).
>> * *
>> * *
>> * *
>> *Server Side*
>> The browser will request data from the domain's server by sending
>> a /XDomainRequest: 1 /header. It will only complete the connection
>> if the server responds with an XDomainRequestAllowed header with
>> the value "1" for true.
>> For example, a server's asp page includes the following response
>> header:
>> *Response.AppendHeader("XDomainRequestAllowed","1");*
>> This can be done in IIS, for example, using an ASP.NET page. The
>> line of code below can be embedded in your ASP page to return the
>> header.
>> *<<% Response.AddHeader  "XDomainRequestAllowed","1" %>Data*
>> * *
>> * *
>> 4.0 Security Model Flowchart
>> XDR Flowchart
>> 5.0 Sample Site and Script
>> Please refer to the AJAX Hands on Labs <http://code.msdn.microsoft.com/iemix08labs/Release/ProjectReleases.aspx?ReleaseId=590
>> > on MSDN for demo script. This will need to be set up on your
>> machine from the resource files.
>> 6.0 Other Developer Benefits of Using XDR
>> 1.        Simple development model.
>> a.        On the server, the server operator must simply add one
>> new header to his HTTP response indicating that cross-domain
>> sources may receive the data.  HTTP Headers can be added by any CGI-
>> style process (PHP/ASPNET/etc) or by the web server software
>> (Apache/IIS/etc) itself.
>> b.        On the client, the XDR object is all about cross-domain-
>> requests.  Because XDR is a new object we are not forced to "bolt
>> on" cross-domain security.  For example, XDR has no means of adding
>> a custom header, because custom headers are dangerous for cross-
>> domain security as the current web model does not expect a custom
>> header being sent across domains. We've encountered experiences
>> when web applications in the past if encountering a custom header
>> using XHR assume it's coming from the same site.
>> 2.        Provably secure
>> a.        The XDR security model is simple.  The client sends a
>> request that clearly identifies its cross-domain nature, and the
>> server must respond in kind for the Same-Origin-Policy to be
>> relaxed such that the client can read the response.  If the server
>> does not set the response header (a "non-participating" server),
>> the client script is not permitted to read the response or
>> determine anything about the target server.
>> b.        XDR is very tightly scoped to minimize the risk of
>> increasing security exposure of the browser.
>> 1.        Specifically, any request sent by XDR could also be
>> emitted by a properly coded HTML FORM object.  Hence, any "non-
>> participating" web server put at risk by XDR is also at risk from
>> simple HTML.
>> Note: The only additional exposure XDR adds is the ability of the
>> client to set a specific Content-Type header.
>> 2.        As XDR strips all credentials and cookies, it prevents
>> even less attack surface for use in a Cross-Site-Request-Forgery
>> (CSRF) <http://en.wikipedia.org/wiki/Cross-site_request_forgery>
>> attack than a HTML Form.
>> c.        XDR attempts to block cross-zone/protocol requests, an
>> ASR which exceeds that undertaken elsewhere in the browser (e.g.
>> SCRIPT SRC) due to compatibility concerns.
>> 3.        Improved Access  Control "Locality"
>> a.        Unlike policy file-based security, the XDR handshake is a
>> part of the HTTP request and response.  This means that XDR is not
>> at risk from DNS-Rebinding <http://en.wikipedia.org/wiki/DNS_rebinding
>> > or Time-of-Check-Time-of-Use <http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use
>> > attacks.
>> b.        Policy files must be located in a particular location on
>> the server, which may cause operational problems for users with
>> limited permissions on the server.  For example, consider the
>> shared hosting case, where only one admin may write to the server
>> root, but many users have permissions to write to sub-folders.  The
>> users must petition the admin for an update to the policy file.
>> 4.        Access-Control Flexibility
>> a.        As Access-Control is based on a per-response basis, the
>> server may choose to allow or deny access based upon any criteria
>> desired.  For instance, Referer of client, time of day, number of
>> requests per hour, etc, etc.
>> b.        The XDR security model prevents attackers from easily
>> determining the access control rules of the server.  The server may
>> keep their rules as a trade secret.
>> 7.0 Developer Release Notes
>> *         Not yet available across browsers; not a W3C standard.
>> *         Services must be explicitly coded to operate with XDR.
>> *         As HTTP Methods are deliberately limited, standard REST-
>> based interop is not possible.
>> *         As credentials are not provided by the browser, the
>> client must transmit them in the request body.  This typically
>> should not be a problem but this could prevent use of the HttpOnly
>> attribute on cookies that must be sent for credentials.
>> *         The XDR handshake is HTTP-specific and cannot be directly
>> translated for reuse in other protocols or situations (E.g. raw
>> socket access).    --
>> *Sunava D*utta
>> Program Manager (AJAX) - Developer Experience Team, Internet Explorer
>> One Microsoft Way, Redmond WA 98052
>> TEL# (425) 705-1418
>> FAX# (425) 936-7329
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Jonas Sicking-2

So the worry here is a scenario where an attacker tricks a user to go to
evil.com which does an evil POST to webstore.com. And at the same time
the attacker launches a DNS rebind attack on the user for the
webstore.com domain name such that the OPTIONS request goes to an
attacker controlled server which approves the POST, but then lets the
actual post go to the real webstore.com server?

If so, couldn't the user simply trick the user to go to webstore.com,
and use a DNS rebind attack so that when webstore.com/ is fetched it
returns a HTML page that contains script that uses normal XHR to do a
POST to webstore.com. When the POST happens the attacker lets that go to
the real webstore.com server.

I.e. I don't see how Cross-site XHR in combination with DNS rebind
attacks lets you do something that DNS rebind attacks doesn't already
let you do on it's own.

XXX = Cross-site Extensions to XHR. So basically XHR+AC spec.

/ Jonas

Chris Wilson wrote:

> Yes, DNS rebinding is one of the major attack vectors I was talking about.  If the access controls are negotiated independently of the actual request/response, this is nearly always a concern.  (Yes, you could require follow-ups to go to the same IP address; that's both a pain to actually implement (because a high-level request needs low-level access; typically, I don't believe we need to know about the IP address at the XHR level) and somewhat confusing (because it will break if there's normal, permitted DNS round-robin going on, e.g.).
>
> Maciej, does XXX = XHR L2 or XDR?
>
> -----Original Message-----
> From: Maciej Stachowiak [mailto:[hidden email]]
> Sent: Friday, March 14, 2008 1:25 PM
> To: Jonas Sicking
> Cc: Chris Wilson; Web API WG (public); Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
> Subject: Re: IE Team's Proposal for Cross Site Requests
>
>
> On Mar 14, 2008, at 11:24 AM, Jonas Sicking wrote:
>
>> Can you describe what you mean by "persistent allow" design?
>
> Anne and I discussed this comment on IRC. One possible flaw is that
> the OPTIONS request to guard against an unaware server receiving cross-
> domain POST or other methods is subject to a DNS rebinding attack
> (though this could be fixable by requiring the OPTIONS and the follow-
> up request to go to the same IP or something along those lines). I'm
> not sure if this is the vulnerability Chris had in mind. I don't think
> XXX has the same vulnerabilities as Flash though, because the access-
> control headers are not an out-of-band control file so the actual
> access control check can't be bypassed via DNS rebinding, only the
> method check.
>
>   - Maciej
>
>>
>> / Jonas
>>
>> Chris Wilson wrote:
>>> Oops.  Obviously, this was not to go to the whole group.
>>> I've been asked a lot, over the last week and a half, why we
>>> implemented XDR rather than the current cross-domain XHR
>>> proposals.  The short version is, as Sunava discusses in the
>>> summary of this mail, that x-domain XHR (and Flash's approach, et
>>> al) is subject to specific x-domain injection attacks because of
>>> its persistent-allow design.
>>> *From:* Chris Wilson
>>> *Sent:* Friday, March 14, 2008 11:00 AM
>>> *To:* Sunava Dutta; Web API WG (public)
>>> *Cc:* Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug
>>> Stamper; Marc Silbey
>>> *Subject:* RE: IE Team's Proposal for Cross Site Requests
>>> I'd move half the summary section up front to make it clear why
>>> we're not wild about x-domain XHR.  You need to lead with that.
>>> *From:* Sunava Dutta
>>> *Sent:* Thursday, March 13, 2008 8:47 PM
>>> *To:* Sunava Dutta; Web API WG (public)
>>> *Cc:* Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath
>>> Udupa; Doug Stamper; Marc Silbey
>>> *Subject:* IE Team's Proposal for Cross Site Requests
>>> 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.
>>>  XDomainRequest (XDR)
>>>    Table of Contents
>>> 1.0   Summary
>>> 2.0   Background: /Overview of how XDR allows cross site requests/
>>> 3.0   API Documentation: /Lists the programming interface/methods/
>>> properties/
>>> 4.0   Security Model Flowchart: /Highlights the security checks
>>> that IE8 makes for an XDR Request./
>>> 5.0   Sample Site and Script: /For developers wishing to create an
>>> XDR page./
>>> 6.0   Developer Benefits of using XDR: /Covers XDR's strengths by
>>> demonstrating XDR's goals of security and simplicity./
>>> 7.0   Developer Release Notes: /A short bulleted list of issues
>>> developers should we aware of when using the object and a summary
>>> of what XDR cannot do./
>>> 1.0 Summary
>>> /With* Cross Domain Request* *(XDR)* developers can create cross
>>> site data aggregation scenarios. Similar to the XMLHttpRequest
>>> object  but with a simpler programming model, this request, called
>>> XDomainRequest, is an easy way to make anonymous requests to third
>>> party sites that support XDR and opt in to making their data
>>> available across domains. Three lines of code will have you making
>>> basic cross site requests. This will ensure data aggregation for
>>> public sites such as blogs etc will be simple, secure and fast. XDR
>>> is an approach designed from the grounds up with a focus on
>>> security. We understand the current cross domain XMLHTTPRequest
>>> proposal and recognize its ability to provide a broader set of
>>> services particularly around declarative auditing for access
>>> control based scenarios and authenticated connections. It does
>>> however come at the risk of more complexity and surface area of
>>> attack. While these are certainly compelling scenarios we realize
>>> that existing implementations have bugs (linked 1 <http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html
>>>> , 2 <https://bugzilla.mozilla.org/show_bug.cgi?id=389508>), some
>>> of which are resolved from the past like TOUCTOU and others like
>>> DNS Rebinding remain mostly unaddressed. In addition, maintaining
>>> configuration is challenging post deployment as Flash has
>>> encountered <http://blog.monstuff.com/archives/000302.html>
>>> (wildcarding) in the past. The IE team is not comfortable
>>> implementing a feature with a high surface area of attack and open/
>>> incoming security issues and proposes XDR as a safer alternative.///
>>> 2.0 Background
>>>  Browsers enforce the same site origin policy, which blocks web
>>> pages from accessing data from another domain. Websites often work
>>> around this policy by having their server request content from
>>> another site's server in the backend, thus circumventing the check
>>> within the browser.
>>>
>>>      Text Box: Figure 1 - IE7 and below need to make a request to
>>> the mashup server which then needs to be proxied to the web server.
>>> In IE8 web pages can simply make a cross domain data request within
>>> the browser using the new /XDomainRequest/ object instead of a
>>> server-to-server requests.
>>> Cross domain requests require mutual consent between the webpage
>>> and server. You can initiate a cross domain request in your webpage
>>> by creating a /xdomainrequest /object off the window object and
>>> opening a connection to a particular domain. The browser will
>>> request data from the domain's server by sending a /XDomainRequest:
>>> 1 /header. It will only complete the connection if the server
>>> responds with a XDomainRequestAllowed header with the value "1" for
>>> true.
>>> For example, a server's asp page includes the following response
>>> header:
>>> Response.AppendHeader("XDomainRequestAllowed","1");
>>>   *Security note: *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.
>>>
>>> 3.0 API Documentation
>>> * *
>>> *Methods*
>>> Once you create a xdomainrequest object, you can use the /open()/
>>> method to open a connection with a domain's server. This method
>>> supports the GET and POST HTTP methods and takes the URL to connect
>>> to as a parameter. Once you've opened a connection, you can use
>>> the /send()/ method to send a data string to the server for
>>> processing if needed. For example:
>>> // 1. Create XDR object
>>> xdr = new XDomainRequest();
>>> //2. Open connection with server using POST method
>>> xdr.open("POST", "http://www.contoso.com/xdr.txt")
>>> //3. Send string data to server
>>> xdr.send("data to be processed")
>>> XDR also has an /abort() /method to cancel an active request, which
>>> takes no parameters. Data is not available on an abort.
>>> * *
>>> *Properties*
>>> *         *responseText - *After the server responds, you can
>>> retrieve the data string through the read-only /responseText /
>>> property.
>>> *         *timeout - *You can use the /timeout /property to set or
>>> retrieve the number of milliseconds the browser should wait for a
>>> server to respond.   IE defaults to no timeout if this property is
>>> not explicitly set. If the request times out, data is not available.
>>> *         *contentType *- If you are posting data to the server,
>>> use the /contentType /property to define the content type string
>>> that will be sent to the server. If you are using a GET then this
>>> property will allow you to read the content type.
>>> *Events*
>>> XDR has the following events:
>>> *         *onerror* - this event fires when there is an error and
>>> the request cannot be completed. For example, the network is not
>>> available
>>> *         *ontimeout *- this event fires when the request reaches
>>> its timeout as defined by the above timeOut property. If the
>>> request times out data is not available.
>>> *         *onprogress -* this event fires while the server responds
>>> to the request by streaming data back to the browser.
>>> *         *onload *- this event fires when the cross domain request
>>> is complete and data is available.
>>> *Security note: *Cross domain requests can only be sent and
>>> received from a web page to URLs in the following IE zones. We
>>> discourage Intranet sites from making XDR data available to help
>>> prevent intranet data from leaking to malicious Internet sites.
>>>
>>>
>>> *Webpage equests data from a URL in the following zone:*
>>>
>>>
>>> Local
>>>
>>> Intranet
>>>
>>> Trusted (Intranet)
>>>
>>> Trusted (Internet)
>>>
>>> Internet
>>>
>>> Restricted
>>> *Webpage is in the following zone:*
>>>
>>> Local
>>>
>>> Allow
>>>
>>> Allow
>>>
>>> Allow
>>>
>>> Allow
>>>
>>> Allow
>>>
>>> Block
>>> Intranet
>>>
>>> Block
>>>
>>> Allow
>>>
>>> Allow
>>>
>>> Allow
>>>
>>> Allow
>>>
>>> Block
>>> Trusted (Intranet)
>>>
>>> Block
>>>
>>> Allow
>>>
>>> Allow
>>>
>>> Allow
>>>
>>> Allow
>>>
>>> Block
>>> Trusted (Internet)
>>>
>>> Block
>>>
>>> Block
>>>
>>> Block
>>>
>>> Allow
>>>
>>> Allow
>>>
>>> Block
>>> Internet
>>>
>>> Block
>>>
>>> Block
>>>
>>> Block
>>>
>>> Allow
>>>
>>> Allow
>>>
>>> Block
>>> Restricted
>>>
>>> Block
>>>
>>> Block
>>>
>>> Block
>>>
>>> Block
>>>
>>> Block
>>>
>>> Block
>>> * *
>>> *Security note: *When using these XDR, safely handling data
>>> provided by another web application is a critical operation.
>>> For instance, the response could be parsed directly by Javascript,
>>> or it could be evaluated with a freely available JSON parser (see http://www.json.org/)
>>>  or it could be inserted into a DOM as static text
>>> (using .innerText).
>>> * *
>>> * *
>>> * *
>>> *Server Side*
>>> The browser will request data from the domain's server by sending
>>> a /XDomainRequest: 1 /header. It will only complete the connection
>>> if the server responds with an XDomainRequestAllowed header with
>>> the value "1" for true.
>>> For example, a server's asp page includes the following response
>>> header:
>>> *Response.AppendHeader("XDomainRequestAllowed","1");*
>>> This can be done in IIS, for example, using an ASP.NET page. The
>>> line of code below can be embedded in your ASP page to return the
>>> header.
>>> *<<% Response.AddHeader  "XDomainRequestAllowed","1" %>Data*
>>> * *
>>> * *
>>> 4.0 Security Model Flowchart
>>> XDR Flowchart
>>> 5.0 Sample Site and Script
>>> Please refer to the AJAX Hands on Labs <http://code.msdn.microsoft.com/iemix08labs/Release/ProjectReleases.aspx?ReleaseId=590
>>>> on MSDN for demo script. This will need to be set up on your
>>> machine from the resource files.
>>> 6.0 Other Developer Benefits of Using XDR
>>> 1.        Simple development model.
>>> a.        On the server, the server operator must simply add one
>>> new header to his HTTP response indicating that cross-domain
>>> sources may receive the data.  HTTP Headers can be added by any CGI-
>>> style process (PHP/ASPNET/etc) or by the web server software
>>> (Apache/IIS/etc) itself.
>>> b.        On the client, the XDR object is all about cross-domain-
>>> requests.  Because XDR is a new object we are not forced to "bolt
>>> on" cross-domain security.  For example, XDR has no means of adding
>>> a custom header, because custom headers are dangerous for cross-
>>> domain security as the current web model does not expect a custom
>>> header being sent across domains. We've encountered experiences
>>> when web applications in the past if encountering a custom header
>>> using XHR assume it's coming from the same site.
>>> 2.        Provably secure
>>> a.        The XDR security model is simple.  The client sends a
>>> request that clearly identifies its cross-domain nature, and the
>>> server must respond in kind for the Same-Origin-Policy to be
>>> relaxed such that the client can read the response.  If the server
>>> does not set the response header (a "non-participating" server),
>>> the client script is not permitted to read the response or
>>> determine anything about the target server.
>>> b.        XDR is very tightly scoped to minimize the risk of
>>> increasing security exposure of the browser.
>>> 1.        Specifically, any request sent by XDR could also be
>>> emitted by a properly coded HTML FORM object.  Hence, any "non-
>>> participating" web server put at risk by XDR is also at risk from
>>> simple HTML.
>>> Note: The only additional exposure XDR adds is the ability of the
>>> client to set a specific Content-Type header.
>>> 2.        As XDR strips all credentials and cookies, it prevents
>>> even less attack surface for use in a Cross-Site-Request-Forgery
>>> (CSRF) <http://en.wikipedia.org/wiki/Cross-site_request_forgery>
>>> attack than a HTML Form.
>>> c.        XDR attempts to block cross-zone/protocol requests, an
>>> ASR which exceeds that undertaken elsewhere in the browser (e.g.
>>> SCRIPT SRC) due to compatibility concerns.
>>> 3.        Improved Access  Control "Locality"
>>> a.        Unlike policy file-based security, the XDR handshake is a
>>> part of the HTTP request and response.  This means that XDR is not
>>> at risk from DNS-Rebinding <http://en.wikipedia.org/wiki/DNS_rebinding
>>>> or Time-of-Check-Time-of-Use <http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use
>>>> attacks.
>>> b.        Policy files must be located in a particular location on
>>> the server, which may cause operational problems for users with
>>> limited permissions on the server.  For example, consider the
>>> shared hosting case, where only one admin may write to the server
>>> root, but many users have permissions to write to sub-folders.  The
>>> users must petition the admin for an update to the policy file.
>>> 4.        Access-Control Flexibility
>>> a.        As Access-Control is based on a per-response basis, the
>>> server may choose to allow or deny access based upon any criteria
>>> desired.  For instance, Referer of client, time of day, number of
>>> requests per hour, etc, etc.
>>> b.        The XDR security model prevents attackers from easily
>>> determining the access control rules of the server.  The server may
>>> keep their rules as a trade secret.
>>> 7.0 Developer Release Notes
>>> *         Not yet available across browsers; not a W3C standard.
>>> *         Services must be explicitly coded to operate with XDR.
>>> *         As HTTP Methods are deliberately limited, standard REST-
>>> based interop is not possible.
>>> *         As credentials are not provided by the browser, the
>>> client must transmit them in the request body.  This typically
>>> should not be a problem but this could prevent use of the HttpOnly
>>> attribute on cookies that must be sent for credentials.
>>> *         The XDR handshake is HTTP-specific and cannot be directly
>>> translated for reuse in other protocols or situations (E.g. raw
>>> socket access).    --
>>> *Sunava D*utta
>>> Program Manager (AJAX) - Developer Experience Team, Internet Explorer
>>> One Microsoft Way, Redmond WA 98052
>>> TEL# (425) 705-1418
>>> FAX# (425) 936-7329
>>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Jonas Sicking-2

Also, the OPTIONS request is there to prevent requests that XDR simply
always allows, i.e. cross site requests using unsafe methods. So I'm not
sure I see how XDR is safer in that regard here.

I would be very interested to hear back on the two first emails I posted
to this thread as they relate to this exact subject.

/ Jonas

Jonas Sicking wrote:

>
> So the worry here is a scenario where an attacker tricks a user to go to
> evil.com which does an evil POST to webstore.com. And at the same time
> the attacker launches a DNS rebind attack on the user for the
> webstore.com domain name such that the OPTIONS request goes to an
> attacker controlled server which approves the POST, but then lets the
> actual post go to the real webstore.com server?
>
> If so, couldn't the user simply trick the user to go to webstore.com,
> and use a DNS rebind attack so that when webstore.com/ is fetched it
> returns a HTML page that contains script that uses normal XHR to do a
> POST to webstore.com. When the POST happens the attacker lets that go to
> the real webstore.com server.
>
> I.e. I don't see how Cross-site XHR in combination with DNS rebind
> attacks lets you do something that DNS rebind attacks doesn't already
> let you do on it's own.
>
> XXX = Cross-site Extensions to XHR. So basically XHR+AC spec.
>
> / Jonas
>
> Chris Wilson wrote:
>> Yes, DNS rebinding is one of the major attack vectors I was talking
>> about.  If the access controls are negotiated independently of the
>> actual request/response, this is nearly always a concern.  (Yes, you
>> could require follow-ups to go to the same IP address; that's both a
>> pain to actually implement (because a high-level request needs
>> low-level access; typically, I don't believe we need to know about the
>> IP address at the XHR level) and somewhat confusing (because it will
>> break if there's normal, permitted DNS round-robin going on, e.g.).
>>
>> Maciej, does XXX = XHR L2 or XDR?
>>
>> -----Original Message-----
>> From: Maciej Stachowiak [mailto:[hidden email]]
>> Sent: Friday, March 14, 2008 1:25 PM
>> To: Jonas Sicking
>> Cc: Chris Wilson; Web API WG (public); Eric Lawrence; Zhenbin Xu;
>> Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
>> Subject: Re: IE Team's Proposal for Cross Site Requests
>>
>>
>> On Mar 14, 2008, at 11:24 AM, Jonas Sicking wrote:
>>
>>> Can you describe what you mean by "persistent allow" design?
>>
>> Anne and I discussed this comment on IRC. One possible flaw is that
>> the OPTIONS request to guard against an unaware server receiving cross-
>> domain POST or other methods is subject to a DNS rebinding attack
>> (though this could be fixable by requiring the OPTIONS and the follow-
>> up request to go to the same IP or something along those lines). I'm
>> not sure if this is the vulnerability Chris had in mind. I don't think
>> XXX has the same vulnerabilities as Flash though, because the access-
>> control headers are not an out-of-band control file so the actual
>> access control check can't be bypassed via DNS rebinding, only the
>> method check.
>>
>>   - Maciej
>>
>>>
>>> / Jonas
>>>
>>> Chris Wilson wrote:
>>>> Oops.  Obviously, this was not to go to the whole group.
>>>> I've been asked a lot, over the last week and a half, why we
>>>> implemented XDR rather than the current cross-domain XHR
>>>> proposals.  The short version is, as Sunava discusses in the
>>>> summary of this mail, that x-domain XHR (and Flash's approach, et
>>>> al) is subject to specific x-domain injection attacks because of
>>>> its persistent-allow design.
>>>> *From:* Chris Wilson
>>>> *Sent:* Friday, March 14, 2008 11:00 AM
>>>> *To:* Sunava Dutta; Web API WG (public)
>>>> *Cc:* Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug
>>>> Stamper; Marc Silbey
>>>> *Subject:* RE: IE Team's Proposal for Cross Site Requests
>>>> I'd move half the summary section up front to make it clear why
>>>> we're not wild about x-domain XHR.  You need to lead with that.
>>>> *From:* Sunava Dutta
>>>> *Sent:* Thursday, March 13, 2008 8:47 PM
>>>> *To:* Sunava Dutta; Web API WG (public)
>>>> *Cc:* Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath
>>>> Udupa; Doug Stamper; Marc Silbey
>>>> *Subject:* IE Team's Proposal for Cross Site Requests
>>>> 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.
>>>>  XDomainRequest (XDR)
>>>>    Table of Contents
>>>> 1.0   Summary
>>>> 2.0   Background: /Overview of how XDR allows cross site requests/
>>>> 3.0   API Documentation: /Lists the programming interface/methods/
>>>> properties/
>>>> 4.0   Security Model Flowchart: /Highlights the security checks
>>>> that IE8 makes for an XDR Request./
>>>> 5.0   Sample Site and Script: /For developers wishing to create an
>>>> XDR page./
>>>> 6.0   Developer Benefits of using XDR: /Covers XDR's strengths by
>>>> demonstrating XDR's goals of security and simplicity./
>>>> 7.0   Developer Release Notes: /A short bulleted list of issues
>>>> developers should we aware of when using the object and a summary
>>>> of what XDR cannot do./
>>>> 1.0 Summary
>>>> /With* Cross Domain Request* *(XDR)* developers can create cross
>>>> site data aggregation scenarios. Similar to the XMLHttpRequest
>>>> object  but with a simpler programming model, this request, called
>>>> XDomainRequest, is an easy way to make anonymous requests to third
>>>> party sites that support XDR and opt in to making their data
>>>> available across domains. Three lines of code will have you making
>>>> basic cross site requests. This will ensure data aggregation for
>>>> public sites such as blogs etc will be simple, secure and fast. XDR
>>>> is an approach designed from the grounds up with a focus on
>>>> security. We understand the current cross domain XMLHTTPRequest
>>>> proposal and recognize its ability to provide a broader set of
>>>> services particularly around declarative auditing for access
>>>> control based scenarios and authenticated connections. It does
>>>> however come at the risk of more complexity and surface area of
>>>> attack. While these are certainly compelling scenarios we realize
>>>> that existing implementations have bugs (linked 1
>>>> <http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html 
>>>>
>>>>> , 2 <https://bugzilla.mozilla.org/show_bug.cgi?id=389508>), some
>>>> of which are resolved from the past like TOUCTOU and others like
>>>> DNS Rebinding remain mostly unaddressed. In addition, maintaining
>>>> configuration is challenging post deployment as Flash has
>>>> encountered <http://blog.monstuff.com/archives/000302.html>
>>>> (wildcarding) in the past. The IE team is not comfortable
>>>> implementing a feature with a high surface area of attack and open/
>>>> incoming security issues and proposes XDR as a safer alternative.///
>>>> 2.0 Background
>>>>  Browsers enforce the same site origin policy, which blocks web
>>>> pages from accessing data from another domain. Websites often work
>>>> around this policy by having their server request content from
>>>> another site's server in the backend, thus circumventing the check
>>>> within the browser.
>>>>
>>>>      Text Box: Figure 1 - IE7 and below need to make a request to
>>>> the mashup server which then needs to be proxied to the web server.
>>>> In IE8 web pages can simply make a cross domain data request within
>>>> the browser using the new /XDomainRequest/ object instead of a
>>>> server-to-server requests.
>>>> Cross domain requests require mutual consent between the webpage
>>>> and server. You can initiate a cross domain request in your webpage
>>>> by creating a /xdomainrequest /object off the window object and
>>>> opening a connection to a particular domain. The browser will
>>>> request data from the domain's server by sending a /XDomainRequest:
>>>> 1 /header. It will only complete the connection if the server
>>>> responds with a XDomainRequestAllowed header with the value "1" for
>>>> true.
>>>> For example, a server's asp page includes the following response
>>>> header:
>>>> Response.AppendHeader("XDomainRequestAllowed","1");
>>>>   *Security note: *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.
>>>>
>>>> 3.0 API Documentation
>>>> * *
>>>> *Methods*
>>>> Once you create a xdomainrequest object, you can use the /open()/
>>>> method to open a connection with a domain's server. This method
>>>> supports the GET and POST HTTP methods and takes the URL to connect
>>>> to as a parameter. Once you've opened a connection, you can use
>>>> the /send()/ method to send a data string to the server for
>>>> processing if needed. For example:
>>>> // 1. Create XDR object
>>>> xdr = new XDomainRequest();
>>>> //2. Open connection with server using POST method
>>>> xdr.open("POST", "http://www.contoso.com/xdr.txt")
>>>> //3. Send string data to server
>>>> xdr.send("data to be processed")
>>>> XDR also has an /abort() /method to cancel an active request, which
>>>> takes no parameters. Data is not available on an abort.
>>>> * *
>>>> *Properties*
>>>> *         *responseText - *After the server responds, you can
>>>> retrieve the data string through the read-only /responseText /
>>>> property.
>>>> *         *timeout - *You can use the /timeout /property to set or
>>>> retrieve the number of milliseconds the browser should wait for a
>>>> server to respond.   IE defaults to no timeout if this property is
>>>> not explicitly set. If the request times out, data is not available.
>>>> *         *contentType *- If you are posting data to the server,
>>>> use the /contentType /property to define the content type string
>>>> that will be sent to the server. If you are using a GET then this
>>>> property will allow you to read the content type.
>>>> *Events*
>>>> XDR has the following events:
>>>> *         *onerror* - this event fires when there is an error and
>>>> the request cannot be completed. For example, the network is not
>>>> available
>>>> *         *ontimeout *- this event fires when the request reaches
>>>> its timeout as defined by the above timeOut property. If the
>>>> request times out data is not available.
>>>> *         *onprogress -* this event fires while the server responds
>>>> to the request by streaming data back to the browser.
>>>> *         *onload *- this event fires when the cross domain request
>>>> is complete and data is available.
>>>> *Security note: *Cross domain requests can only be sent and
>>>> received from a web page to URLs in the following IE zones. We
>>>> discourage Intranet sites from making XDR data available to help
>>>> prevent intranet data from leaking to malicious Internet sites.
>>>>
>>>>
>>>> *Webpage equests data from a URL in the following zone:*
>>>>
>>>>
>>>> Local
>>>>
>>>> Intranet
>>>>
>>>> Trusted (Intranet)
>>>>
>>>> Trusted (Internet)
>>>>
>>>> Internet
>>>>
>>>> Restricted
>>>> *Webpage is in the following zone:*
>>>>
>>>> Local
>>>>
>>>> Allow
>>>>
>>>> Allow
>>>>
>>>> Allow
>>>>
>>>> Allow
>>>>
>>>> Allow
>>>>
>>>> Block
>>>> Intranet
>>>>
>>>> Block
>>>>
>>>> Allow
>>>>
>>>> Allow
>>>>
>>>> Allow
>>>>
>>>> Allow
>>>>
>>>> Block
>>>> Trusted (Intranet)
>>>>
>>>> Block
>>>>
>>>> Allow
>>>>
>>>> Allow
>>>>
>>>> Allow
>>>>
>>>> Allow
>>>>
>>>> Block
>>>> Trusted (Internet)
>>>>
>>>> Block
>>>>
>>>> Block
>>>>
>>>> Block
>>>>
>>>> Allow
>>>>
>>>> Allow
>>>>
>>>> Block
>>>> Internet
>>>>
>>>> Block
>>>>
>>>> Block
>>>>
>>>> Block
>>>>
>>>> Allow
>>>>
>>>> Allow
>>>>
>>>> Block
>>>> Restricted
>>>>
>>>> Block
>>>>
>>>> Block
>>>>
>>>> Block
>>>>
>>>> Block
>>>>
>>>> Block
>>>>
>>>> Block
>>>> * *
>>>> *Security note: *When using these XDR, safely handling data
>>>> provided by another web application is a critical operation.
>>>> For instance, the response could be parsed directly by Javascript,
>>>> or it could be evaluated with a freely available JSON parser (see
>>>> http://www.json.org/)
>>>>  or it could be inserted into a DOM as static text
>>>> (using .innerText).
>>>> * *
>>>> * *
>>>> * *
>>>> *Server Side*
>>>> The browser will request data from the domain's server by sending
>>>> a /XDomainRequest: 1 /header. It will only complete the connection
>>>> if the server responds with an XDomainRequestAllowed header with
>>>> the value "1" for true.
>>>> For example, a server's asp page includes the following response
>>>> header:
>>>> *Response.AppendHeader("XDomainRequestAllowed","1");*
>>>> This can be done in IIS, for example, using an ASP.NET page. The
>>>> line of code below can be embedded in your ASP page to return the
>>>> header.
>>>> *<<% Response.AddHeader  "XDomainRequestAllowed","1" %>Data*
>>>> * *
>>>> * *
>>>> 4.0 Security Model Flowchart
>>>> XDR Flowchart
>>>> 5.0 Sample Site and Script
>>>> Please refer to the AJAX Hands on Labs
>>>> <http://code.msdn.microsoft.com/iemix08labs/Release/ProjectReleases.aspx?ReleaseId=590 
>>>>
>>>>> on MSDN for demo script. This will need to be set up on your
>>>> machine from the resource files.
>>>> 6.0 Other Developer Benefits of Using XDR
>>>> 1.        Simple development model.
>>>> a.        On the server, the server operator must simply add one
>>>> new header to his HTTP response indicating that cross-domain
>>>> sources may receive the data.  HTTP Headers can be added by any CGI-
>>>> style process (PHP/ASPNET/etc) or by the web server software
>>>> (Apache/IIS/etc) itself.
>>>> b.        On the client, the XDR object is all about cross-domain-
>>>> requests.  Because XDR is a new object we are not forced to "bolt
>>>> on" cross-domain security.  For example, XDR has no means of adding
>>>> a custom header, because custom headers are dangerous for cross-
>>>> domain security as the current web model does not expect a custom
>>>> header being sent across domains. We've encountered experiences
>>>> when web applications in the past if encountering a custom header
>>>> using XHR assume it's coming from the same site.
>>>> 2.        Provably secure
>>>> a.        The XDR security model is simple.  The client sends a
>>>> request that clearly identifies its cross-domain nature, and the
>>>> server must respond in kind for the Same-Origin-Policy to be
>>>> relaxed such that the client can read the response.  If the server
>>>> does not set the response header (a "non-participating" server),
>>>> the client script is not permitted to read the response or
>>>> determine anything about the target server.
>>>> b.        XDR is very tightly scoped to minimize the risk of
>>>> increasing security exposure of the browser.
>>>> 1.        Specifically, any request sent by XDR could also be
>>>> emitted by a properly coded HTML FORM object.  Hence, any "non-
>>>> participating" web server put at risk by XDR is also at risk from
>>>> simple HTML.
>>>> Note: The only additional exposure XDR adds is the ability of the
>>>> client to set a specific Content-Type header.
>>>> 2.        As XDR strips all credentials and cookies, it prevents
>>>> even less attack surface for use in a Cross-Site-Request-Forgery
>>>> (CSRF) <http://en.wikipedia.org/wiki/Cross-site_request_forgery>
>>>> attack than a HTML Form.
>>>> c.        XDR attempts to block cross-zone/protocol requests, an
>>>> ASR which exceeds that undertaken elsewhere in the browser (e.g.
>>>> SCRIPT SRC) due to compatibility concerns.
>>>> 3.        Improved Access  Control "Locality"
>>>> a.        Unlike policy file-based security, the XDR handshake is a
>>>> part of the HTTP request and response.  This means that XDR is not
>>>> at risk from DNS-Rebinding <http://en.wikipedia.org/wiki/DNS_rebinding
>>>>> or Time-of-Check-Time-of-Use
>>>>> <http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use
>>>>> attacks.
>>>> b.        Policy files must be located in a particular location on
>>>> the server, which may cause operational problems for users with
>>>> limited permissions on the server.  For example, consider the
>>>> shared hosting case, where only one admin may write to the server
>>>> root, but many users have permissions to write to sub-folders.  The
>>>> users must petition the admin for an update to the policy file.
>>>> 4.        Access-Control Flexibility
>>>> a.        As Access-Control is based on a per-response basis, the
>>>> server may choose to allow or deny access based upon any criteria
>>>> desired.  For instance, Referer of client, time of day, number of
>>>> requests per hour, etc, etc.
>>>> b.        The XDR security model prevents attackers from easily
>>>> determining the access control rules of the server.  The server may
>>>> keep their rules as a trade secret.
>>>> 7.0 Developer Release Notes
>>>> *         Not yet available across browsers; not a W3C standard.
>>>> *         Services must be explicitly coded to operate with XDR.
>>>> *         As HTTP Methods are deliberately limited, standard REST-
>>>> based interop is not possible.
>>>> *         As credentials are not provided by the browser, the
>>>> client must transmit them in the request body.  This typically
>>>> should not be a problem but this could prevent use of the HttpOnly
>>>> attribute on cookies that must be sent for credentials.
>>>> *         The XDR handshake is HTTP-specific and cannot be directly
>>>> translated for reuse in other protocols or situations (E.g. raw
>>>> socket access).    --
>>>> *Sunava D*utta
>>>> Program Manager (AJAX) - Developer Experience Team, Internet Explorer
>>>> One Microsoft Way, Redmond WA 98052
>>>> TEL# (425) 705-1418
>>>> FAX# (425) 936-7329
>>>>
>>>
>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Maciej Stachowiak


On Mar 14, 2008, at 2:42 PM, Jonas Sicking wrote:

> Also, the OPTIONS request is there to prevent requests that XDR  
> simply always allows, i.e. cross site requests using unsafe methods.  
> So I'm not sure I see how XDR is safer in that regard here.
>
> I would be very interested to hear back on the two first emails I  
> posted to this thread as they relate to this exact subject.

The attack scenario would be like this:
- evil.com binds rebind-domain.com to point to evil.com's IP
- evil.com does a cross-domain XHR to rebind-domain.com with POST or a  
custom method, making sure to allow
- evil.com rebinds rebind-domain.com to point to webstore.com's IP
- evil.com does a cross-domain XHR to rebind-domain.com with POST or a  
custom method, it is now allowed

The end result is that you send a request with a disallowed method to  
webstore.com, but the user's normal cookies or other credentials won't  
be sent since the request is sent to rebind-domain.com, not  
webstore.com, as far as the client knows.

However, after thinking about this, you could achieve the same by DNS  
rebinding using evil.com itself, making the XHR not cross-domain at  
all. So, even though there seems to be a potential gap in the OPTIONS  
pre-request here, it does not appear to be a new hole.

I am also not sure if a DNS rebound cross-domain XHR with POST or some  
other method can do anything that you can't do with a cross-domain  
form submission. You can set custom headers, but that seems unlikely  
to make the difference between safe and unsafe. You can also use  
methods besides the ones allowed for form posting. I am not sure why  
the OPTIONS preflight check was added in the first place, I hope  
whoever came up with the pre-check design can chime in to indicate  
whether this attack subverts the purpose of the check.

Regards,
Maciej


>
>
> / Jonas
>
> Jonas Sicking wrote:
>> So the worry here is a scenario where an attacker tricks a user to  
>> go to evil.com which does an evil POST to webstore.com. And at the  
>> same time the attacker launches a DNS rebind attack on the user for  
>> the webstore.com domain name such that the OPTIONS request goes to  
>> an attacker controlled server which approves the POST, but then  
>> lets the actual post go to the real webstore.com server?
>> If so, couldn't the user simply trick the user to go to  
>> webstore.com, and use a DNS rebind attack so that when  
>> webstore.com/ is fetched it returns a HTML page that contains  
>> script that uses normal XHR to do a POST to webstore.com. When the  
>> POST happens the attacker lets that go to the real webstore.com  
>> server.
>> I.e. I don't see how Cross-site XHR in combination with DNS rebind  
>> attacks lets you do something that DNS rebind attacks doesn't  
>> already let you do on it's own.
>> XXX = Cross-site Extensions to XHR. So basically XHR+AC spec.
>> / Jonas
>> Chris Wilson wrote:
>>> Yes, DNS rebinding is one of the major attack vectors I was  
>>> talking about.  If the access controls are negotiated  
>>> independently of the actual request/response, this is nearly  
>>> always a concern.  (Yes, you could require follow-ups to go to the  
>>> same IP address; that's both a pain to actually implement (because  
>>> a high-level request needs low-level access; typically, I don't  
>>> believe we need to know about the IP address at the XHR level) and  
>>> somewhat confusing (because it will break if there's normal,  
>>> permitted DNS round-robin going on, e.g.).
>>>
>>> Maciej, does XXX = XHR L2 or XDR?
>>>
>>> -----Original Message-----
>>> From: Maciej Stachowiak [mailto:[hidden email]]
>>> Sent: Friday, March 14, 2008 1:25 PM
>>> To: Jonas Sicking
>>> Cc: Chris Wilson; Web API WG (public); Eric Lawrence; Zhenbin Xu;  
>>> Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
>>> Subject: Re: IE Team's Proposal for Cross Site Requests
>>>
>>>
>>> On Mar 14, 2008, at 11:24 AM, Jonas Sicking wrote:
>>>
>>>> Can you describe what you mean by "persistent allow" design?
>>>
>>> Anne and I discussed this comment on IRC. One possible flaw is that
>>> the OPTIONS request to guard against an unaware server receiving  
>>> cross-
>>> domain POST or other methods is subject to a DNS rebinding attack
>>> (though this could be fixable by requiring the OPTIONS and the  
>>> follow-
>>> up request to go to the same IP or something along those lines). I'm
>>> not sure if this is the vulnerability Chris had in mind. I don't  
>>> think
>>> XXX has the same vulnerabilities as Flash though, because the  
>>> access-
>>> control headers are not an out-of-band control file so the actual
>>> access control check can't be bypassed via DNS rebinding, only the
>>> method check.
>>>
>>>  - Maciej
>>>
>>>>
>>>> / Jonas
>>>>
>>>> Chris Wilson wrote:
>>>>> Oops.  Obviously, this was not to go to the whole group.
>>>>> I've been asked a lot, over the last week and a half, why we
>>>>> implemented XDR rather than the current cross-domain XHR
>>>>> proposals.  The short version is, as Sunava discusses in the
>>>>> summary of this mail, that x-domain XHR (and Flash's approach, et
>>>>> al) is subject to specific x-domain injection attacks because of
>>>>> its persistent-allow design.
>>>>> *From:* Chris Wilson
>>>>> *Sent:* Friday, March 14, 2008 11:00 AM
>>>>> *To:* Sunava Dutta; Web API WG (public)
>>>>> *Cc:* Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug
>>>>> Stamper; Marc Silbey
>>>>> *Subject:* RE: IE Team's Proposal for Cross Site Requests
>>>>> I'd move half the summary section up front to make it clear why
>>>>> we're not wild about x-domain XHR.  You need to lead with that.
>>>>> *From:* Sunava Dutta
>>>>> *Sent:* Thursday, March 13, 2008 8:47 PM
>>>>> *To:* Sunava Dutta; Web API WG (public)
>>>>> *Cc:* Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn;  
>>>>> Sharath
>>>>> Udupa; Doug Stamper; Marc Silbey
>>>>> *Subject:* IE Team's Proposal for Cross Site Requests
>>>>> 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.
>>>>> XDomainRequest (XDR)
>>>>>   Table of Contents
>>>>> 1.0   Summary
>>>>> 2.0   Background: /Overview of how XDR allows cross site requests/
>>>>> 3.0   API Documentation: /Lists the programming interface/methods/
>>>>> properties/
>>>>> 4.0   Security Model Flowchart: /Highlights the security checks
>>>>> that IE8 makes for an XDR Request./
>>>>> 5.0   Sample Site and Script: /For developers wishing to create an
>>>>> XDR page./
>>>>> 6.0   Developer Benefits of using XDR: /Covers XDR's strengths by
>>>>> demonstrating XDR's goals of security and simplicity./
>>>>> 7.0   Developer Release Notes: /A short bulleted list of issues
>>>>> developers should we aware of when using the object and a summary
>>>>> of what XDR cannot do./
>>>>> 1.0 Summary
>>>>> /With* Cross Domain Request* *(XDR)* developers can create cross
>>>>> site data aggregation scenarios. Similar to the XMLHttpRequest
>>>>> object  but with a simpler programming model, this request, called
>>>>> XDomainRequest, is an easy way to make anonymous requests to third
>>>>> party sites that support XDR and opt in to making their data
>>>>> available across domains. Three lines of code will have you making
>>>>> basic cross site requests. This will ensure data aggregation for
>>>>> public sites such as blogs etc will be simple, secure and fast.  
>>>>> XDR
>>>>> is an approach designed from the grounds up with a focus on
>>>>> security. We understand the current cross domain XMLHTTPRequest
>>>>> proposal and recognize its ability to provide a broader set of
>>>>> services particularly around declarative auditing for access
>>>>> control based scenarios and authenticated connections. It does
>>>>> however come at the risk of more complexity and surface area of
>>>>> attack. While these are certainly compelling scenarios we realize
>>>>> that existing implementations have bugs (linked 1 <http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html
>>>>>> , 2 <https://bugzilla.mozilla.org/show_bug.cgi?id=389508>), some
>>>>> of which are resolved from the past like TOUCTOU and others like
>>>>> DNS Rebinding remain mostly unaddressed. In addition, maintaining
>>>>> configuration is challenging post deployment as Flash has
>>>>> encountered <http://blog.monstuff.com/archives/000302.html>
>>>>> (wildcarding) in the past. The IE team is not comfortable
>>>>> implementing a feature with a high surface area of attack and  
>>>>> open/
>>>>> incoming security issues and proposes XDR as a safer  
>>>>> alternative.///
>>>>> 2.0 Background
>>>>> Browsers enforce the same site origin policy, which blocks web
>>>>> pages from accessing data from another domain. Websites often work
>>>>> around this policy by having their server request content from
>>>>> another site's server in the backend, thus circumventing the check
>>>>> within the browser.
>>>>>
>>>>>     Text Box: Figure 1 - IE7 and below need to make a request to
>>>>> the mashup server which then needs to be proxied to the web  
>>>>> server.
>>>>> In IE8 web pages can simply make a cross domain data request  
>>>>> within
>>>>> the browser using the new /XDomainRequest/ object instead of a
>>>>> server-to-server requests.
>>>>> Cross domain requests require mutual consent between the webpage
>>>>> and server. You can initiate a cross domain request in your  
>>>>> webpage
>>>>> by creating a /xdomainrequest /object off the window object and
>>>>> opening a connection to a particular domain. The browser will
>>>>> request data from the domain's server by sending a /
>>>>> XDomainRequest:
>>>>> 1 /header. It will only complete the connection if the server
>>>>> responds with a XDomainRequestAllowed header with the value "1"  
>>>>> for
>>>>> true.
>>>>> For example, a server's asp page includes the following response
>>>>> header:
>>>>> Response.AppendHeader("XDomainRequestAllowed","1");
>>>>>  *Security note: *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.
>>>>>
>>>>> 3.0 API Documentation
>>>>> * *
>>>>> *Methods*
>>>>> Once you create a xdomainrequest object, you can use the /open()/
>>>>> method to open a connection with a domain's server. This method
>>>>> supports the GET and POST HTTP methods and takes the URL to  
>>>>> connect
>>>>> to as a parameter. Once you've opened a connection, you can use
>>>>> the /send()/ method to send a data string to the server for
>>>>> processing if needed. For example:
>>>>> // 1. Create XDR object
>>>>> xdr = new XDomainRequest();
>>>>> //2. Open connection with server using POST method
>>>>> xdr.open("POST", "http://www.contoso.com/xdr.txt")
>>>>> //3. Send string data to server
>>>>> xdr.send("data to be processed")
>>>>> XDR also has an /abort() /method to cancel an active request,  
>>>>> which
>>>>> takes no parameters. Data is not available on an abort.
>>>>> * *
>>>>> *Properties*
>>>>> *         *responseText - *After the server responds, you can
>>>>> retrieve the data string through the read-only /responseText /
>>>>> property.
>>>>> *         *timeout - *You can use the /timeout /property to set or
>>>>> retrieve the number of milliseconds the browser should wait for a
>>>>> server to respond.   IE defaults to no timeout if this property is
>>>>> not explicitly set. If the request times out, data is not  
>>>>> available.
>>>>> *         *contentType *- If you are posting data to the server,
>>>>> use the /contentType /property to define the content type string
>>>>> that will be sent to the server. If you are using a GET then this
>>>>> property will allow you to read the content type.
>>>>> *Events*
>>>>> XDR has the following events:
>>>>> *         *onerror* - this event fires when there is an error and
>>>>> the request cannot be completed. For example, the network is not
>>>>> available
>>>>> *         *ontimeout *- this event fires when the request reaches
>>>>> its timeout as defined by the above timeOut property. If the
>>>>> request times out data is not available.
>>>>> *         *onprogress -* this event fires while the server  
>>>>> responds
>>>>> to the request by streaming data back to the browser.
>>>>> *         *onload *- this event fires when the cross domain  
>>>>> request
>>>>> is complete and data is available.
>>>>> *Security note: *Cross domain requests can only be sent and
>>>>> received from a web page to URLs in the following IE zones. We
>>>>> discourage Intranet sites from making XDR data available to help
>>>>> prevent intranet data from leaking to malicious Internet sites.
>>>>>
>>>>>
>>>>> *Webpage equests data from a URL in the following zone:*
>>>>>
>>>>>
>>>>> Local
>>>>>
>>>>> Intranet
>>>>>
>>>>> Trusted (Intranet)
>>>>>
>>>>> Trusted (Internet)
>>>>>
>>>>> Internet
>>>>>
>>>>> Restricted
>>>>> *Webpage is in the following zone:*
>>>>>
>>>>> Local
>>>>>
>>>>> Allow
>>>>>
>>>>> Allow
>>>>>
>>>>> Allow
>>>>>
>>>>> Allow
>>>>>
>>>>> Allow
>>>>>
>>>>> Block
>>>>> Intranet
>>>>>
>>>>> Block
>>>>>
>>>>> Allow
>>>>>
>>>>> Allow
>>>>>
>>>>> Allow
>>>>>
>>>>> Allow
>>>>>
>>>>> Block
>>>>> Trusted (Intranet)
>>>>>
>>>>> Block
>>>>>
>>>>> Allow
>>>>>
>>>>> Allow
>>>>>
>>>>> Allow
>>>>>
>>>>> Allow
>>>>>
>>>>> Block
>>>>> Trusted (Internet)
>>>>>
>>>>> Block
>>>>>
>>>>> Block
>>>>>
>>>>> Block
>>>>>
>>>>> Allow
>>>>>
>>>>> Allow
>>>>>
>>>>> Block
>>>>> Internet
>>>>>
>>>>> Block
>>>>>
>>>>> Block
>>>>>
>>>>> Block
>>>>>
>>>>> Allow
>>>>>
>>>>> Allow
>>>>>
>>>>> Block
>>>>> Restricted
>>>>>
>>>>> Block
>>>>>
>>>>> Block
>>>>>
>>>>> Block
>>>>>
>>>>> Block
>>>>>
>>>>> Block
>>>>>
>>>>> Block
>>>>> * *
>>>>> *Security note: *When using these XDR, safely handling data
>>>>> provided by another web application is a critical operation.
>>>>> For instance, the response could be parsed directly by Javascript,
>>>>> or it could be evaluated with a freely available JSON parser  
>>>>> (see http://www.json.org/)
>>>>> or it could be inserted into a DOM as static text
>>>>> (using .innerText).
>>>>> * *
>>>>> * *
>>>>> * *
>>>>> *Server Side*
>>>>> The browser will request data from the domain's server by sending
>>>>> a /XDomainRequest: 1 /header. It will only complete the connection
>>>>> if the server responds with an XDomainRequestAllowed header with
>>>>> the value "1" for true.
>>>>> For example, a server's asp page includes the following response
>>>>> header:
>>>>> *Response.AppendHeader("XDomainRequestAllowed","1");*
>>>>> This can be done in IIS, for example, using an ASP.NET page. The
>>>>> line of code below can be embedded in your ASP page to return the
>>>>> header.
>>>>> *<<% Response.AddHeader  "XDomainRequestAllowed","1" %>Data*
>>>>> * *
>>>>> * *
>>>>> 4.0 Security Model Flowchart
>>>>> XDR Flowchart
>>>>> 5.0 Sample Site and Script
>>>>> Please refer to the AJAX Hands on Labs <http://code.msdn.microsoft.com/iemix08labs/Release/ProjectReleases.aspx?ReleaseId=590
>>>>>> on MSDN for demo script. This will need to be set up on your
>>>>> machine from the resource files.
>>>>> 6.0 Other Developer Benefits of Using XDR
>>>>> 1.        Simple development model.
>>>>> a.        On the server, the server operator must simply add one
>>>>> new header to his HTTP response indicating that cross-domain
>>>>> sources may receive the data.  HTTP Headers can be added by any  
>>>>> CGI-
>>>>> style process (PHP/ASPNET/etc) or by the web server software
>>>>> (Apache/IIS/etc) itself.
>>>>> b.        On the client, the XDR object is all about cross-domain-
>>>>> requests.  Because XDR is a new object we are not forced to "bolt
>>>>> on" cross-domain security.  For example, XDR has no means of  
>>>>> adding
>>>>> a custom header, because custom headers are dangerous for cross-
>>>>> domain security as the current web model does not expect a custom
>>>>> header being sent across domains. We've encountered experiences
>>>>> when web applications in the past if encountering a custom header
>>>>> using XHR assume it's coming from the same site.
>>>>> 2.        Provably secure
>>>>> a.        The XDR security model is simple.  The client sends a
>>>>> request that clearly identifies its cross-domain nature, and the
>>>>> server must respond in kind for the Same-Origin-Policy to be
>>>>> relaxed such that the client can read the response.  If the server
>>>>> does not set the response header (a "non-participating" server),
>>>>> the client script is not permitted to read the response or
>>>>> determine anything about the target server.
>>>>> b.        XDR is very tightly scoped to minimize the risk of
>>>>> increasing security exposure of the browser.
>>>>> 1.        Specifically, any request sent by XDR could also be
>>>>> emitted by a properly coded HTML FORM object.  Hence, any "non-
>>>>> participating" web server put at risk by XDR is also at risk from
>>>>> simple HTML.
>>>>> Note: The only additional exposure XDR adds is the ability of the
>>>>> client to set a specific Content-Type header.
>>>>> 2.        As XDR strips all credentials and cookies, it prevents
>>>>> even less attack surface for use in a Cross-Site-Request-Forgery
>>>>> (CSRF) <http://en.wikipedia.org/wiki/Cross-site_request_forgery>
>>>>> attack than a HTML Form.
>>>>> c.        XDR attempts to block cross-zone/protocol requests, an
>>>>> ASR which exceeds that undertaken elsewhere in the browser (e.g.
>>>>> SCRIPT SRC) due to compatibility concerns.
>>>>> 3.        Improved Access  Control "Locality"
>>>>> a.        Unlike policy file-based security, the XDR handshake  
>>>>> is a
>>>>> part of the HTTP request and response.  This means that XDR is not
>>>>> at risk from DNS-Rebinding <http://en.wikipedia.org/wiki/DNS_rebinding
>>>>>> or Time-of-Check-Time-of-Use <http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use
>>>>>> attacks.
>>>>> b.        Policy files must be located in a particular location on
>>>>> the server, which may cause operational problems for users with
>>>>> limited permissions on the server.  For example, consider the
>>>>> shared hosting case, where only one admin may write to the server
>>>>> root, but many users have permissions to write to sub-folders.  
>>>>> The
>>>>> users must petition the admin for an update to the policy file.
>>>>> 4.        Access-Control Flexibility
>>>>> a.        As Access-Control is based on a per-response basis, the
>>>>> server may choose to allow or deny access based upon any criteria
>>>>> desired.  For instance, Referer of client, time of day, number of
>>>>> requests per hour, etc, etc.
>>>>> b.        The XDR security model prevents attackers from easily
>>>>> determining the access control rules of the server.  The server  
>>>>> may
>>>>> keep their rules as a trade secret.
>>>>> 7.0 Developer Release Notes
>>>>> *         Not yet available across browsers; not a W3C standard.
>>>>> *         Services must be explicitly coded to operate with XDR.
>>>>> *         As HTTP Methods are deliberately limited, standard REST-
>>>>> based interop is not possible.
>>>>> *         As credentials are not provided by the browser, the
>>>>> client must transmit them in the request body.  This typically
>>>>> should not be a problem but this could prevent use of the HttpOnly
>>>>> attribute on cookies that must be sent for credentials.
>>>>> *         The XDR handshake is HTTP-specific and cannot be  
>>>>> directly
>>>>> translated for reuse in other protocols or situations (E.g. raw
>>>>> socket access).    --
>>>>> *Sunava D*utta
>>>>> Program Manager (AJAX) - Developer Experience Team, Internet  
>>>>> Explorer
>>>>> One Microsoft Way, Redmond WA 98052
>>>>> TEL# (425) 705-1418
>>>>> FAX# (425) 936-7329
>>>>>
>>>>
>>>
>>>
>


Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Jonas Sicking-2

The OPTIONS preflight was added for methods like DELETE which today are
not possible to do cross-site. It was also decided that it should be
used for POST since with XHR you can send more types of data, such as
XML data which isn't possible today. This might matter for servers such
as SOAP servers.

But like you say, using DNS rebind attacks you can do all these things
today.

You can replicate the exact same thing like the attack you describe.

- evil.com binds rebind-domain.com to point to evil.com's IP
- evil.com opens an <iframe src="rebind-domain.com">
- evil.com serves a page webpage that sets up a same-site XHR
   POST request
- evil.com rebinds rebind-domain.com to point to webstore.com's IP
- the webpage fires the same-site XHR request

This results in exactly the same request being made to the webstore.

/ Jonas

Maciej Stachowiak wrote:

>
>
> On Mar 14, 2008, at 2:42 PM, Jonas Sicking wrote:
>
>> Also, the OPTIONS request is there to prevent requests that XDR simply
>> always allows, i.e. cross site requests using unsafe methods. So I'm
>> not sure I see how XDR is safer in that regard here.
>>
>> I would be very interested to hear back on the two first emails I
>> posted to this thread as they relate to this exact subject.
>
> The attack scenario would be like this:
> - evil.com binds rebind-domain.com to point to evil.com's IP
> - evil.com does a cross-domain XHR to rebind-domain.com with POST or a
> custom method, making sure to allow
> - evil.com rebinds rebind-domain.com to point to webstore.com's IP
> - evil.com does a cross-domain XHR to rebind-domain.com with POST or a
> custom method, it is now allowed
>
> The end result is that you send a request with a disallowed method to
> webstore.com, but the user's normal cookies or other credentials won't
> be sent since the request is sent to rebind-domain.com, not
> webstore.com, as far as the client knows.
>
> However, after thinking about this, you could achieve the same by DNS
> rebinding using evil.com itself, making the XHR not cross-domain at all.
> So, even though there seems to be a potential gap in the OPTIONS
> pre-request here, it does not appear to be a new hole.
>
> I am also not sure if a DNS rebound cross-domain XHR with POST or some
> other method can do anything that you can't do with a cross-domain form
> submission. You can set custom headers, but that seems unlikely to make
> the difference between safe and unsafe. You can also use methods besides
> the ones allowed for form posting. I am not sure why the OPTIONS
> preflight check was added in the first place, I hope whoever came up
> with the pre-check design can chime in to indicate whether this attack
> subverts the purpose of the check.
>
> Regards,
> Maciej
>
>
>>
>>
>> / Jonas
>>
>> Jonas Sicking wrote:
>>> So the worry here is a scenario where an attacker tricks a user to go
>>> to evil.com which does an evil POST to webstore.com. And at the same
>>> time the attacker launches a DNS rebind attack on the user for the
>>> webstore.com domain name such that the OPTIONS request goes to an
>>> attacker controlled server which approves the POST, but then lets the
>>> actual post go to the real webstore.com server?
>>> If so, couldn't the user simply trick the user to go to webstore.com,
>>> and use a DNS rebind attack so that when webstore.com/ is fetched it
>>> returns a HTML page that contains script that uses normal XHR to do a
>>> POST to webstore.com. When the POST happens the attacker lets that go
>>> to the real webstore.com server.
>>> I.e. I don't see how Cross-site XHR in combination with DNS rebind
>>> attacks lets you do something that DNS rebind attacks doesn't already
>>> let you do on it's own.
>>> XXX = Cross-site Extensions to XHR. So basically XHR+AC spec.
>>> / Jonas
>>> Chris Wilson wrote:
>>>> Yes, DNS rebinding is one of the major attack vectors I was talking
>>>> about.  If the access controls are negotiated independently of the
>>>> actual request/response, this is nearly always a concern.  (Yes, you
>>>> could require follow-ups to go to the same IP address; that's both a
>>>> pain to actually implement (because a high-level request needs
>>>> low-level access; typically, I don't believe we need to know about
>>>> the IP address at the XHR level) and somewhat confusing (because it
>>>> will break if there's normal, permitted DNS round-robin going on,
>>>> e.g.).
>>>>
>>>> Maciej, does XXX = XHR L2 or XDR?
>>>>
>>>> -----Original Message-----
>>>> From: Maciej Stachowiak [mailto:[hidden email]]
>>>> Sent: Friday, March 14, 2008 1:25 PM
>>>> To: Jonas Sicking
>>>> Cc: Chris Wilson; Web API WG (public); Eric Lawrence; Zhenbin Xu;
>>>> Gideon Cohn; Sharath Udupa; Doug Stamper; Marc Silbey
>>>> Subject: Re: IE Team's Proposal for Cross Site Requests
>>>>
>>>>
>>>> On Mar 14, 2008, at 11:24 AM, Jonas Sicking wrote:
>>>>
>>>>> Can you describe what you mean by "persistent allow" design?
>>>>
>>>> Anne and I discussed this comment on IRC. One possible flaw is that
>>>> the OPTIONS request to guard against an unaware server receiving cross-
>>>> domain POST or other methods is subject to a DNS rebinding attack
>>>> (though this could be fixable by requiring the OPTIONS and the follow-
>>>> up request to go to the same IP or something along those lines). I'm
>>>> not sure if this is the vulnerability Chris had in mind. I don't think
>>>> XXX has the same vulnerabilities as Flash though, because the access-
>>>> control headers are not an out-of-band control file so the actual
>>>> access control check can't be bypassed via DNS rebinding, only the
>>>> method check.
>>>>
>>>>  - Maciej
>>>>
>>>>>
>>>>> / Jonas
>>>>>
>>>>> Chris Wilson wrote:
>>>>>> Oops.  Obviously, this was not to go to the whole group.
>>>>>> I've been asked a lot, over the last week and a half, why we
>>>>>> implemented XDR rather than the current cross-domain XHR
>>>>>> proposals.  The short version is, as Sunava discusses in the
>>>>>> summary of this mail, that x-domain XHR (and Flash's approach, et
>>>>>> al) is subject to specific x-domain injection attacks because of
>>>>>> its persistent-allow design.
>>>>>> *From:* Chris Wilson
>>>>>> *Sent:* Friday, March 14, 2008 11:00 AM
>>>>>> *To:* Sunava Dutta; Web API WG (public)
>>>>>> *Cc:* Eric Lawrence; Zhenbin Xu; Gideon Cohn; Sharath Udupa; Doug
>>>>>> Stamper; Marc Silbey
>>>>>> *Subject:* RE: IE Team's Proposal for Cross Site Requests
>>>>>> I'd move half the summary section up front to make it clear why
>>>>>> we're not wild about x-domain XHR.  You need to lead with that.
>>>>>> *From:* Sunava Dutta
>>>>>> *Sent:* Thursday, March 13, 2008 8:47 PM
>>>>>> *To:* Sunava Dutta; Web API WG (public)
>>>>>> *Cc:* Eric Lawrence; Chris Wilson; Zhenbin Xu; Gideon Cohn; Sharath
>>>>>> Udupa; Doug Stamper; Marc Silbey
>>>>>> *Subject:* IE Team's Proposal for Cross Site Requests
>>>>>> 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.
>>>>>> XDomainRequest (XDR)
>>>>>>   Table of Contents
>>>>>> 1.0   Summary
>>>>>> 2.0   Background: /Overview of how XDR allows cross site requests/
>>>>>> 3.0   API Documentation: /Lists the programming interface/methods/
>>>>>> properties/
>>>>>> 4.0   Security Model Flowchart: /Highlights the security checks
>>>>>> that IE8 makes for an XDR Request./
>>>>>> 5.0   Sample Site and Script: /For developers wishing to create an
>>>>>> XDR page./
>>>>>> 6.0   Developer Benefits of using XDR: /Covers XDR's strengths by
>>>>>> demonstrating XDR's goals of security and simplicity./
>>>>>> 7.0   Developer Release Notes: /A short bulleted list of issues
>>>>>> developers should we aware of when using the object and a summary
>>>>>> of what XDR cannot do./
>>>>>> 1.0 Summary
>>>>>> /With* Cross Domain Request* *(XDR)* developers can create cross
>>>>>> site data aggregation scenarios. Similar to the XMLHttpRequest
>>>>>> object  but with a simpler programming model, this request, called
>>>>>> XDomainRequest, is an easy way to make anonymous requests to third
>>>>>> party sites that support XDR and opt in to making their data
>>>>>> available across domains. Three lines of code will have you making
>>>>>> basic cross site requests. This will ensure data aggregation for
>>>>>> public sites such as blogs etc will be simple, secure and fast. XDR
>>>>>> is an approach designed from the grounds up with a focus on
>>>>>> security. We understand the current cross domain XMLHTTPRequest
>>>>>> proposal and recognize its ability to provide a broader set of
>>>>>> services particularly around declarative auditing for access
>>>>>> control based scenarios and authenticated connections. It does
>>>>>> however come at the risk of more complexity and surface area of
>>>>>> attack. While these are certainly compelling scenarios we realize
>>>>>> that existing implementations have bugs (linked 1
>>>>>> <http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html 
>>>>>>
>>>>>>> , 2 <https://bugzilla.mozilla.org/show_bug.cgi?id=389508>), some
>>>>>> of which are resolved from the past like TOUCTOU and others like
>>>>>> DNS Rebinding remain mostly unaddressed. In addition, maintaining
>>>>>> configuration is challenging post deployment as Flash has
>>>>>> encountered <http://blog.monstuff.com/archives/000302.html>
>>>>>> (wildcarding) in the past. The IE team is not comfortable
>>>>>> implementing a feature with a high surface area of attack and open/
>>>>>> incoming security issues and proposes XDR as a safer alternative.///
>>>>>> 2.0 Background
>>>>>> Browsers enforce the same site origin policy, which blocks web
>>>>>> pages from accessing data from another domain. Websites often work
>>>>>> around this policy by having their server request content from
>>>>>> another site's server in the backend, thus circumventing the check
>>>>>> within the browser.
>>>>>>
>>>>>>     Text Box: Figure 1 - IE7 and below need to make a request to
>>>>>> the mashup server which then needs to be proxied to the web server.
>>>>>> In IE8 web pages can simply make a cross domain data request within
>>>>>> the browser using the new /XDomainRequest/ object instead of a
>>>>>> server-to-server requests.
>>>>>> Cross domain requests require mutual consent between the webpage
>>>>>> and server. You can initiate a cross domain request in your webpage
>>>>>> by creating a /xdomainrequest /object off the window object and
>>>>>> opening a connection to a particular domain. The browser will
>>>>>> request data from the domain's server by sending a /XDomainRequest:
>>>>>> 1 /header. It will only complete the connection if the server
>>>>>> responds with a XDomainRequestAllowed header with the value "1" for
>>>>>> true.
>>>>>> For example, a server's asp page includes the following response
>>>>>> header:
>>>>>> Response.AppendHeader("XDomainRequestAllowed","1");
>>>>>>  *Security note: *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.
>>>>>>
>>>>>> 3.0 API Documentation
>>>>>> * *
>>>>>> *Methods*
>>>>>> Once you create a xdomainrequest object, you can use the /open()/
>>>>>> method to open a connection with a domain's server. This method
>>>>>> supports the GET and POST HTTP methods and takes the URL to connect
>>>>>> to as a parameter. Once you've opened a connection, you can use
>>>>>> the /send()/ method to send a data string to the server for
>>>>>> processing if needed. For example:
>>>>>> // 1. Create XDR object
>>>>>> xdr = new XDomainRequest();
>>>>>> //2. Open connection with server using POST method
>>>>>> xdr.open("POST", "http://www.contoso.com/xdr.txt")
>>>>>> //3. Send string data to server
>>>>>> xdr.send("data to be processed")
>>>>>> XDR also has an /abort() /method to cancel an active request, which
>>>>>> takes no parameters. Data is not available on an abort.
>>>>>> * *
>>>>>> *Properties*
>>>>>> *         *responseText - *After the server responds, you can
>>>>>> retrieve the data string through the read-only /responseText /
>>>>>> property.
>>>>>> *         *timeout - *You can use the /timeout /property to set or
>>>>>> retrieve the number of milliseconds the browser should wait for a
>>>>>> server to respond.   IE defaults to no timeout if this property is
>>>>>> not explicitly set. If the request times out, data is not available.
>>>>>> *         *contentType *- If you are posting data to the server,
>>>>>> use the /contentType /property to define the content type string
>>>>>> that will be sent to the server. If you are using a GET then this
>>>>>> property will allow you to read the content type.
>>>>>> *Events*
>>>>>> XDR has the following events:
>>>>>> *         *onerror* - this event fires when there is an error and
>>>>>> the request cannot be completed. For example, the network is not
>>>>>> available
>>>>>> *         *ontimeout *- this event fires when the request reaches
>>>>>> its timeout as defined by the above timeOut property. If the
>>>>>> request times out data is not available.
>>>>>> *         *onprogress -* this event fires while the server responds
>>>>>> to the request by streaming data back to the browser.
>>>>>> *         *onload *- this event fires when the cross domain request
>>>>>> is complete and data is available.
>>>>>> *Security note: *Cross domain requests can only be sent and
>>>>>> received from a web page to URLs in the following IE zones. We
>>>>>> discourage Intranet sites from making XDR data available to help
>>>>>> prevent intranet data from leaking to malicious Internet sites.
>>>>>>
>>>>>>
>>>>>> *Webpage equests data from a URL in the following zone:*
>>>>>>
>>>>>>
>>>>>> Local
>>>>>>
>>>>>> Intranet
>>>>>>
>>>>>> Trusted (Intranet)
>>>>>>
>>>>>> Trusted (Internet)
>>>>>>
>>>>>> Internet
>>>>>>
>>>>>> Restricted
>>>>>> *Webpage is in the following zone:*
>>>>>>
>>>>>> Local
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Block
>>>>>> Intranet
>>>>>>
>>>>>> Block
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Block
>>>>>> Trusted (Intranet)
>>>>>>
>>>>>> Block
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Block
>>>>>> Trusted (Internet)
>>>>>>
>>>>>> Block
>>>>>>
>>>>>> Block
>>>>>>
>>>>>> Block
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Block
>>>>>> Internet
>>>>>>
>>>>>> Block
>>>>>>
>>>>>> Block
>>>>>>
>>>>>> Block
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Allow
>>>>>>
>>>>>> Block
>>>>>> Restricted
>>>>>>
>>>>>> Block
>>>>>>
>>>>>> Block
>>>>>>
>>>>>> Block
>>>>>>
>>>>>> Block
>>>>>>
>>>>>> Block
>>>>>>
>>>>>> Block
>>>>>> * *
>>>>>> *Security note: *When using these XDR, safely handling data
>>>>>> provided by another web application is a critical operation.
>>>>>> For instance, the response could be parsed directly by Javascript,
>>>>>> or it could be evaluated with a freely available JSON parser (see
>>>>>> http://www.json.org/)
>>>>>> or it could be inserted into a DOM as static text
>>>>>> (using .innerText).
>>>>>> * *
>>>>>> * *
>>>>>> * *
>>>>>> *Server Side*
>>>>>> The browser will request data from the domain's server by sending
>>>>>> a /XDomainRequest: 1 /header. It will only complete the connection
>>>>>> if the server responds with an XDomainRequestAllowed header with
>>>>>> the value "1" for true.
>>>>>> For example, a server's asp page includes the following response
>>>>>> header:
>>>>>> *Response.AppendHeader("XDomainRequestAllowed","1");*
>>>>>> This can be done in IIS, for example, using an ASP.NET page. The
>>>>>> line of code below can be embedded in your ASP page to return the
>>>>>> header.
>>>>>> *<<% Response.AddHeader  "XDomainRequestAllowed","1" %>Data*
>>>>>> * *
>>>>>> * *
>>>>>> 4.0 Security Model Flowchart
>>>>>> XDR Flowchart
>>>>>> 5.0 Sample Site and Script
>>>>>> Please refer to the AJAX Hands on Labs
>>>>>> <http://code.msdn.microsoft.com/iemix08labs/Release/ProjectReleases.aspx?ReleaseId=590 
>>>>>>
>>>>>>> on MSDN for demo script. This will need to be set up on your
>>>>>> machine from the resource files.
>>>>>> 6.0 Other Developer Benefits of Using XDR
>>>>>> 1.        Simple development model.
>>>>>> a.        On the server, the server operator must simply add one
>>>>>> new header to his HTTP response indicating that cross-domain
>>>>>> sources may receive the data.  HTTP Headers can be added by any CGI-
>>>>>> style process (PHP/ASPNET/etc) or by the web server software
>>>>>> (Apache/IIS/etc) itself.
>>>>>> b.        On the client, the XDR object is all about cross-domain-
>>>>>> requests.  Because XDR is a new object we are not forced to "bolt
>>>>>> on" cross-domain security.  For example, XDR has no means of adding
>>>>>> a custom header, because custom headers are dangerous for cross-
>>>>>> domain security as the current web model does not expect a custom
>>>>>> header being sent across domains. We've encountered experiences
>>>>>> when web applications in the past if encountering a custom header
>>>>>> using XHR assume it's coming from the same site.
>>>>>> 2.        Provably secure
>>>>>> a.        The XDR security model is simple.  The client sends a
>>>>>> request that clearly identifies its cross-domain nature, and the
>>>>>> server must respond in kind for the Same-Origin-Policy to be
>>>>>> relaxed such that the client can read the response.  If the server
>>>>>> does not set the response header (a "non-participating" server),
>>>>>> the client script is not permitted to read the response or
>>>>>> determine anything about the target server.
>>>>>> b.        XDR is very tightly scoped to minimize the risk of
>>>>>> increasing security exposure of the browser.
>>>>>> 1.        Specifically, any request sent by XDR could also be
>>>>>> emitted by a properly coded HTML FORM object.  Hence, any "non-
>>>>>> participating" web server put at risk by XDR is also at risk from
>>>>>> simple HTML.
>>>>>> Note: The only additional exposure XDR adds is the ability of the
>>>>>> client to set a specific Content-Type header.
>>>>>> 2.        As XDR strips all credentials and cookies, it prevents
>>>>>> even less attack surface for use in a Cross-Site-Request-Forgery
>>>>>> (CSRF) <http://en.wikipedia.org/wiki/Cross-site_request_forgery>
>>>>>> attack than a HTML Form.
>>>>>> c.        XDR attempts to block cross-zone/protocol requests, an
>>>>>> ASR which exceeds that undertaken elsewhere in the browser (e.g.
>>>>>> SCRIPT SRC) due to compatibility concerns.
>>>>>> 3.        Improved Access  Control "Locality"
>>>>>> a.        Unlike policy file-based security, the XDR handshake is a
>>>>>> part of the HTTP request and response.  This means that XDR is not
>>>>>> at risk from DNS-Rebinding
>>>>>> <http://en.wikipedia.org/wiki/DNS_rebinding
>>>>>>> or Time-of-Check-Time-of-Use
>>>>>>> <http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use
>>>>>>> attacks.
>>>>>> b.        Policy files must be located in a particular location on
>>>>>> the server, which may cause operational problems for users with
>>>>>> limited permissions on the server.  For example, consider the
>>>>>> shared hosting case, where only one admin may write to the server
>>>>>> root, but many users have permissions to write to sub-folders.  The
>>>>>> users must petition the admin for an update to the policy file.
>>>>>> 4.        Access-Control Flexibility
>>>>>> a.        As Access-Control is based on a per-response basis, the
>>>>>> server may choose to allow or deny access based upon any criteria
>>>>>> desired.  For instance, Referer of client, time of day, number of
>>>>>> requests per hour, etc, etc.
>>>>>> b.        The XDR security model prevents attackers from easily
>>>>>> determining the access control rules of the server.  The server may
>>>>>> keep their rules as a trade secret.
>>>>>> 7.0 Developer Release Notes
>>>>>> *         Not yet available across browsers; not a W3C standard.
>>>>>> *         Services must be explicitly coded to operate with XDR.
>>>>>> *         As HTTP Methods are deliberately limited, standard REST-
>>>>>> based interop is not possible.
>>>>>> *         As credentials are not provided by the browser, the
>>>>>> client must transmit them in the request body.  This typically
>>>>>> should not be a problem but this could prevent use of the HttpOnly
>>>>>> attribute on cookies that must be sent for credentials.
>>>>>> *         The XDR handshake is HTTP-specific and cannot be directly
>>>>>> translated for reuse in other protocols or situations (E.g. raw
>>>>>> socket access).    --
>>>>>> *Sunava D*utta
>>>>>> Program Manager (AJAX) - Developer Experience Team, Internet Explorer
>>>>>> One Microsoft Way, Redmond WA 98052
>>>>>> TEL# (425) 705-1418
>>>>>> FAX# (425) 936-7329
>>>>>>
>>>>>
>>>>
>>>>
>>
>
>


Reply | Threaded
Open this post in threaded view
|

RE: IE Team's Proposal for Cross Site Requests

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

Thanks for all of the great input!

=====

Jonas Sicking [[hidden email]] asked:
<<How do you define the "Intranet", "Internet", "Restricted" etc zones?  Without correct definitions for these zones it seems possible to attack intranet servers by sending unsafe (such as POST or DELETE) requests to intranet servers from internet pages.>>

The XDR design does not require zone awareness; this should be considered an optional part of the specification.  Zones are used as an attack surface reduction in IE as they are supported by the IE/Windows platform.  Other browsers could elect to implement an approach where a plain hostname (no dots) is isolated from a fully-qualified domain name (with dots) to approximate the Zones behavior.  However, non-IE browsers generally do not appear to do this today, and this is not required for a successful XDR implementation.

Note that XDR supports only the GET and POST methods, DELETE and other methods are not supported.

XDR is intended for "public" data.  We explicitly suggest that Intranet servers do not expose private data through this mechanism.  In order to ensure that no existing servers/services (in any zone) are put at risk, XDR does not send credentials of any sort, and requires that the server acknowledge the cross-domain nature of the request via the response header.

=====

Jonas Sicking [[hidden email]] asked:
<<Also, if you do have reliable definitions of the "Intranet"/"Internet"/"Restricted" zones, what is the purpose of the XDomainRequestAllowed header since presumably all servers in a zone could just read data directly from each other without regard for the XDomainRequestAllowed header.>>

If you are suggesting that XDR competes directly with server-side proxies, then yes, this is true.

The intent of XDR is to allow an AJAX application to communicate with multiple origin servers without the overhead of proxying all cross-domain requests through the server which is hosting the AJAX application.

For instance, consider an AJAX "portal" homepage hosted by AJAXPortal.example.com.  The portal page presents data from multiple providers.  In order to allow this, the developer has at least three design options:

1> Use XDR.  The clientside page retrieves data directly from the data providers.
2> Use a serverside proxy running on AJAXPortal.example.com, which uses a backend process to call out to the data provider's servers.  The proxy aggregates the data on AJAXPortal.example.com, and then supplies it to the client.
3> Include multiple IFRAMEs, each of which points to a different data provider.

Using XDR (#1) results in lower load on the AJAXPortal server as compared to using a serverside proxy (#2).  Using XDR (#1) provides increased client application flexibility as compared to using multiple IFRAMEs (#3).

=====

Jonas Sicking [[hidden email]] observed:
<<Also, the OPTIONS request is there to prevent requests that XDR simply always allows, i.e. cross site requests using unsafe methods. So I'm not sure I see how XDR is safer in that regard here.>>

XDR intentionally does not permit cross-site requests that are not already possible using plain HTML forms.  HTML permits GET/POST forms to be submitted cross-domain.

=====

Laurens Holst [[hidden email]] asked:
<<So, if I cannot set HTTP headers, how am I supposed to set an Accept
header to indicate that I e.g. want to receive application/xhtml+xml,
application/atom+xml, application/*rss*+xml, application/rdf+xml, etc.?
Your proposal is completely unfriendly to content negotiation. Also,
there are valid use cases for setting other headers.

I sincerely hope you will fix this issue by creating a blacklist of
headers instead of disallowing them entirely.>>

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.

Creating a "blocklist" of headers is problematic as there is no existing mechanism to determine whether a target server will interpret a given header in a particular way.

By way of example, we are aware of servers which utilize custom HTTP request headers as an anti-CRSF mechanism.  Such servers assume that, because the only mechanism currently available in the browser to send custom headers is via XMLHTTPRequest, if such custom headers are present, then the request "must" be from a same-origin XHR object.  Hence, permitting use of custom headers in XDR would expose such servers to attack.  It's absolutely reasonable to argue that such servers never should have made such assumptions, however we do not feel it is appropriate to put servers at risk.

While HTTP-based content-negotiation is certainly well-defined by the HTTP specifications, for operational reasons it is relatively uncommon in the wild.  Different content types are usually served from different URLs; for instance, you can see that Yahoo!-based services use a URL parameter to pivot between JSON and XML format (http://developer.yahoo.com/common/json.html).

=====

Maciej Stachowiak [[hidden email]] asked:
<<How does this compare to the Cross-Site Extensions for XMLHttpRequest standard that is being developed by Web API and Web App Formats (and as implemented in Firefox betas)? From Apple's point of view we would like to have a unified standard in this area.>>

We believe that the XDR proposal exposes a smaller surface of attack than the Cross-Site extensions for XHR.  Specifically, it can be demonstrated that the capabilities exposed by XDR are virtually identical to the capabilities exposed by existing HTML tags.  The one exception (obviously) is that the XDR object allows examination of response bodies cross-domain if and only if the server explicitly indicates that such access is permissible via the XDomainRequestAllowed header.

=====

Maciej Stachowiak [[hidden email]] asked, in part:
<<I am also not sure if a DNS rebound cross-domain XHR with POST or some other method can do anything that you can't do with a cross-domain form submission. You can set custom headers, but that seems unlikely to make the difference between safe and unsafe.>>

It's certainly a possibility.  For instance, consider a device which accepts SOAP XML as input  The designers of the device were wise to note that a cross-domain form submission could be made (encType = text/plain) that contains XML-formatted content, and thus they devised an anti-CSRF mechanism of rejecting requests that do not bear a proper SOAPAction header.  Such restriction properly blocks CSRF via HTML forms, but is put at risk if a cross-domain XHR request is able to send arbitrary headers.


Thanks again,

Eric Lawrence
Program Manager - IE Security

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.
>
>
>
>
>
> XDomainRequest (XDR)
>
>
>     Table of Contents
>
> 1.0   Summary
>
> 2.0   Background: /Overview of how XDR allows cross site requests/
>
> 3.0   API Documentation: /Lists the programming
> interface/methods/properties/
>
> 4.0   Security Model Flowchart: /Highlights the security checks that IE8
> makes for an XDR Request./
>
> 5.0   Sample Site and Script: /For developers wishing to create an XDR
> page./
>
> 6.0   Developer Benefits of using XDR: /Covers XDR's strengths by
> demonstrating XDR's goals of security and simplicity./
>
> 7.0   Developer Release Notes: /A short bulleted list of issues
> developers should we aware of when using the object and a summary of
> what XDR cannot do./
>
> 1.0 Summary
>
> /With* Cross Domain Request* *(XDR)* developers can create cross site
> data aggregation scenarios. Similar to the XMLHttpRequest object  but
> with a simpler programming model, this request, called XDomainRequest,
> is an easy way to make anonymous requests to third party sites that
> support XDR and opt in to making their data available across domains.
> Three lines of code will have you making basic cross site requests. This
> will ensure data aggregation for public sites such as blogs etc will be
> simple, secure and fast. XDR is an approach designed from the grounds up
> with a focus on security. We understand the current cross domain
> XMLHTTPRequest proposal and recognize its ability to provide a broader
> set of services particularly around declarative auditing for access
> control based scenarios and authenticated connections. It does however
> come at the risk of more complexity and surface area of attack. While
> these are certainly compelling scenarios we realize that existing
> implementations have bugs (linked 1
> <http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html>,
> 2 <https://bugzilla.mozilla.org/show_bug.cgi?id=389508>), some of which
> are resolved from the past like TOUCTOU and others like DNS Rebinding
> remain mostly unaddressed. In addition, maintaining configuration is
> challenging post deployment as Flash has encountered
> <http://blog.monstuff.com/archives/000302.html> (wildcarding) in the
> past. The IE team is not comfortable implementing a feature with a high
> surface area of attack and open/incoming security issues and proposes
> XDR as a safer alternative.///
>
>
>
> 2.0 Background
>
>
>
>
>
> Browsers enforce the same site origin policy, which blocks web pages
> from accessing data from another domain. Websites often work around this
> policy by having their server request content from another site's server
> in the backend, thus circumventing the check within the browser.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>       Text Box: Figure 1 - IE7 and below need to make a request to the mashup
> server which then needs to be proxied to the web server.
>
>
>
>
> In IE8 web pages can simply make a cross domain data request within the
> browser using the new /XDomainRequest/ object instead of a
> server-to-server requests.
>
> Cross domain requests require mutual consent between the webpage and
> server. You can initiate a cross domain request in your webpage by
> creating a /xdomainrequest /object off the window object and opening a
> connection to a particular domain. The browser will request data from
> the domain's server by sending a /XDomainRequest: 1 /header. It will
> only complete the connection if the server responds with a
> XDomainRequestAllowed header with the value "1" for true.
>
>
>
> For example, a server's asp page includes the following response header:
>
> Response.AppendHeader("XDomainRequestAllowed","1");
>
>
>
>
>
>
>
> *Security note: *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.
>
>
>
>
>
>
> 3.0 API Documentation
>
>
>
> * *
>
> *Methods*
>
> Once you create a xdomainrequest object, you can use the /open()/ method
> to open a connection with a domain's server. This method supports the
> GET and POST HTTP methods and takes the URL to connect to as a
> parameter. Once you've opened a connection, you can use the /send()/
> method to send a data string to the server for processing if needed. For
> example:
>
>
>
> // 1. Create XDR object
>
> xdr = new XDomainRequest();
>
>
>
> //2. Open connection with server using POST method
>
> xdr.open("POST", "http://www.contoso.com/xdr.txt")
>
>
>
> //3. Send string data to server
>
> xdr.send("data to be processed")
>
>
>
> XDR also has an /abort() /method to cancel an active request, which
> takes no parameters. Data is not available on an abort.
>
> * *
>
> *Properties*
>
> *         *responseText - *After the server responds, you can retrieve
> the data string through the read-only /responseText /property.
>
> *         *timeout - *You can use the /timeout /property to set or
> retrieve the number of milliseconds the browser should wait for a server
> to respond.   IE defaults to no timeout if this property is not
> explicitly set. If the request times out, data is not available.
>
> *         *contentType *- If you are posting data to the server, use the
> /contentType /property to define the content type string that will be
> sent to the server. If you are using a GET then this property will allow
> you to read the content type.
>
>
>
> *Events*
>
> XDR has the following events:
>
> *         *onerror* - this event fires when there is an error and the
> request cannot be completed. For example, the network is not available
>
> *         *ontimeout *- this event fires when the request reaches its
> timeout as defined by the above timeOut property. If the request times
> out data is not available.
>
> *         *onprogress -* this event fires while the server responds to
> the request by streaming data back to the browser.
>
> *         *onload *- this event fires when the cross domain request is
> complete and data is available.
>
>
>
> *Security note: *Cross domain requests can only be sent and received
> from a web page to URLs in the following IE zones. We discourage
> Intranet sites from making XDR data available to help prevent intranet
> data from leaking to malicious Internet sites.
>
>
>
>
>
>
>
>
>
>
>
> *Webpage equests data from a URL in the following zone:*
>
>
>
>
>
>
>
>
>
> Local
>
>
>
> Intranet
>
>
>
> Trusted (Intranet)
>
>
>
> Trusted (Internet)
>
>
>
> Internet
>
>
>
> Restricted
>
> *Webpage is in the following zone:*
>
>
>
> Local
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Block
>
> Intranet
>
>
>
> Block
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Block
>
> Trusted (Intranet)
>
>
>
> Block
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Block
>
> Trusted (Internet)
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Block
>
> Internet
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
>
>
> Allow
>
>
>
> Allow
>
>
>
> Block
>
> Restricted
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
>
>
> Block
>
> * *
>
> *Security note: *When using these XDR, safely handling data provided by
> another web application is a critical operation.
>
>
>
> For instance, the response could be parsed directly by Javascript, or it
> could be evaluated with a freely available JSON parser (see
> http://www.json.org/) or it could be inserted into a DOM as static text
> (using .innerText).
>
> * *
>
> * *
>
> * *
>
> *Server Side*
>
> The browser will request data from the domain's server by sending a
> /XDomainRequest: 1 /header. It will only complete the connection if the
> server responds with an XDomainRequestAllowed header with the value "1"
> for true.
>
> For example, a server's asp page includes the following response header:
>
> *Response.AppendHeader("XDomainRequestAllowed","1");*
>
> This can be done in IIS, for example, using an ASP.NET page. The line of
> code below can be embedded in your ASP page to return the header.
>
>
>
> *<<% Response.AddHeader  "XDomainRequestAllowed","1" %>Data*
>
> * *
>
> * *
>
> 4.0 Security Model Flowchart
>
> XDR Flowchart
>
> 5.0 Sample Site and Script
>
>
>
> Please refer to the AJAX Hands on Labs
> <http://code.msdn.microsoft.com/iemix08labs/Release/ProjectReleases.aspx?ReleaseId=590>
> on MSDN for demo script. This will need to be set up on your machine
> from the resource files.
>
>
>
> 6.0 Other Developer Benefits of Using XDR
>
> 1.        Simple development model.
>
> a.        On the server, the server operator must simply add one new
> header to his HTTP response indicating that cross-domain sources may
> receive the data.  HTTP Headers can be added by any CGI-style process
> (PHP/ASPNET/etc) or by the web server software (Apache/IIS/etc) itself.
>
> b.        On the client, the XDR object is all about
> cross-domain-requests.  Because XDR is a new object we are not forced to
> "bolt on" cross-domain security.  For example, XDR has no means of
> adding a custom header, because custom headers are dangerous for
> cross-domain security as the current web model does not expect a custom
> header being sent across domains. We've encountered experiences when web
> applications in the past if encountering a custom header using XHR
> assume it's coming from the same site.
>
>
>
> 2.        Provably secure
>
> a.        The XDR security model is simple.  The client sends a request
> that clearly identifies its cross-domain nature, and the server must
> respond in kind for the Same-Origin-Policy to be relaxed such that the
> client can read the response.  If the server does not set the response
> header (a "non-participating" server), the client script is not
> permitted to read the response or determine anything about the target
> server.
>
>
>
> b.        XDR is very tightly scoped to minimize the risk of increasing
> security exposure of the browser.
>
> 1.        Specifically, any request sent by XDR could also be emitted by
> a properly coded HTML FORM object.  Hence, any "non-participating" web
> server put at risk by XDR is also at risk from simple HTML.
>
>
>
> Note: The only additional exposure XDR adds is the ability of the client
> to set a specific Content-Type header.
>
>
>
> 2.        As XDR strips all credentials and cookies, it prevents even
> less attack surface for use in a Cross-Site-Request-Forgery (CSRF)
> <http://en.wikipedia.org/wiki/Cross-site_request_forgery> attack than a
> HTML Form.
>
>
>
> c.        XDR attempts to block cross-zone/protocol requests, an ASR
> which exceeds that undertaken elsewhere in the browser (e.g. SCRIPT SRC)
> due to compatibility concerns.
>
>
>
> 3.        Improved Access  Control "Locality"
>
> a.        Unlike policy file-based security, the XDR handshake is a part
> of the HTTP request and response.  This means that XDR is not at risk
> from DNS-Rebinding <http://en.wikipedia.org/wiki/DNS_rebinding> or
> Time-of-Check-Time-of-Use
> <http://en.wikipedia.org/wiki/Time-of-check-to-time-of-use> attacks.
>
> b.        Policy files must be located in a particular location on the
> server, which may cause operational problems for users with limited
> permissions on the server.  For example, consider the shared hosting
> case, where only one admin may write to the server root, but many users
> have permissions to write to sub-folders.  The users must petition the
> admin for an update to the policy file.
>
>
>
> 4.        Access-Control Flexibility
>
> a.        As Access-Control is based on a per-response basis, the server
> may choose to allow or deny access based upon any criteria desired.  For
> instance, Referer of client, time of day, number of requests per hour,
> etc, etc.
>
> b.        The XDR security model prevents attackers from easily
> determining the access control rules of the server.  The server may keep
> their rules as a trade secret.
>
>
>
> 7.0 Developer Release Notes
>
> *         Not yet available across browsers; not a W3C standard.
>
> *         Services must be explicitly coded to operate with XDR.
>
> *         As HTTP Methods are deliberately limited, standard REST-based
> interop is not possible.
>
> *         As credentials are not provided by the browser, the client
> must transmit them in the request body.  This typically should not be a
> problem but this could prevent use of the HttpOnly attribute on cookies
> that must be sent for credentials.
>
> *         The XDR handshake is HTTP-specific and cannot be directly
> translated for reuse in other protocols or situations (E.g. raw socket
> access).
>
>
>
>
>
>
>
> --
> *Sunava D*utta
> Program Manager (AJAX) - Developer Experience Team, Internet Explorer
>
> One Microsoft Way, Redmond WA 98052
> TEL# (425) 705-1418
>
> FAX# (425) 936-7329
>
>
>



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 Doug Schepers-3
Sure Doug. Will try to get this out to you in the mentioned format asap.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Doug Schepers
Sent: Friday, March 14, 2008 4:37 AM
To: Web API WG (public)
Subject: Re: IE Team's Proposal for Cross Site Requests


Hi, Sunava-

Could you please resend this as an HTML attachment, rather than as the
body of the email?  Many people use text-based email clients (I myself
normally view emails as text-only, though I can switch on HTML), making
this very hard to read.  It also looks crummy in the archives:

   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0096.html

Thanks-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI


Reply | Threaded
Open this post in threaded view
|

RE: IE Team's Proposal for Cross Site Requests

Sunava Dutta
The following is as an HTML attachment as requested.(I'm also including the resource folder as a .zip).
The Whitepaper is also another way to view the images and APIs.

http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=ie8whitepapers&ReleaseId=581


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Sunava Dutta
Sent: Friday, March 14, 2008 5:44 PM
To: Doug Schepers; Web API WG (public)
Subject: RE: IE Team's Proposal for Cross Site Requests

Sure Doug. Will try to get this out to you in the mentioned format asap.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Doug Schepers
Sent: Friday, March 14, 2008 4:37 AM
To: Web API WG (public)
Subject: Re: IE Team's Proposal for Cross Site Requests


Hi, Sunava-

Could you please resend this as an HTML attachment, rather than as the
body of the email?  Many people use text-based email clients (I myself
normally view emails as text-only, though I can switch on HTML), making
this very hard to read.  It also looks crummy in the archives:

   http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0096.html

Thanks-
-Doug Schepers
W3C Team Contact, SVG, CDF, and WebAPI



IE Team's Proposal for Cross Site Requests.htm (139K) Download Attachment
IE Team's Proposal for Cross Site Requests_files.zip (120K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: IE Team's Proposal for Cross Site Requests

Kris Zyp-4
In reply to this post by Maciej Stachowiak

> How does this compare to the Cross-Site Extensions for XMLHttpRequest
> standard
> that is being developed by Web API and Web App Formats (and
> as implemented in Firefox betas)?
The major ones, IMO:
1. XDomainRequest uses a different constructor/API to make requests
(XDomainRequest instead of XMLHttpRequest).
2. XDomainRequest does not allow any headers. The W3C/AC for XSite requests
allows headers like "Accept" and "Accept-Language" which are crucial for the
fundamental HTTP capability of content and language negotiation.
3. Completely different server side response required to validate cross-site
requests are acceptable. XDomainRequest looks for a response header of
"XDomainRequestAllowed: 1", while W3C/AC, looks for an Access-Control header
which has more fine-grained control.
4. Cookies and credentials are not sent with XDomainRequest. I believe this
is still being discussed with W3C/AC.
5. Standard HTTP REST methods (PUT and DELETE) are not supported with
XDomainRequest, but are supported with W3C/AC.


> From Apple's point of view we would like to have a
> unified standard in this area.
>From web developer/framework developer's point of view, we would also
like a unified standard. Creating a new divergent API for cross-site
requests with XDR is certainly not the most beneficial approach for web
developers. Cross-site requests that work in all browsers (those that
implement W3C/AC and XDR) would look like:
if (window.XDomainRequest) {
    var xhr = new XDomainRequest(); // IE's cross-domain request technique
}
else {
    var xhr = new XMLHttpRequest(); // W3C and standards compliant browsers
cross-domain request technique
}
xhr.open("POST","http://otherdomain.com",true);
xhr.send();

And on the server, the server needs to at least set headers
"XDomainRequestAllowed: 1" and "Access-Control: allow *" for the responses
to be accessible in all browsers.
Does this seem like a clean API for devs? I think it would be much cleaner
and easier for developers if Microsoft adopted the W3C cross-site request
mechanism and worked to improve it, rather than creating a different API.

snipping from Chris's email:
> The short version is, as Sunava discusses in the summary of this mail,
> that x-domain XHR (and Flash’s approach, et al) is subject to specific
> x-domain injection attacks because of its persistent-allow design.

I understand that MS has security concerns, but rewriting the API is not
necessary to address these concerns. If there are aspects of the W3C/AC
proposal that MS doesn't like, I am sure discussion and feedback would be
welcome. Even minor deviations from W3C/AC proposal to satisfy the Microsoft
security concerns (such as stripping cookies, and requiring the
Access-Control header on every response) would be vastly better than using a
completely different API. I think the web development community would
appreciate standards convergence much more than multiple APIs. Having
multiple APIs increases complexity which increases the vector of possible
attacks.

> Specifically, any request sent by XDR could also be emitted by a
> properly coded HTML FORM object.  Hence, any “non-participating”
> web server put at risk by XDR is also at risk from simple HTML.

This is not true. I could send a POST request with XDR with a body of any
string. This is not possible in a form. A form strictly encodes everything
in URL encoded format. A server that expects that a body with pure JSON
would only come from a safe client (since this is not possible with a form),
would be in for a surprise with XDR. W3C/AC protects against this
vulnerability. IMO, this is a vulnerability and XDR may actually be
less secure than W3C/AC (and certainly less funtional).

Thanks,
Kris


1234 ... 7