Firefox/Projects/AccountManager/SecurityReview: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 50: Line 50:
** AMCD describes to the browser how to connect/disconnect/get status and how to respond on success/failure, e.g., load a url
** 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
** AMCD is a JSON file
** Status headers are comma and semicolon separated values describing each account and parsed with a custom parser
** Link headers are defined with [[https://datatracker.ietf.org/doc/draft-nottingham-http-link-header/ 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?
* Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?

Revision as of 21:44, 31 August 2010

Overview

Describe the goals and objectives of the feature here.

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
  • 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
    • Status headers are comma and semicolon separated values describing each account and parsed with a custom parser
    • 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?
  • Does it change any existing interfaces?

Module interactions

  • What other modules are used (REQUIRES in the makefile, interfaces)?
    • 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?
  • What is the output of this feature?
  • What storage formats are used?

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

Review comments