RE: IE Team's Proposal for Cross Site Requests

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:mjs@apple.com]
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
>>
>
>

Received on Friday, 14 March 2008 20:37:04 UTC