User:Sicking/Cross Site XHR Review

Status

Feature tracking bug

• bug 389508

Initial review was done here: Cross_Site_XMLHttpRequest

Landed for alpha7. Has received updates since to account for changes to the spec.

Spec available here: [1]

Overview

Cross-Site XMLHttpRequest allows a web page to read information from other web servers using norm XMLHttpRequest. In the past this has not been permitted since the other server may be sitting inside a corporate firewall or may be a server where the user is logged in.

To solve this problem it is suggested that the accessed server can signal back to the browser that it is ok for other sites to access certain pages on the server. Firefox checks for this and only returns the response to the page if the server explicitly allows it. Otherwise the browser will throw away the response from the server and throw an exception.

Use Cases

• If a server foo.example.org implements a simple REST API to create, delete and modify resources Access Control could be used to let a nice editing application on server editing.invalid store the results of the editing actions on foo.example.org.
• XBL binding allows full access to the binding document cross-site XBL usage is prevented. Access Control enables cross-site XBL bindings. If the user is authenticated with the server that hosts the XBL widget it is possible to have a user-specific cross-site bindings.
• To prevent data theft, from e.g. intranets, cross-site XSLT usage is not possible. With Access Control several domains are able to share XSLT resources in a cross-site fashion.
• If you have a Web application that fetches resources (e.g. RDF) from around the Web to extract data out of them Access Control could be used to fetch them using a single request if the resource enables cross-site access.

Requirements

Biggest concern is security. Both for the server and for the users private data. A full list of requirements available at [2]

Schedule

Shedule for implementation is that we're mostly done. Biggest problem is having to keep up with changes to the spec. Lagging behind one major feature, bug 416957.

UI Design Documentation

Feature doesn't have any UI.

Design Impact

Security and Privacy

• What security issues do you address in your project?
  • Should not share data unless the server explicitly opts in to it.
  • Should not perform unsafe requests to the server without the server explicitly opting in to it.
• Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
  • So far does not use any configuration files.
  • We might want to add a pref to turn off all cross-site requests.
• Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
  • We do send authentication credentials and cookies when making requests to the remote site. These are the auth credentials and cookies for *that* site, not for the site making the request.
    • Results of this discussed here [3].

See the #Requirements section

The security issues raised last review listed at Cross_Site_XMLHttpRequest

Some things have changed since then:

• The initial check for if it's ok to do a unsafe (i.e. POST, DELETE etc) is done using OPTIONS rather than GET.
• It is now possible to apply the same policy to multiple files. This is done using the Access-Control-Policy-Path header to point to a parent directory. An OPTIONS request is done to that directory which can signal that its policy apply to all resources inside that directory.
• It is no longer possible to specify that only specific unsafe methods are allowed. The server will have to deal with all or not support any unsafe methods.
  • XMLHttpRequest still will block methods that are unsafe for anyone, such as CONNECT and TRACE.
• The deny rule has been removed. This means that there is no way for someone putting a resource on a server that allows sharing, to specify that sharing should not be allowed for this one resource.

Exported APIs

• Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
  • There are no exported APIs planned for this feature in FF3. Might want to expose the implementation at a later point to allow other code to use the access-control spec.
  • No new UI. Only UI is standard "enter password" dialog.
• Does it interoperate with a web service? How will it do so?
  • Yes, as described above.
• Explain the significant file formats, names, syntax, and semantics.
  • Formats for headers described here [4]

Web Compatibility

• Does the feature had any impact on Web compatibility?
  • New feature so should not affect existing content.

Performance

• How will the project contribute (positively or negatively) to "perceived performance"?
  • No performance impact to existing content.
  • Very little performance impact on cross-site GET requests as checking for headers and processing-instruction is negligible compared to network traffic time.
  • Unsafe cross-site requests will be slower than same-site due to the additional OPTIONS request. However the OPTIONS request can be cached. It can also be applied to whole trees to avoid overhead when multiple URIs are accessed.
• What are the performance goals of the project? How were they evaluated? What is the test or reference platform and baseline results?
  • Performance of implementation hasn't been tested yet, but should be minimal. No impact expected to existing content.
• Will it require large files/databases (for example, browsing history)?
  • No.

Reliability

• What failure modes or decision points are presented to the user?
• Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

l10n and a11y

• are any strings being changed or added?
• are all UI elements available through accessibility technologies?

Installation, Upgrade/Downgrade/Sidegrade, and platform requirements

• Does it equally support all Tier-1 platforms?
• Does is have a hardware requirement (or increase minimum requirements)?
• Does it require changes to the installer?
• Does it impact updates?
• list the expected behavior of this feature/function when Firefox is upgraded to a newer minor release, downgraded by installation of an earlier revision, or re-installed (same version)

configuration

• Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
• Are there build options for developers? [#ifdefs, ac_add_options, etc.]
• What ranges for the tunable are appropriate? How are they determined?
• What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

Relationships to other projects - are there related projects in the community?

• If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?
• Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?

Documentation

• Do built-in Help pages need modified?
• Documentation for developer.mozilla.org?

Other

any other implementation or design related documentation

Discussion & Implications

Risks Identified During 2/12/2008 Security Review

• Cross Site XHR, as currently specified, only requires an agreement between two websites. Ideally, the agreement would also include the client (browser). This could take the form of having the browser prompt the user when a site wants to make a XSXHR on their behalf.

• allowing sites to specify "all hosts" as able to send XSXHR may result in web developers using this as their default setting.
  • this would enable the most functionality, but developers might not see or understand the risks.
  • a series of high-profile attacks against sites using this functionality may lead to a backlash against the feature and may lead to large numbers of people disabling it altogether

• sending cookies, by-default, with "non-safe" requests.
  • many of the risks that are associated with allowing cross-site XHR, e.g. Cross-Site Request Forgery, can be mitigated by not sending cookies with these requests
  • sites will still want to be able to exchange private data via XSHXR, so they may implement their own non-cookie authentication mechanisms
  • this could include sites asking users to provide their login credentials for other sites to enable authenticated XSXHR, not necesarilly something we want to encourage

• Jonas concerned that sites will assume and come to rely upon browsers not sending cookies with cross-site requests, which could lead to problems if we ever decide to start sending 3rd party cookies by default

• Check to make sure that no-one uses the URI of a document to do security checks. Consider changing the document URI to something safer. Grep extensions for checksameorigin.

• We should not send cookies and auth headers.

• Should look into DNS rebind attacks.
  • Doesn't seem to allow any attacks that aren't already possible.

• access-control-origin can be set by old browsers for same-site requests. Might be interesting to do for sites that serve different content based on access-control-origin.

• GET requests can be cached, should send 'Vary: access-control-origin'. Does our cache honor the vary header? Sites needs send this header if they do depend on access-control-origin.

• Does overridemimetype make it possible to treat things as XML though they aren't.

• Many sites are probably going to treat OPTIONS as POST by doing "if method != get { ... }". However you can't include a body so the harm should be very limited.

• An alternative to the current OPTIONS algorithm would be to ask top down. This would require a lot more OPTIONS requests. One alternative would be to check all parent directories and use the most permissive rule. This would make results consistent, but more permissive.

Caveats / What We've Tried Before

links to previous design documents, discussions, etc.

References

links to external documents that could inform the design of the feature