Security/Reviews/TogetherJS

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)

{{#set:SecReview name=TogetherJS |SecReview 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

{{#set: SecReview feature goal=* 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.

|SecReview alt solutions=' |SecReview solution chosen=' |SecReview threats considered=* Output encoding, etc. seems to be good - will test some more |SecReview 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

}}

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) TogetherJS Team :: offsite navigation (not allow by default, whitelist for allowable) :: https://github.com/mozilla/togetherjs/issues/847

{{#set:|SecReview action item status=None

|Feature version=` |SecReview 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)

• TogetherJS Team :: offsite navigation (not allow by default, whitelist for allowable) :: https://github.com/mozilla/togetherjs/issues/847

}} 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