Web Security Checklist/Review

[pjenvey]

From foxsec's web security checklist:

Risk Management

• [x] The service must have performed a Rapid Risk Assessment
• [x] The service must be registered via a New Service issue. You need to have access to the mozilla-services GitHub organization to be able to view and create this issue (ping secops if you don't have access).

Infrastructure

• [x] Access and application logs must be archived for a minimum of 90 days
• [x] Use Modern or Intermediate TLS
• [x] Set HSTS to 31536000 (1 year)
  • strict-transport-security: max-age=31536000
  • [x] If the service is not hosted under services.mozilla.com, it must be manually added to Firefox's preloaded pins. This only applies to production services, not short-lived experiments.
• [x] Correctly set client IP
  • [x] Confirm client ip is in the proper location in X-Forwarded-For, modifying what is sent from the client if needed. AWS and GCP's load balancers will do this automatically.
  • [x] Make sure the web server and the application get the true client IP by configuring trusted IP's within Nginx or Apache
  • Nginx: ngx_http_realip_module
  • Apache: mod_remoteip
  • [x] If you have a service-oriented architecture, you must always be able to find the IP of the client that sent the initial request. We recommend passing along the X-Forwarded-For to all back-end services.
• ~If service has an admin panels, it must:~
  • [x] ~only be available behind Mozilla VPN (which provides MFA)~
  • [x] ~require Auth0 authentication~
  • [x] ~Enforce a CSP with frame-ancestors 'none' to prevent iframe related attacks, such as DOM-Based CSRF~
• [x] Build and deploy main or slim variants of official languagespecific base docker images e.g. node, python, or rust and contact secops@ if you want to use other variants

Development

• [x] Ensure your code repository is configured and located appropriately:
  • [x] Application built internally should be hosted in trusted GitHub organizations (mozilla, mozilla-services, mozilla-bteam, mozilla-conduit, mozilla-mobile, taskcluster). Sometimes we build and deploy applications we don't fully control. In those cases, the Dockerfile that builds the application container should be hosted in its own repository in a trusted organization.
  • [x] Secure your repository by implementing Mozilla's GitHub security standard.
• [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] Enable automated security fix PRs on GitHub for vulnerabilities in 3rd-party dependencies
• [x] Keep 3rd-party libraries up to date (in addition to the security updates)
  • For NodeJS applications, use dependabot, renovate, or GreenKeeper
  • For Python, use pip list --outdated or requires.io or pyup outdated checks
  • For Rust, use cargo update and cargo upgrade when changing versions
• [x] 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

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

Web Applications

• [x] Must have a Content Security Policy (CSP). The policy:
  • [x] should set default-src none or only allow specific origins and set frame-src and object-src to none if default-src is not none
  • [x] web API responses should return default-src 'none'; frame-ancestors 'none'; base-uri 'none' to disallow content rendering and framing/redressing
  • [x] should not use unsafe-inline or unsafe-eval in script-src, style-src, or img-src directives (
  • [x] may include a report-uri directive to provide visibility into CSP violations
• [x] ~Third-party javascript must be pinned to specific versions using Subresource Integrity (SRI)~
• [ ] Web APIs:
  • [x] must set a non-HTML content-type on all responses, including 300s, 400s and 500s
  • [ ] Web APIs should export an OpenAPI (Swagger) to facilitate automated vulnerability tests
  • [x] Should use authentication tokens with a unique pattern which is easily parsed with a regexp. This should allow inclusion into a token scanning service in the future. (E.g. prefix mgp- + 20 hex digits would match the regexp \bmgp-[0-9A-Fa-f]{20}\b)
• [x] ~for Cookies:~
  • [x] ~Set the Secure and HTTPOnly flags~
  • [x] ~Use a sensible Expiration~
  • [x] ~Use the prefix __Host- for the cookie name~
• [ ] Make sure your application gets an A+ on the Mozilla Observatory
• [x] Confirm your application doesn't fail the ZAP Security Baseline:
  1. Register your service as described in the Risk Management section (if you are not registering your service you can run the scan as described at: https://github.com/zaproxy/zaproxy/wiki/ZAP-Baseline-Scan)
  2. Go to The STMO baseline dashboard (if you do not have access to the dashboard, contact secops@)
  3. Filter for your service name and check that the "failures" column is 0. Click on each individual site for additional information about any failures.
  4. If you need to document exceptions to the baseline e.g. to mark a search form as CSRF exempt, contact secops@ or ping 'psiinon' on github to get the scan config updated

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 and the SameSite attribute set to 'strict' or 'lax' (which allows external regular links to login).
  • For more information about potential pitfalls see the OWASP Session Management Cheat Sheet
• [x] ~When using cookies for session management, make sure you have CSRF protections in place, which in 99% of cases is SameSite cookies. If you can't use SameSite, use anti CSRF tokens. There are two exceptions to implementing CSRF protection:~
  • Forms that don't change state (e.g. search forms) don't need CSRF protection and can indicate that by setting the 'data-no-csrf' form attribute (this tells our ZAP scanner to ignore those forms when testing for CSRF).
  • Sites that don't use cookies for anything sensitive can ignore CSRF protection. A lot of modern sites prefer to use local-storage JWTs for session management, which aren't vulnerable to CSRF (but must have a rock solid CSP).
• [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.~
• [ ] 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.

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 explicitly needed
• [x] ~When allowing users to upload or generate content, make sure to host that content on a separate domain (eg. firefoxusercontent.com, etc.). This will prevent malicious content from having access to storage and cookies from the origin.~
  • Also use this technique to host rich content you can't protect with a CSP, such as metrics reports, wiki pages, etc.
• [x] ~When managing permissions, make sure access controls are enforced server-side~
• [x] ~If an authenticated user accesses protected resource, make sure the pages with those resource arent cached and served up to unauthenticated users (like via a CDN).~
• [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)~

┆Issue is synchronized with this Jira Task ┆Epic: General Project Tasks

[pjenvey]

..and additionally the Rust specific checklist:

Rust

A checklist for people using Rust to develop Firefox services, to be used in addition to the common checklist.

• [x] Use cargo-audit to check for dependency security vulnerabilities
• [x] Use rust-clippy for linting (easier for new projects)
• [x] Use slog-mozlog-json for service logging
• [x] Set compile time filters if you are using the log Crate. The default setting does not disable any log levels, which can result in excessive logging in high traffic applications
• [x] Binaries (as opposed to libraries) should include a Cargo.lock file in version control
• [x] Use dependabot to keep your dependencies up to date
• [x] Add #![forbid(unsafe_code)] to your crate (e.g. the top of main.rs or lib.rs)
  • [x] If you must use 'unsafe', include a comment explaining why you believe its use is sound and its behavior is correct and well defined
• [x] Only use Rust nightly when it is absolutely necessary
  • [ ] If you have to use nightly track the features you require so that you can move off it once they are merged into stable
• [x] Minimise dependencies (not Rust specific, but important due to the relative immaturity of the ecosystem)
  • Check to see if existing crates already have the functionality
  • Consider implementing simple functionality instead of adding a new dependency
  • Give preference to
  • Crates that are already vendored into Firefox.
  • Crates from rust-lang-nursery
  • Crates that appear to be widely used in the rust community.

Recommended crates

Crate	Description
Actix web	Actix web is a small, pragmatic, and extremely fast rust web framework.
Hyper	A fast and correct HTTP implementation for Rust.
Reqwest	An ergonomic, batteries-included HTTP Client for Rust.
Serde	Serde is a framework for serializing and deserializing Rust data structures efficiently and generically.
Slog	The logging for Rust

[jrconlin]

Linked to https://jira.mozilla.com/browse/CONSVC-8

[jrconlin]

FWIW: Observatory gives an "A" rating: https://observatory.mozilla.org/analyze/contile.services.mozilla.com?third-party=false

[jrconlin]

Status: Downloaded newer image for owasp/zap2docker-stable:latest 2021-07-06 23:57:05,231 Could not find custom hooks file at /home/zap/.zap_hooks.py Jul 06, 2021 11:57:13 PM java.util.prefs.FileSystemPreferences$1 run INFO: Created user preferences directory. Total of 6 URLs ... PASS: Loosely Scoped Cookie [90033] FAIL-NEW: 0 FAIL-INPROG: 0 WARN-NEW: 0 WARN-INPROG: 0 INFO: 0 IGNORE: 0 PASS: 53

[data-sync-user]

➤ David Durst commented:

Philip Jenvey I realize this is low priority. Just wondering if the remaining few items have been addressed for Contile – or rather, if there was a plan to knock out the last few things?

[data-sync-user]

➤ Philip Jenvey commented:

David Durst Yea, I’m actively looking into one final item here

[data-sync-user]

➤ Philip Jenvey commented:

The “A” score on the Mozilla Observatory appears due to the root URL linking to MDN: https://observatory.mozilla.org/analyze/developer.mozilla.org ( https://observatory.mozilla.org/analyze/developer.mozilla.org|smart-link ) and it failing the SRI check.

I’ve pinged #mdn-dev about this and will follow up with them if they’d like an issue logged to improve their SRI support.

Everything else is done for Contile, closing out.

[data-sync-user]

➤ Philip Jenvey commented:

Logged this for MDN SRI support: https://github.com/mdn/yari/issues/4823 ( https://github.com/mdn/yari/issues/4823|smart-link )