Security/FirefoxOperations: Difference between revisions

Jump to navigation Jump to search

Security/FirefoxOperations (view source)

Revision as of 20:39, 1 August 2017

2,006 bytes added ,  1 August 2017
→‎Security Checklist
(correct syntax on pip command)
Line 67: Line 67:


<source lang:markdown>
<source lang:markdown>
Risk Management
Risk Management
---------------
---------------
* [ ] The service must have performed a Rapid Risk Assessment and have a Risk Record bug (**SVC-RRA**).
* [ ] The service must have performed a Rapid Risk Assessment and have a Risk Record bug
* [ ] Public staging and production endpoints must be added to the [security baseline](https://github.com/mozilla-services/foxsec/blob/master/services/README.md)


Infrastructure rules
Infrastructure
--------------------
--------------


* [ ] Access and application logs must be archived for a minimum of 90 days
* [ ] Access and application logs must be archived for a minimum of 90 days
* [ ] Use [Modern](https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility) or [Intermediate](https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility) TLS (**INFRA-TLS**)
* [ ] Use [Modern](https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility) or [Intermediate](https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility) TLS
* [ ] Set HSTS to 31536000 (1 year) (**INFRA-HSTS**)
* [ ] Set HSTS to 31536000 (1 year)
   * `strict-transport-security: max-age=31536000`
   * `strict-transport-security: max-age=31536000`
* [ ] Set HPKP to 5184000 (60 days) (**INFRA-HPKP**)
* [ ] Set HPKP to 5184000 (60 days)
   * `Public-Key-Pins: max-age=5184000; pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18="; pin-sha256="r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E="; pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="; pin-sha256="sRHdihwgkaib1P1gxX8HFszlD+7/gTfNvuAybgLPNis=";`
   * `Public-Key-Pins: max-age=5184000; pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18="; pin-sha256="r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E="; pin-sha256="YLh1dUR9y6Kja30RrAn7JKnbQG/uEtLMkBgFF2Fuihg="; pin-sha256="sRHdihwgkaib1P1gxX8HFszlD+7/gTfNvuAybgLPNis=";`
     * Start with max-age set to 5 minutes (`max-age=300`) and increase progressively
     * Start with max-age set to 5 minutes (`max-age=300`) and increase progressively
Line 85: Line 85:
   * [ ] If the service is not hosted under `services.mozilla.com`, it must be manually added to [Firefox's preloaded pins](https://dxr.mozilla.org/mozilla-central/source/security/manager/tools/PreloadedHPKPins.json#184).
   * [ ] If the service is not hosted under `services.mozilla.com`, it must be manually added to [Firefox's preloaded pins](https://dxr.mozilla.org/mozilla-central/source/security/manager/tools/PreloadedHPKPins.json#184).
* If service has an admin panels, it must:
* If service has an admin panels, it must:
   * [ ] only be available behind Mozilla VPN (which provides MFA) (**INFRA-ADMINVPN**)
   * [ ] only be available behind Mozilla VPN (which provides MFA)
   * [ ] require LDAP authentication (**INFRA-ADMINLDAP**)
   * [ ] require Auth0 authentication
  * [ ] enforce a two-man rule on sensitive changes (**INFRA-2MANRULE**)


Coding rules
Development
------------
-----------
 
* [ ] Sign all release tags, and ideally commits as well
The following rules apply to all web applications: api and websites.
 
* [ ] Sign all release tags, and maybe commits as well (**APP-COMMITSIG**)
   * 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.
* [ ] Publish detailed logs in [mozlog](https://github.com/mozilla-services/Dockerflow/blob/master/docs/mozlog.md) format (**APP-MOZLOG**)
* [ ] Keep 3rd-party libraries up to date
  * Business logic must be logged with app specific codes (errno)
   * Use [NSP](https://nodesecurity.io/) or [GreenKeeper](https://greenkeeper.io/ Greenkeeper) for NodeJS applications
  * Access control failures must be logged at WARN level
   * For Python applications, enable pyup security updates:
* [ ] Must have a CSP with (**APP-CSP**)
  * [ ] a report-uri pointing to the service's own `/__cspreport__` endpoint
  * [ ] web APIs should set `default-src` to `none`, disallowing all content rendering
  * [ ] if default-src is not `self`, frame-src and object-src should be `none` or only allow specific origins
  * [ ] no use of unsafe-inline or unsafe-eval
* [ ] User data must be escaped for the right context prior to reflecting it (**APP-ESCAPE**)
* [ ] Web APIs must set a non-HTML content-type on all responses, including 300s, 400s and 500s (**APP-NOHTML**)
* [ ] All SQL queries must be parameterized, not concatenated (**APP-SQL**)
* [ ] Apply sensible limits to user inputs, see [input validation](https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Input_Validation) (**APP-INPUTVAL**)
* [ ] When managing permissions, make sure access controls are enforced server-side (**APP-ACL**)
* [ ] Set the Secure and HTTPOnly flags on [Cookies](https://wiki.mozilla.org/Security/Guidelines/Web_Security#Cookies), and use sensible Expiration (**APP-SECCOOKIE**)
* Keep 3rd-party libraries up to date (**APP-DEPS**)
   * [ ] Use [NSP](https://nodesecurity.io/) or [GreenKeeper](https://greenkeeper.io/ Greenkeeper) for NodeJS applications
   * [ ] For Python applications, 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)
     * Add https://github.com/mozsvcpyup as a collaborator to your repo
     * Add https://github.com/mozsvcpyup as a collaborator to your repo
     * Notify secops@mozilla.com to enable the integration in pyup
     * Notify secops@mozilla.com to enable the integration in pyup
     * Consider using ``pip list --outdated`` or [requires.io](https://requires.io/) too
     * Consider using ``pip list --outdated`` or [requires.io](https://requires.io/) too
* [ ] If handling cryptographic keys, must have a mechanism to handle quarterly key rotations (**APP-KEYROT**)
* [ ] 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)
    * Python applications should use [Bandit](https://github.com/openstack/bandit)
    * Go applications should use the [Go Meta Linter](https://github.com/alecthomas/gometalinter)
    * Use whitelisting mechanisms in these tools to deal with false positives
 
Dual Sign Off
------------
* [ ] Services that push data to Firefox clients must require a dual sign off on every change, implemented in their admin panels
  * This mechanism must be reviewed and approved by the Firefox Operations Security team before being enabled in production
 
Logging
-------
* [ ] Publish detailed logs in [mozlog](https://github.com/mozilla-services/Dockerflow/blob/master/docs/mozlog.md) format (**APP-MOZLOG**)
  * Business logic must be logged with app specific codes (see [FxA](https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#defined-errors))
  * Access control failures must be logged at WARN level
 
Security Headers
----------------
* [ ] Must have a CSP with
  * [ ] a report-uri pointing to the service's own `/__cspreport__` endpoint
  * [ ] web API responses should return `default-src 'none'; frame-ancestors 'none'; base-uri 'none'; report-uri /__cspreport__` to disallowing all content rendering, framing, and report violations
  * [ ] if default-src is not `none`, frame-src, and object-src should be `none` or only allow specific origins
  * [ ] no use of unsafe-inline or unsafe-eval in script-src, style-src, and img-src
* [ ] Web APIs must set a non-HTML content-type on all responses, including 300s, 400s and 500s
* [ ] Set the Secure and HTTPOnly flags on [Cookies](https://wiki.mozilla.org/Security/Guidelines/Web_Security#Cookies), and use sensible Expiration
* [ ] Make sure your application gets an A+ on the [Mozilla Observatory](https://observatory.mozilla.org/)
* [ ] Verify your application doesn't have any failures on the [Security Baseline](https://github.com/mozilla-services/foxsec/blob/master/tools/baseline-scan/results/Baseline-Services.md).
  * Contact secops@ or ping 'psiinon' on github to document exceptions to the baseline, mark csrf exempt forms, etc.
* [ ] Web APIs should export an OpenAPI (Swagger) to facilitate automated vulnerability tests
 
Databases
---------
* [ ] All SQL queries must be parameterized, not concatenated
* [ ] Applications must use accounts with limited GRANTS when connecting to databases
  * In particular, applications **must not use admin or owner accounts**, to decrease the impact of a sql injection vulnerability.
 
Common issues
-------------
* [ ] User data must be [escaped for the right context](https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#XSS_Prevention_Rules_Summary) prior to reflecting it
  * When inserting user generated html into an html context:
    * Python applications should use [Bleach](https://github.com/mozilla/bleach)
    * 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)
  * POST body size should be small (<500kB) unless explicitely needed
* [ ] When managing permissions, make sure access controls are enforced server-side
* [ ] 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.
* [ ] Applications must use accounts with limited GRANTS when connecting to databases (**APP-DBPRIV**)
* [ ] Do not proxy requests from users without strong limitations and filtering (see [Pocket UserData vulnerability](https://www.gnu.gl/blog/Posts/multiple-vulnerabilities-in-pocket/)). Don't proxy requests to [link local, loopback, or private networks](https://en.wikipedia.org/wiki/Reserved_IP_addresses#IPv4) or DNS that resolves to addresses in those ranges (i.e. 169.254.0.0/16, 127.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 172.16.0.0/12, 192.168.0.0/16, 198.18.0.0/15).
  * In particular, applications **must not use admin or owner accounts**, to decrease the impact of a sql injection vulnerability.
* [ ] fork, exec, subprocess, child_process, etc. calls passing user input to a binary should be [sandboxed](https://github.com/mozilla-services/foxsec/blob/master/docs/sandbox.md)




Ulfr
Confirmed users
529

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1177153"

Navigation menu