Re: IE Team's Proposal for Cross Site Requests

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: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 21:43:59 UTC