Firefox security guidelines
Purpose
This document outlines a set of security guidelines that will generally apply to all client applications, such as Firefox and Thunderbird.
Secure Coding Principles
Ensure that the application follows theOWASP Secure Coding Principles:
- Minimize attack surface area
- Establish secure defaults
- Principle of Least privilege
- Principle of Defense in depth
- Fail securely
- Don't trust services
- Keep security simple
- Fix security issues correctly
Input Validation
Does the application accept user input?
- Verify a sampling of input locations to ensure that reasonable maximums are in place when accepting user data
- Verify a sampling of input locations to ensure that the application allows only a defined set of acceptable characters
- Ensure that allowlisting is used instead of denylisting
Does the application accept user input that is displayed in any way?
- Verify a sampling of input and output locations to ensure user supplied content is properly encoded in the response
Chrome JS - Dangerous Functions
Are any of the following functions used?
If so ensure they are safe and that no better alternatives are available.
| Name | Risk Level | Problem | Solution |
|---|---|---|---|
| eval | Very High | Invokes JavaScript parser - dangerous if used with untrusted input | Avoid eval if at all possible. |
| setTimeout(string, time) | Very High | Acts like eval | Use setTimeout(function, time, param1, param2, …) |
C++ - Dangerous Functions
Are any of the following functions used?
If so ensure they are safe and that no better alternatives are available.
| Name | Risk Level | Problem | Solution |
|---|---|---|---|
| gets | Very High | No bounds checking | Do not use gets. Use fgets instead. |
| strcpy | Very High | No bounds checking | strcpy is safe only if the source string is a constant and the destination is large enough to hold it. Otherwise, use strncpy. |
| sprintf | Very High | No bounds checking, format string attacks | sprintf is very hard to use safely. Use snprintf instead. |
| scanf, sscanf | High | Possibly no bounds checking, format string attacks | Make sure all %-directives match the corresponding argument types. Do not use '%s' directives with no bounds checking. Use '%xs' where x is the buffer size of the corresponding argument. Do not use untrusted, un-validated data in the format string. |
| strcat | High | No bounds checking | If input sizes are not well-known and fixed, use strncat instead. |
| printf, fprintf, snprintf, vfprintf, vsprintf, syslog | High | format string attacks | Do not use untrusted, un-validated data in the format string. If the format string can be influenced by Web content or user input, validate it for the proper number and type of %-directives before calling these functions. Make sure destination size arguments are correct. |
| strncpy, fgets, strncat | Low | May not null-terminate | Always explicitly null-terminate the destination buffer. Make sure the size argument is correct. Be sure to leave room in the destination buffer to add the null character! |
URLs
Does the application make use of untrusted data to construct URLs?
- Ensure any such data is adequately sanitized and encoded prior to use.
- Ensure any data obtained from these URLs is checked before use or storage.
Does the application follow redirects?
- Ensure security checks are performed on redirects as well as the original request URI.
Security Controls
- Does the application implement suitable permission checks?
- Ensure the correct APIs are used where available (e.g., shouldLoad, etc.)
- Ensure the application fails securely.
Remote System Access
- Does the application access any remote systems?
- Ensure that TLS is used unless there's avery good reason not to.
- Ensure that no user information is transmitted without the user's consent.
Information Storage
File storage
Ensure the application checks that any files created are under allowed paths
Are filenames generated from untrusted data?
- Ensure the data is suitably encoded
Check files are of an acceptable type
Check files cannot exceed reasonable size limits
Database storage
- Ensure any untrusted information sent to the database is adequately sanitized
- Where possible, make use of type safe parameterization to prevent injection attacks
Sensitive information
- Ensure any security sensitive or personal information is adequately protected (see Encryption section)
- Particular care must be taken around credentials (passwords, etc.) - If you're working with information of this type and you're unsure of what to do, it's always worth asking
Logging
- Don't forget the above rules apply to logs as well as your usual application data
Encryption
- Does the application use any form of encryption?
- Are the algorithms used recognized standards?
Denial of Service
- Ensure the application protects against exhaustion of:
- System memory
- Storage
Security Warnings
Does the application present the user with any security warnings?
Are they clearly understandable and appropriate?
Can untrusted data change the meaning of messages to the user?
- Can user input change the meaning of messages?
- Can user input force system messages off the visible screen?
- Can user input include special characters that can change the meaning of messages (e.g., Unicode right-to-left override U+202E)
Can an attacker use the timing of dialogs to fool the user into clicking on something they didn't intend to?
Information Disclosure
- Does the application disclose information that could compromise the user?
- Does the application disclose any information that it does not need to?
- Does the application disclose anything that may surprise or upset the user?
Front End
Are safe mechanisms used to create XUL and HTML UI elements?
- e.g., use createTextNode instead of innerHTML or similar
Does the application create its own docshells (tabs, iframes)?
- Ensure you are explicit about the type of these, e.g., iframe.setAttribute("type", "content")