Prod security review

[bbangert]

When pushbox is ready to go to prod, it needs a security review. Correlating privatesec-review issue:

• mozilla-services/foxsec#778

[jvehent]

You might want to go through this, though I expect most of it will not apply to this project, so just cross it off or mark it as done.

---

Risk Management

• [x] 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

Infrastructure

• [x] Access and application logs must be archived for a minimum of 90 days
• [x] Use Modern or Intermediate TLS
• [ ] Set HSTS to 31536000 (1 year)
  • strict-transport-security: max-age=31536000
  • [ ] If the service is not hosted under services.mozilla.com, it must be manually added to Firefox's preloaded pins.
• If service has an admin panels, it must:
  • [ ] only be available behind Mozilla VPN (which provides MFA)
  • [ ] require Auth0 authentication

Development

• [x] Ensure your code repository is configured and located appropriately:
  • Only designated people should be allowed to push to production branches. (GitHub protected branches.)
  • Host your repository in a trusted organization (one that follows EIS Recommendations). A list is maintained here.
• [x] Sign all release tags, and ideally commits as well
  • Developers should configure git to sign all tags 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.
• [x] Keep 3rd-party libraries up to date
  • Use NSP 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)
  • From the "add a team" dropdown for your repo add the relevant "Approved Mozilla PyUp Configuration" team for your github org (e.g. for mozilla and mozilla-services) and grant it write permission.
  • Notify secops@mozilla.com to enable the integration in pyup
  • Consider using pip list --outdated or requires.io too
• [ ] Integrate static code analysis in CI, and avoid merging code with issues
  • Javascript applications should use ESLint with the Mozilla ruleset
  • Python applications should use Bandit
  • Go applications should use the Go Meta Linter
  • 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

• [x] Publish detailed logs in mozlog format (APP-MOZLOG)
  • Business logic must be logged with app specific codes (see FxA)
  • 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
• [x] Web APIs must set a non-HTML content-type on all responses, including 300s, 400s and 500s
• [x] Set the Secure and HTTPOnly flags on Cookies, and use sensible Expiration
• [ ] Make sure your application gets an A+ on the Mozilla Observatory
• [ ] Verify your application doesn't have any failures on the Security Baseline.
  • 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

Security Features

• [x] Authentication of end-users should be via FxA. Authentication of Mozillians should be via Auth0/SSO. Any exceptions must be approved by the security team.
• [x] Session Management should be via existing and well regarded frameworks. In all cases you should contact the security team for a design and implementation review
  • 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 cookies must have HttpOnly and Secure flags set.
  • For more information about potential pitfalls see the OWASP Session Management Cheet Sheet
• [x] 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.

Databases

• [x] All SQL queries must be parameterized, not concatenated
• [x] 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

• [x] User data must be escaped for the right context prior to reflecting it
  • When inserting user generated html into an html context:
  • Python applications should use Bleach
  • Javascript applications should use DOMPurify
• [x] Apply sensible limits to user inputs, see input validation
  • POST body size should be small (<500kB) unless explicitely needed
• [x] When managing permissions, make sure access controls are enforced server-side
• [x] 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.
• [x] Do not proxy requests from users without strong limitations and filtering (see Pocket UserData vulnerability). Don't proxy requests to link local, loopback, or private networks 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).
• [x] Do not use target="_blank" in external links unless you also use rel="noopener noreferrer" (to prevent Reverse Tabnabbing)

[bbangert]

This is blocked on pushbox being 'complete'.

[jvehent]

any update?

[bbangert]

I believe we are waiting till rustbox is ready, as that will be the final prod version, not the AWS serverless one.

[rfk]

@jrconlin what followup do we need on this issue now that things are ready for prod?

[jrconlin]

Going to go through the checklist this morning, then see about getting it scheduled for review. If you like, you can add it to any new FxA service review you're doing, or I can keep it separate.

[jrconlin]

Added draft RRA

[jrconlin]

Added Risk Record bug

[jrconlin]

Closing as complete. No additional actions requested by OpSec.