Closed jvehent closed 5 years ago
@psiinon, I think we're good to close this out. Can you confirm? :)
@caitmuenster its looking pretty good :) Just a couple of outstanding issues:
Updated to ping the right person, sorry about that Bob :/
no CSP report-uri set - is this something you can add?
@psiinon does static sites must have "report-uri" per secops standard?
Current Ops model for hosting a static website only contains cloudfront, edge lambda and s3 components. "report-uri" means that we very likely need to introduce an ELB and EC2 instances just to host the "report-uri" endpoint. It then requires logging, monitoring and etc.
That said, we can add it if it's a hard requirement, and we'd like to skip setting it if it's not mandatory.
none of the release tags seem to be signed - can you sign future ones?
We haven't cut any official release tags yet. Existing ones are for testing deployments only and can be removed in a later time.
Future official releases should be signed by whoever releases them.
@psiinon I don't know that we're signing releases for libs elsewhere in every case - is that a hard requirement?
I'd expect most releases will be done by cutting tags via the github UI. Even if that means it's signed because github creates that tag it does also mean anyone with write perms can release.
@bqbn I'd have thought we'd want a report-uri defined in case the CSP breaks something. Tbh thats more of a development concern than a security one.
@hwine how hard a requirement is signing releases on github?
@psiinon thx for the clarification. I'm OK without report-uri then (from Ops perspective). @muffinresearch let me know if you think we need one from dev perspective.
Nevertheless, it doesn't sound like "report-uri" is a blocking factor for the release, e.g. we can file a bugzilla to add it if we decide to have it in the future. Also our other static site extensionschallenge.com doesn't have it.
@psiinon signing (commit, tag, release) is only a recommended action at this time. There are a number of pitfalls in using signing, and extra tooling needed to support it.
I'm happy to take suggestions on how to better reflect that in the "docs".
@psiinon is there anything else from a security perspective that needs addressing before this issue can be closed out?
@muffinresearch I'm good with closing this out now :)
Thanks, @psiinon!
Risk Management
Infrastructure
strict-transport-security: max-age=31536000
services.mozilla.com
, it must be manually added to Firefox's preloaded pins. This only applies to production services, not short-lived experiments.Development
npm audit
with audit-filter to review and handle exceptions (see example in speech-proxy)pip list --outdated
or requires.io or pyup outdated checkscargo update
and cargo upgrade when changing versionsDual Sign Off
Logging
Web Applications
/__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
extensions.webextensions.restrictedDomains
. This will prevent a malicious extension from being able to steal sensitive information from it, see bug 1415644.Databases
Common issues
target="_blank"
in external links unless you also userel="noopener noreferrer"
(to prevent Reverse Tabnabbing)