Re: IE Team's Proposal for Cross Site Requests

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

Received on Friday, 14 March 2008 18:25:38 UTC