Security/Reviews/TogetherJS
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)
https://github.com/mozilla/togetherjs/issues/848 https://github.com/mozilla/togetherjs/issues/840 (at least the user identity part)
|
|
{{#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