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 the OWASP 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 a very 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")