Firefox3.1/XS-XHR Security Review

Overview

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

• There will be a global pref to turn off the feature entirely (all cross site requests will be denied).
• Considering adding a API for extensions to allow the user to ask whenever data is being transferred cross site.

Review comments

• are the Access-Control-Request-Headers and -Methods headers sanitized? We don't want bogus header and method names to create extra or malformed headers. setRequestHeader() and open() should reject anything that doesn't match a strict set (no spaces, no colons, no control chars, etc).
• IE's XDR adds a random delay for failure cases to prevent timing attacks. Even if you can't read the data (the server doesn't return the Access-Control headers) you could use a timing attack to see if a user has access to some resource. Do we need something like that?
• OPTIONS pre-flight request does not contain cookies.
• Not supposed to send "credentials" unless the client script opts in and not supposed to allow client to read response unless the server responds with the Allow-Credentials: true header. But how do we suppress auth headers?
• Need to test for cache attacks:
  • force logged-in user to load resource (iframe, img)
  • request resource using cookie-less XS-XHR
  • read cached value.
• need to add the cache issue to the spec
• "Access-Control-Allow-Origin: *" is dangerous if there's a caching proxy in the path and it's not public data. Specifying an origin will fail in a safe way if the server forgets to say Vary: Origin.

• Should make sure that only valid headers and methods are put in Access-Control-Request-(Method/Headers).
• Should prevent timing attacks to search for servers.
• Spec should mention that cookie-less requests need to be cached separately from cookied requests.