mozilla / blurts-server Goto Github PK

Is this compatible with FireFox Quantum ver. 57? Because this add-on showing error that, this is compatible with minVersion: 58.0a1. add-on maxVersion: 59.0a1

I want to do an audit of all the code to clean up stuff like:

• Package imports should be ordered nicely
• Use async/await instead of Promises
• Make variable naming consistent (especially for function arguments - prefix with "a" e.g. aArg1, aArg2)
• Sensible whitespace

Currently API handlers are added direction with app.get/app.post. We should implement a handler registration system that will allow organized, versioned API handling for better maintainability and readability.

We have arguments against const and arguments for const, let's have a 🔪 and 🔫 fight and settle this once and for all and see if we can find an ESLint rule that will support whatever we go with.

So this is a "needs discussion" but now shouldn't be a blocker on the current open PR.

All the code is present in the server.js file. Instead, we should modularize the code by creating different routes using express Router.

We can have different routes for user, oauth etc.

We should check all the environment variables we're using and ensure the correctness of their values in a rigorous way before listening.

As mentioned by @pdehaan ...

I commented out the test because I was eager to merge the PR, but the tape test runner would hang on that test. I think it has something to do with how Sequelize model instance methods should (or should not?) return promises?

Breach Alert UX on Drive: https://drive.google.com/file/d/1AuhQCFHOsNduMF_Sne32mCMfMeaTFuVJ/view?usp=sharing

Including:

• Input field for the user to input their email address
• Button to search breaches for their email address
• Button to subscribe to email notifications if their email address is included in a future breach

It's not in the basic "eslint:recommended" rule set, but we should just use this to enforce consistency:

"quotes": ["error", "double"],

Now that this is under Mozilla GitHub org, we should verify the license (currently ISC per package.json — but not sure if it should be MPL-2.0):

And probably add a root level LICENSE file.

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
• Use Modern or Intermediate TLS
• Set HSTS to 31536000 (1 year)
  • strict-transport-security: max-age=31536000
• [ ] 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=";
    • Start with max-age set to 5 minutes (max-age=300) and increase progressively
    • The first two pins are for Digicert EV and DV roots, the last two are for Let's Encrypt X3 and X4 intermediates (LE is only used for backup)
  • [ ] 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

• 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.
• Keep 3rd-party libraries up to date
  • Use NSP or 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 [email protected] 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

• 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, HTTPOnly, and SameSite 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.
    • Note: we have a sticky session cookie AWSELB that is set without secure and httponly flags, but it is low risk.
• [ ] 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 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 Cheet Sheet
• [ ] 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.

Common issues

• 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
• Apply sensible limits to user inputs, see 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.
• 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)

Ref #53 (comment)

should we be including Twitter/OpenGraph <meta> tags?

MOAR COMMENTS PLZ

To avoid the overhead of enabling legacy extensions and to simplify the code-base, this could be refactored into WebExtensions APIs. Specifically, webRequest and notifications E.g.,

background.js

const BREACHES_URL = "..."
let siteSet = new Set();

async function initSiteList() {
  const breachesResponse = await fetch(BREACHES_URL);
  const breachesJSON = breachesResponse.json();
  siteSet = new Set(breachesJSON.map(site => site.Domain));
}

function initOnResponseStarted() {
  browser.webRequest.onResponseStarted.addListener(details => {
    if (siteSet.has(details.url.replace("www.",""))) {
      notifications.create({...});
    }
  }...);
}

initSiteList();
initOnResponseStarted();

PRESERVE ALL THE BLAME

We probably also want to add Circle-CI or Travis-CI git hooks so we can run linting/tests/nsp on a per-PR basis.

To prevent the extremely unlikely scenario of a clash. Simply requiring the email address as a request parameter should suffice.

Needs a README with instructions for development & testing

Ref: https://github.com/mozilla/blurts-server/pull/48/files#r171956899:

Hmm, this would be nice, yes, but I'm going to procrastinate on it because:

• This is not immediately important.
• Getting numerical values from the environment means using parseInt(), and that seems like a prime surface area for bugs and failures.
• We should probably first improve AppConstants to also know what type each value is supposed to be and automate the parseInt()s.

Not sure if something like Mozilla's node-convict would be useful here for config+env management w/ schema validation.

Environment variable usage should be done via AppConstants.

I.e., /app/version.json object at /__version__, /__heartbeat__, and /__lbheartbeat__ as described here:

https://github.com/mozilla-services/Dockerflow#containerized-app-requirements

Since we're a server, we probably want to use something like nsp or snyk to audit or suspect dependencies...

Current status:

$ npx nsp@latest check

npx: installed 113 in 15.185s

(+) 1 vulnerability found
┌────────────┬────────────────────────────────────────────────────────────────────┐
│            │ Prototype pollution attack                                         │
├────────────┼────────────────────────────────────────────────────────────────────┤
│ Name       │ hoek                                                               │
├────────────┼────────────────────────────────────────────────────────────────────┤
│ CVSS       │ 4 (Medium)                                                         │
├────────────┼────────────────────────────────────────────────────────────────────┤
│ Installed  │ 4.2.0                                                              │
├────────────┼────────────────────────────────────────────────────────────────────┤
│ Vulnerable │ <= 4.2.0 || >= 5.0.0 < 5.0.3                                       │
├────────────┼────────────────────────────────────────────────────────────────────┤
│ Patched    │ > 4.2.0 < 5.0.0 || >= 5.0.3                                        │
├────────────┼────────────────────────────────────────────────────────────────────┤
│ Path       │ [email protected] > [email protected] > [email protected] > [email protected]     │
├────────────┼────────────────────────────────────────────────────────────────────┤
│ More Info  │ https://nodesecurity.io/advisories/566                             │
└────────────┴────────────────────────────────────────────────────────────────────┘

Ref: https://nodesecurity.io/advisories/566

And since we're using Express, not sure if we want to consider something like helmet to lock down a few settings.

Consolidate our 2 linting scripts in package.json. (See #39 (review))

To scan HIBP breach data without revealing user emails, download the email hashsets for HIBP breaches and store them to Mozilla S3 storage.

https://stage.haveibeenpwned.com/EnterpriseSubscriber/e698550f-0f1c-46bd-9f3b-64dd57209dcb/Api#HashSetsOverview

STR:

1. ./package.sh
2. Run Firefox Nightly 58.0a1 (2017-11-07) (64-bit) Mac
3. In about:config set:

• xpinstall.signatures.required to false
• extensions.legacy.enabled to true

4. In about:addons, choose "Install Add-on from File"
5. Select the packaged BreachAlerts.xpi
6. Visit linkedin.com

Expected result:

Notification bar with an alert: "You visited hacked site ..."

Actual result:

Nothing is shown

Inform users about data breaches through the Firefox UI - for example, a notification when they visit a site (or maybe when they focus a form on a login page) known to have recently been breached.

I'm curious about the wording of this. What defines "recently"?

Potential solution:

$ npm i foundation-sites jquery -D
$ cp ./node_modules/foundation-sites/dist/css/foundation.min.css public/css/vendor/foundation.min.css
$ cp ./node_modules/foundation-sites/dist/js/foundation.min.js public/js/vendor/foundation.min.js
$ cp ./node_modules/jquery/dist/jquery.min.js public/js/vendor/jquery.js

But at least this will make managing the vendor files easier and let us use semver to manage versions (and nsp to make sure everything is tip-top).

Here's a quick example using shelljs to copy files:

const { cp } = require('shelljs');
 
cp("./node_modules/foundation-sites/dist/css/foundation.min.css", "./public/css/vendor/");
cp([
  "./node_modules/foundation-sites/dist/js/foundation.min.js",
  "./node_modules/jquery/dist/jquery.min.js"
], "./public/js/vendor/");

... then we'd just need some clever .gitignore to ignore the ./public/css/vendor/* files and ./public/js/vendor/* folders.

Should we insist that the user make an explicit choice on the warning? Just FYI, the options presented in the previous study were:

• I don't have an account [here]
• I've changed my password
• Disable all future warnings
• Sign up for security warnings

Hi,

I have some question about the way you verify if an user "has been pwned". Are you sending the email to https://haveibeenpwned.com/ ?
If yes, will this be standard behavior when being integrated into Firefox core?

(I took the original mention of the problem from here:
https://gnusocial.de/notice/12301756 )

Simon

Good practice, I'd say (and so might @pdehaan ;))

See #75 (review)

Looking through the code, it only looks like it has 2 fields, but may be nice to include a dummy "server/smtp-credentials.json.sample" file with something like:

{
  "username": "xxx",
  "password": "yyy"
}

We should start an api.md file containing detailed documentation for API endpoints, usage, errors, request/response structures, etc.

Just an idea, not sure how doable this is or how it'd play with a templating system, but let's see.

What should the behavior of this extension be when you visit a site with an unverified breach?

Here's a set of options that seems to span the spectrum of possible behavior:

1. Don't show any notification - if it turns out to be fake, we worried a bunch of people for no reason
2. Only show a notification if some criteria is met - e.g. user is frequent visitor to the site? logged in
3. Save that you visited the site, and give a notification later if the breach is verified as correct - much less invasive, tracked data is very small
4. Give a notification with muted styling and wording ("We're not sure yet, but…")
5. Full speed ahead, tiny or no indication that the breach is marked in HIBP as unverified

Will be needed when we scale.

The README document should link to the API docs and contain detailed instructions for:

• local development
• deployment (to heroku)
• contribution

We should just make this a script. It does not need to have a HTTP API.

Includes:

• List of breaches in which the email address was included
• CTA

Tasks:

• Implement FetchHashsets to download email hashsets of HIBP breaches
• Search the email hashsets for the email address entered by the user
• Display breach information for each of the breaches found