|
|
| (10 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| = Security Review Pre-Work =
| | ;Items to be reviewed: |
| Please fill our the short section below prior to the review, and make sure you contact security@mozilla.org to schedule your actual review.
| |
|
| |
|
| == Overview == | | == Introduce Feature (5-10 minutes) [can be answered ahead of time to save meeting time]== |
| ''Describe the goals and objectives of the feature here.''
| | === Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)=== |
|
| |
|
| ;Background links
| | === What solutions/approaches were considered other than the proposed solution?=== |
| * feature-tracking bug links
| |
| * public specifications (RFC's, W3C specs, IETF Drafts, etc)
| |
| * design docs or internal specifications
| |
| * data flow or entity relation diagrams
| |
| * links to other implementations of the feature
| |
|
| |
|
| == Threats == | | === Why was this solution chosen?=== |
| ''Please list the top 3 security threats you have considered during the design and implementation of this feature.'' Consider attack points as well as code that feels fragile.
| |
|
| |
|
| * Threat 1
| | == Any security threats already considered in the design and why?== |
| * Threat 2
| |
| * Threat 3
| |
|
| |
|
| What mitigations have you implemented?
| | == Threat Brainstorming (30-40 minutes)== |
| ----
| |
|
| |
|
| = Topics To Discuss During The Review = | | == Conclusions / Action Items (10-20 minutes)== |
| Please be prepared to discuss the following topics as they relate to your feature / project. To the degree you can answer some of these questions prior to the review it will speed up the process, but its not a requirement.
| |
| | |
| == Security and Privacy ==
| |
| Provide a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
| |
| | |
| * Is this feature a security feature?
| |
| ** If it is, what security issues is it intended to resolve?
| |
| * How are transitions in/out of Private Browsing mode handled?
| |
| * Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
| |
| * If any content or UI is displayed to the user, in what context is that content presented? Does it have chrome privileges, for example?
| |
| * Does the feature include any new cryptographic functions or other security-critical code?
| |
| ** Has this code been reviewed and verified by someone familiar with the theory or principles behind it?
| |
| | |
| == Exported APIs ==
| |
| Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc).
| |
| Explain the significant file formats, names, syntax, and semantics.
| |
| | |
| * Does it interoperate with a web service?
| |
| ** How will it do so (by which protocols or techniques)?
| |
| * Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
| |
| * Does it change any existing interfaces?
| |
| | |
| == Module/Library interactions ==
| |
| * What other modules are used (REQUIRES in the makefile, interfaces)?
| |
| * What third-party libraries are used (.so, .dll, source code libraries/modules, etc)?
| |
| ** Have these third-party sources been reviewed for security?
| |
| ** How will we keep up-to-date with upstream?
| |
| | |
| == Data ==
| |
| * What data is read or parsed by this feature?
| |
| ** What types of validation are done on data inputs (e.g., type checking, string decoding/encoding, etc.)?
| |
| * What is the output of this feature?
| |
| ** What types of normalization or sanitization are performed on data outputs (e.g., data aggregation, string encoding, path canonicalization, etc)?
| |
| * What storage formats are used?
| |
| ** Who can access the data in storage (for example: is it encrypted with a master password, obfuscated, packed, protected by a filesystem ACL, etc)?
| |
| | |
| == Reliability ==
| |
| * What failure modes or decision points are presented to the user?
| |
| * Can its files be corrupted by failures? Does it clean up any locks/files after crashes?
| |
| | |
| == Configuration ==
| |
| * Can the end user configure settings (via UI, about:config, or environment variables)?
| |
| * Are there build options for developers (e.g. #ifdefs, ac_add_options)
| |
| * 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 = | |
| ''Notes made during the review will be recorded here.''
| |