Confirmed users
529
edits
Security/FirefoxOperations: Difference between revisions
Jump to navigation
Jump to search
no edit summary
m (fix unsupported tag) |
No edit summary |
||
| Line 97: | Line 97: | ||
* Developers should [configure git to sign all tags](http://micropipes.com/blog//2016/08/31/signing-your-commits-on-github-with-a-gpg-key/) and upload their PGP fingerprint to https://login.mozilla.com | * Developers should [configure git to sign all tags](http://micropipes.com/blog//2016/08/31/signing-your-commits-on-github-with-a-gpg-key/) and upload their PGP fingerprint to https://login.mozilla.com | ||
* The signature verification will eventually become a requirement to shipping a release to staging & prod: the tag being deployed in the pipeline must have a matching tag in git signed by a project owner. This control is designed to reduce the risk of a 3rd party GitHub integration from compromising our source code. | * The signature verification will eventually become a requirement to shipping a release to staging & prod: the tag being deployed in the pipeline must have a matching tag in git signed by a project owner. This control is designed to reduce the risk of a 3rd party GitHub integration from compromising our source code. | ||
* [ ] | * [ ] enable security scanning of 3rd-party libraries and dependencies | ||
* Use [ | * Use [`nsp check`](https://nodesecurity.io/) for node.js (see usage in [FxA](https://github.com/mozilla/fxa-customs-server/search?utf8=%E2%9C%93&q=nsp&type=) and [screenshots](https://github.com/mozilla-services/screenshots/search?utf8=%E2%9C%93&q=nsp&type=)) | ||
* For Python | * For Python, enable pyup security updates: | ||
* Add a pyup config to your repo (example config: https://github.com/mozilla-services/antenna/blob/master/.pyup.yml) | * Add a pyup config to your repo (example config: https://github.com/mozilla-services/antenna/blob/master/.pyup.yml) | ||
* From the "add a team" dropdown for your repo | * Enable branch protection for master and other development branches. Make sure the approved-mozilla-pyup-configuration team *CANNOT* push to those branches. | ||
* | * From the "add a team" dropdown for your repo /settings page | ||
* Add the "Approved Mozilla PyUp Configuration" team for your github org (e.g. for [mozilla](https://github.com/orgs/mozilla/teams/approved-mozilla-pyup-configuration) and [mozilla-services](https://github.com/orgs/mozilla-services/teams/approved-mozilla-pyup-configuration)) | |||
* Grant it write permission so it can make pull requests | |||
* notify secops@mozilla.com to enable the integration in pyup | |||
* [ ] Keep 3rd-party libraries up to date (in addition to the security updates) | |||
* For NodeJS applications, use [renovate](https://renovateapp.com/) or [GreenKeeper](https://greenkeeper.io/ Greenkeeper) | |||
* For Python, use ``pip list --outdated`` or [requires.io](https://requires.io/) or pyup outdated checks | |||
* For Rust, use `cargo update` and [cargo upgrade](https://github.com/killercup/cargo-edit#cargo-upgrade) when changing versions | |||
* [ ] Integrate static code analysis in CI, and avoid merging code with issues | * [ ] Integrate static code analysis in CI, and avoid merging code with issues | ||
* Javascript applications should use ESLint with the [Mozilla ruleset](https://developer.mozilla.org/en-US/docs/ESLint) | * Javascript applications should use ESLint with the [Mozilla ruleset](https://developer.mozilla.org/en-US/docs/ESLint) | ||
| Line 141: | Line 147: | ||
* Store session keys server side (typically in a db) so that they can be revoked immediately. | * Store session keys server side (typically in a db) so that they can be revoked immediately. | ||
* Session keys must be changed on login to prevent session fixation attacks. | * Session keys must be changed on login to prevent session fixation attacks. | ||
* Session cookies must have HttpOnly and Secure flags set. | * Session cookies must have HttpOnly and Secure flags set and the SameSite attribute set to 'strict'. | ||
* For more information about potential pitfalls see the [OWASP Session Management | * For more information about potential pitfalls see the [OWASP Session Management Cheat Sheet](https://www.owasp.org/index.php/Session_Management_Cheat_Sheet) | ||
* [ ] Access Control should be via existing and well regarded frameworks. If you really do need to roll your own then contact the security team for a design and implementation review. | * [ ] Access Control should be via existing and well regarded frameworks. If you really do need to roll your own then contact the security team for a design and implementation review. | ||
* [ ] If you are building a core Firefox service, consider adding it to the list of restricted domains in the preference `extensions.webextensions.restrictedDomains`. This will prevent a malicious extension from being able to steal sensitive information from it, see [bug 1415644](https://bugzilla.mozilla.org/show_bug.cgi?id=1415644). | * [ ] If you are building a core Firefox service, consider adding it to the list of restricted domains in the preference `extensions.webextensions.restrictedDomains`. This will prevent a malicious extension from being able to steal sensitive information from it, see [bug 1415644](https://bugzilla.mozilla.org/show_bug.cgi?id=1415644). | ||
| Line 159: | Line 165: | ||
* Javascript applications should use [DOMPurify](https://github.com/cure53/DOMPurify/) | * Javascript applications should use [DOMPurify](https://github.com/cure53/DOMPurify/) | ||
* [ ] Apply sensible limits to user inputs, see [input validation](https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Input_Validation) | * [ ] Apply sensible limits to user inputs, see [input validation](https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Input_Validation) | ||
* POST body size should be small (<500kB) unless | * POST body size should be small (<500kB) unless explicitly needed | ||
* [ ] When managing permissions, make sure access controls are enforced server-side | * [ ] When managing permissions, make sure access controls are enforced server-side | ||
* [ ] If caching is used then make sure that any data cached does not incorrectly allow allow access to data protected by access control | |||
* [ ] If handling cryptographic keys, must have a mechanism to handle quarterly key rotations | * [ ] If handling cryptographic keys, must have a mechanism to handle quarterly key rotations | ||
* Keys used to sign sessions don't need a rotation mechanism if destroying all sessions is acceptable in case of emergency. | * Keys used to sign sessions don't need a rotation mechanism if destroying all sessions is acceptable in case of emergency. | ||