Firefox/Projects/AccountManager/SecurityReview

From MozillaWiki
Jump to: navigation, search

Overview

From the project page:

The Account Manager project aims to help users manage the (currently manual and tedious) process of signing up/in/out of sites by adding chrome-level status and knobs to give the user a consistent point to view and control of sign-in status to the current site.

Example use-case from the specification:

A web browser visits a new site. The site advertises to the browser that account management features are available. The browser user requests "connection" to the site. The browser negotiates account setup, possibly disclosing some personal information about the user, and learns a userid-credential pair. On a subsequent visit, the browser notices that it does not have an active session, and automatically establishes one. When the user requests "disconnection" from the site, the browser terminates the session. When the user views a "my accounts" page in his browser, she sees what information the site is storing about her.

Generally speaking, the protocol defines two things

  1. How to determine status--that is, who is signed in.
  2. How to discover capabilities--that is, what does the site support and how does it work.

With these two pieces the user-agent can present UI to the user to allow them to control their identity on each site.

Background links

Security and Privacy

  • Is this feature a security feature? If it is, what security issues is it intended to resolve?

It's not a security feature per se, but it does have strong ties to security. Account Manager is intended to abstract out how sites deal with authentication, and in so doing make it possible for authentication components to be swapped in later (as opposed to the status quo of being married to web forms).

  • What potential security issues in your feature have you already considered and addressed?

Please see the Security Considerations section of the Account Manager specification.

  • Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?

There are no preferences or configuration files.

  • Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.

The Security Considerations section of the specification contains possible attack vectors for the feature.

  • How are transitions in/out of Private Browsing mode handled?

We don't do anything in particular right now.

Possibly we might need to disable the feature. Passwords are kept in the Password Manager, so it's possible the feature will be halfway-disabled anyway.

Exported APIs

  • Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)

Various javascript modules into resource://gre/modules/accountmanager

  • service.jsm API for getting realms from the UI
  • profiles.jsm provide a way to register new account types
    • Also provides abstract parent classes for profiles to implement
    • savedAccountCount, savedAccounts, createAccount, connect, disconnect
  • base.jsm parent class sharing helper functions
  • cache.jsm simple fifo cache
  • hostmeta.jsm fetch and cache host metas for sites
  • linkHeaderParser.jsm parse Link headers
  • realms.jsm fetch and cache amcd for sites
  • statusParser.jsm parse account status headers
  • userPassFormProfile.jsm handle username/password accounts (server and local)
  • Does it interoperate with a web service? How will it do so?

Interacts with websites that provide AMCD and status headers, but not with any particular web service

  • Explain the significant file formats, names, syntax, and semantics.

AMCD describes to the browser how to connect/disconnect/get status and how to respond on success/failure, e.g., load a url

  • AMCD is a JSON file described in the spec

HTTP X-Account-Management-Status: Status headers are comma and semicolon separated values describing each account and parsed with a custom parser

HTTP Link: <uri>; rel="acct-mgmt": Link headers are defined with Web Linking standard and parsed with a custom parser

  • Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?

For website-facing changes, documentation is in the spec and blog examples. For Firefox add-on facing api, not so much except existing code as a template, but we're not heavily pushing this yet.

  • Does it change any existing interfaces?

No, but additional columns are added to the Password Manager database

Module interactions

  • What other modules are used (REQUIRES in the makefile, interfaces)?

Necko WebProgressListener to track tab document requests, redirects and headers

Resource.jsm for network GET/PUT/POST (similar to sync)

Password Manager for storing/getting username/password accounts

PopupNotifications for showing UI and handling interactions

Data

  • What data is read or parsed by this feature?

host-meta xml document, AMCD JSON, status/link headers

  • What is the output of this feature?

UI in the location bar and door-hanger notifications for the user to interact with

  • What storage formats are used?

Necko cache for host-meta, AMCD, status documents

Password manager for saving accounts

Reliability

  • What failure modes or decision points are presented to the user?

The feature is extensible (different authentication methods may be defined and implemented within Account Manager). Generally speaking, however, the specification includes a provision for an onfailure handler which may be defined for most methods. This handler (a mirror of the onsuccess handler) may define one of several actions:

  • none: do nothing
  • reload (the default): reload the current page
  • load-url: load a specific url
  • js-event: create a js event which the current page can listen to

See Method Status Actions for details.

  • Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

The feature depends on other components which have files (e.g., the Password Manager), but has no files of its own.

Configuration

  • Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?

There are preferences to enable debugging output to stdout/error console. No other prefs are used.

  • Are there build options for developers? [#ifdefs, ac_add_options, etc.]

No.

  • What ranges for the tunable are appropriate? How are they determined?

Debugging output prefs are boolean.

  • What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

None.

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?


There are plenty of auth-related technologies out there. A few pertinent ones:

  • HTTP Auth

There is an HTTP Auth profile, although it is not currently implemented. The profile makes additional requirements on top of HTTP Auth (e.g., there must be an AMCD).

  • OpenID/OAuth/Other federated

There is a federated ID profile, similar to the HTTP Auth case.

  • InfoCards/CardSpace

An attempt at replacing the auth stack with something else. Much more heavy-handed approach. Not compatible with AM.

Review comments

  • Link: header URI whitelisted to http/https
  • Link: header URI might itself be an attack link. Is it any worse than <img src=uri>?
  • Link: header might log you into some unrelated site
    • phishing potential if chrome looks "signed in"? (e.g. "There's a problem, please confirm your password")
    • make sure someone's logged into a victim site as a preface to another CSRF attack?
  • If site is HTTPS then AMCD URI must be HTTPS (current code doesn't enforce this)
    • what do we do if it's not?
  • If site is HTTP then AMCD can be HTTP or HTTPS (but of course https is recommended)
  • Don't trust x-acct-mgmt-status unless the user actually has an account for that realm
    • pages might have x-acct-mgmt-status header and no AMCD! (Link: or host-meta)
  • What character set is the x-acct-mgmt-status? Easiest to just treat it as utf-8
  • in the <XRD> the link tag can have a path. path is a substring, but must end in a '/' or else a '/' is assumed at the end.
  • AMCD has various "path" fields, but they're really full URIs potentially. Should be renamed to uri/url and allow/recommend relative paths (truth in advertising?).
  • currently no domain sanity checked in the AMCD uris. We do want mail.yahoo.com to be able to point to login.yahoo.com, but we don't really want it pointing at evil.com. For now leaving it up to sites to not be idiots.
    • maybe we should be stricter if the AMCD is itself loaded over HTTP. Since it could be injected then maybe the AMCD has to be at the same host as gave us the Link: header (or host-meta), and the various paths/urls in the HTTP AMCD must also be on the same host. If everything is SSL (the original site, the AMCD realm, and the paths) then we can trust the data.
Retrieved from "https://wiki.mozilla.org/index.php?title=Firefox/Projects/AccountManager/SecurityReview&oldid=250419"