Security/ReviewTopics

From MozillaWiki
Jump to navigation Jump to search

These are some questions we might ask during a security review.

Security

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?
    • Do your tests include both should-be-allowed and should-be-disallowed cases?
  • 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?

Privacy

  • Does the feature expose information that could strengthen fingerprinting?
  • Does the feature cache or store data that could strengthen super-cookies?
  • How are transitions in/out of Private Browsing mode handled?
  • How is "Clear Recent History" handled?

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?

C and C++

  • Did you minimize and isolate use of low-level constructs (manual allocation, manual refcounting, union tricks such as bit-stealing, and pointer arithmetic)?
  • Does your code build without warnings?
  • Are new C++ classes annotated for Mozilla's dehydra analyses?
  • Do you use CheckedInt where integer overflows could be an issue?
  • Does the code use assertions to make it easier to catch bugs?
  • Are the safety-critical invariants documented?
  • What would make you more confident in the code's safety?
  • When calling scripts (or firing events), is it safe to run scripts? Are you holding any raw pointers that might disappear on you? (Smaug's area of expertise)