You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 2, 2019. It is now read-only.
@leplatrem we can split this into smaller issues if you want to do that instead.
Also, a bunch of these probably won't apply and I'll handle some of them (e.g. the Risk Management and Infrastructure sections), but I wanted to start thinking about these.
Risk Management
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
Access and application logs must be archived for a minimum of 90 days
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.
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.
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 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
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, and use sensible Expiration
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
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.
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.
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
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.
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.
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).
Do not use target="_blank" in external links unless you also use rel="noopener noreferrer" (to prevent Reverse Tabnabbing)
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
@leplatrem we can split this into smaller issues if you want to do that instead.
Also, a bunch of these probably won't apply and I'll handle some of them (e.g. the Risk Management and Infrastructure sections), but I wanted to start thinking about these.
Risk Management
Infrastructure
strict-transport-security: max-age=31536000
services.mozilla.com
, it must be manually added to Firefox's preloaded pins.Development
pip list --outdated
or requires.io tooDual Sign Off
Logging
Security Headers
/__cspreport__
endpointdefault-src 'none'; frame-ancestors 'none'; base-uri 'none'; report-uri /__cspreport__
to disallowing all content rendering, framing, and report violationsnone
, frame-src, and object-src should benone
or only allow specific originsSecurity Features
Databases
Common issues
target="_blank"
in external links unless you also userel="noopener noreferrer"
(to prevent Reverse Tabnabbing)The text was updated successfully, but these errors were encountered: