Security/Reviews/Firefox4/mozGetAsFile Security Review

From MozillaWiki
Jump to: navigation, search

Overview

Provide a method to extract a file from a canvas element.

Background links
  • Bug 583863 - Refactor HTML input implementation to work with "files" that aren't on the disk.
  • Bug 565843 - Implement canvas.mozGetAsFile

Security and Privacy

  • Is this feature a security feature? If it is, what security issues is it intended to resolve? No
  • What potential security issues in your feature have you already considered and addressed? Untrusted content is allowed to specify the file name, which means that privileged code cannot trust the file name of a File object unless it knows where it originated (in other words, a webpage could create a file with the name 'etc/passwd'). The only code that looks at the filename is sessionstore which is only looking at file names that are trusted (files that originated in an <input> element). The safe way to read a file is to use the FileReader object or the methods on the File object which will do The Right Thing TM.
  • Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing? No
  • Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. Almost all of the code is shared with canvas.toDataUrl and the existing File object implementation. The only potential issue that I'm aware of is the filename stuff discussed above.
  • How are transitions in/out of Private Browsing mode handled? Not relevant

Exported APIs

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

<canvas>.mozGetAsFile() (nsIDOMHTMLCanvasElement)

  • Does it interoperate with a web service? How will it do so? No
  • Explain the significant file formats, names, syntax, and semantics. n/a
  • Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully? They will be
  • Does it change any existing interfaces? Yes, nsIDOMFile

Module interactions

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

Data

  • What data is read or parsed by this feature? The pixel contents of a canvas
  • What is the output of this feature? A DOMFile containing the contents of a <canvas>
  • What storage formats are used? The existing image encoders are used

Reliability

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

Configuration

  • Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables? No
  • Are there build options for developers? [#ifdefs, ac_add_options, etc.] No
  • 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? No, though hopefully this feature will be standardized eventually

  • 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