W3C home > Mailing lists > Public > public-webapi@w3.org > March 2008

Re: IE Team's Proposal for Cross Site Requests

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 14 Mar 2008 13:24:52 -0700
Cc: Chris Wilson <Chris.Wilson@microsoft.com>, "Web API WG (public)" <public-webapi@w3.org>, Eric Lawrence <ericlaw@exchange.microsoft.com>, Zhenbin Xu <zhenbinx@windows.microsoft.com>, Gideon Cohn <gidco@windows.microsoft.com>, Sharath Udupa <Sharath.Udupa@microsoft.com>, Doug Stamper <dstamper@exchange.microsoft.com>, Marc Silbey <marcsil@windows.microsoft.com>
Message-Id: <A76FA9E6-74AE-4971-A4B2-FB1E065FCBAB@apple.com>
To: Jonas Sicking <jonas@sicking.cc>


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
>>
>
>
Received on Friday, 14 March 2008 20:25:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 14 March 2008 20:25:31 GMT