Re: IE Team's Proposal for Cross Site Requests

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

Received on Friday, 14 March 2008 18:00:07 UTC