Security/Reviews/TogetherJS

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.

Item Reviewed

TogetherJS
Target https://togetherjs.com/docs/#technology-overview

https://wiki.mozilla.org/Privacy/Reviews/TogetherJS https://bugzilla.mozilla.org/show_bug.cgi?id=920244

To browse source collaboratively: https://togetherjs.com/source/#&togetherjs=7glnwO7kDU (also docs)


Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

  • a site includes it by includeing a bit of JS from togetherjs
    • the items run in content
  • People are connected to a hub which bounces messages to / from them
  • the sessions are linked, forms are synced, users can see where each others' pointers, etc.

There's a default setting that points to a default hub - you can override it by making a version on your own site (can also have per settings) - default server is shared among a number of sites.

  • These settings are in an API (you can set a bunch of things from the script that sets it up)

Settings that have interesting security properties:

  • Identity stuff in general
  • Clicks may be sent to remote peer
  • Hub server
    • same URL == same room (randomly generated) - that's the primary security
    • Find room setting lets you find a room where there are already rooms (instead of random ID you can use one that's there)

Server is currently run by AWS (jp looks after this) - kinda like mofodev's hosting

  • If we scaled there might be scaling issues (people can stand up their own if we can't scale for them).

ID info in local storage Session storage in session storage

  • Password fields - blacklisted from form sync.

What solutions/approaches were considered other than the proposed solution?

`

Why was this solution chosen?

`

Any security threats already considered in the design and why?

  • Output encoding, etc. seems to be good - will test some more

Threat Brainstorming

  • spoofing a user
    • option for a site to use a given auth to set username/avatar (no peer to peer)
    • user could hack local storage to change username/avatar
    • could get a user to show you sensitive information on a form field or get them to enter information that would allow the attacker access later (requires social engineering)
    • Remote DOM XSS possible by form sync
  • password fields are blacklisted from form sync
  • Clickjacking on 'do you want to join'?
  • Possible phishing from 'user has gone here' - investigate
  • A custom client could make messages appear to come from someone else
  • Property "SecReview feature goal" (as page type) with input value "* a site includes it by includeing a bit of JS from togetherjs
      • the items run in content
    • People are connected to a hub which bounces messages to / from them
    • the sessions are linked, forms are synced, users can see where each others' pointers, etc.

    There's a default setting that points to a default hub - you can override it by making a version on your own site (can also have per settings) - default server is shared among a number of sites.

    • These settings are in an API (you can set a bunch of things from the script that sets it up)

    Settings that have interesting security properties:

    • Identity stuff in general
    • Clicks may be sent to remote peer
    • Hub server
      • same URL == same room (randomly generated) - that's the primary security
      • Find room setting lets you find a room where there are already rooms (instead of random ID you can use one that's there)

    Server is currently run by AWS (jp looks after this) - kinda like mofodev's hosting

    • If we scaled there might be scaling issues (people can stand up their own if we can't scale for them).

    ID info in local storage Session storage in session storage

    • Password fields - blacklisted from form sync." contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
    • Property "SecReview threat brainstorming" (as page type) with input value "* spoofing a user
      • option for a site to use a given auth to set username/avatar (no peer to peer)
      • user could hack local storage to change username/avatar
      • could get a user to show you sensitive information on a form field or get them to enter information that would allow the attacker access later (requires social engineering)
      • Remote DOM XSS possible by form sync
    • password fields are blacklisted from form sync
    • Clickjacking on 'do you want to join'?
    • Possible phishing from 'user has gone here' - investigate
    • A custom client could make messages appear to come from someone else" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

Action Items

Action Item Status None
Release Target `
Action Items
* Who :: What :: By when (Keep in mind all these things will be bugs that block the review bug, that blocks the feature bug)
  • TogetherJS Team :: add a warning to not provide sensiteve information (can go FAQ?)::

https://github.com/mozilla/togetherjs/issues/848 https://github.com/mozilla/togetherjs/issues/840 (at least the user identity part)

Other items noted: Turn off http access (even via redirect) to togetherjs.js: https://github.com/mozilla/togetherjs/issues/846 Include setting to turn off form synchronization for a field or set of fields: https://github.com/mozilla/togetherjs/issues/841 Turn off http access to hub: https://github.com/mozilla/togetherjs/issues/849 HSTS: https://github.com/mozilla/togetherjs/issues/396

Retrieved from "https://wiki.mozilla.org/index.php?title=Security/Reviews/TogetherJS&oldid=726612"