Firefox3.1/XS-XHR Security Review

Overview

Describe the goals and objectives of the feature here.

Background links

• {bug|389508} tracks the implementation.
• Access Control specs the security model.

Security and Privacy

• Security concerns:
  • Want to protect "private" resources, both reading and writing to them. "Private" resources are for example resources behind firewalls, and resources that are protected by authentication or session cookies.
  • In many cases just sending a request to a server can cause harm, even if the response can't be accessed. It should not be possible to send any requests that aren't already possible, unless the server first opts in.
  • Users private data residing on servers need to be protected from being read by other sites.
  • We want to protect against accidental data leakage by servers that are configured to share more data than they intended. I.e. minimize risk of misconfiguration resulting in sharing too much data.
  • Should be secure even in the face of proxies sitting between the server and the user and possibly cache requests.
  • Should be easy to deploy securely on commonly used servers.
  • See also requirements section in the spec: [1]
• prefs.js holds preferences for disabling the feature. If that file gets corrupted the feature might get reenabled even if the user has disabled it.
• Assumptions:
  • Servers are secured against requests that are already possible using HTML today. This is known not to always be the case today, this results in CSRF attacks. XS-XHR should not make these attacks worse.
  • Servers which the user has given his/her private data is responsible and ask the user before sharing that data with 3rd parties. I.e. that users don't give their private data to servers they don't trust to keep that data private according to the users wishes. This has been a highly contagious issue within mozilla and consensus was not reached if this is a valid assumption.
• Risks
  • Servers share data without asking the user
  • Servers are misconfigured resulting in the server being exploitable.

Exported APIs

• External
  • The Access-Control spec defines an API for the server to flag that data can be read by a third party, and flag that requests to a certain URI is allowed from a given domain, using a specified set of HTTP methods and HTTP headers.
  • The XMLHttpRequest object gets a new boolean flag indicating if the request should be attempted with or without cookies.
• Internal
  • nsCrossSiteListenerProxy implements the Access-Control spec to allow reuse elsewhere inside gecko. Currently not usable from extensions but might be in the future.

Module interactions

• Mostly interacts with the necko code set request headers and read response headers. The actual data is never inspected but rather just passed through to consumer.
• Interaction with the consumer, in this case XMLHttpRequest, is done mostly by either simply passing data through, or by raising an NS_ERROR_DOM_BAD_URI error.

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?