Security/Reviews/SimplePush

Item Reviewed

Introduce the Feature

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

Background is here: https://wiki.mozilla.org/WebAPI/SimplePush Push Notifications - currently on designed for B2G Will be implemented on desktop, but this is specified yet. Found it: https://etherpad.mozilla.org/n1f1znLCQh

Registration Flow

1. User Agent sends "push-register" message to app Sorry the documentation is not clear on that, will fix. push-register is only sent sometimes and is a recovery mechanism. Ideally applications call mozPushNotification.register() whenever they want 2. In the handler for push-register, the app calls navigator.pushNotifications.register() once for each topic it wants to listen for. 3. register() causes the user-agent to request a new unique channel identifier for the app by requesting a new channelID from the Push Server. The User Agent generates the GUID4 and asks the push server if it is available. 4. Upon recieving the pushEndpoint and channelID from the Push Server, the user-agent returns the pushEndpoint to the app, which represents the URL which will recieve notifications for this channel. 5. The app sends this URL to its App Server, to let it know that it is listening to push requests sent to this URL

Sending a message

1. App Server posts a message to the Push Notification URL containing a version string 2. The version of this channelID is stored on the PushServer 3. The user-agent calls /v1/update to retrieve a list of all registered all channels and all known versions (for this particular user-agent-id)

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?

`

Threat Brainstorming

1. Spoof a message from the Application Server to the client Is this correct: There is no authentication of the App Server, however the ChannelIDs are designed to be large and random enough to make it impossible to guess, bruteforce or accidentally send data to a channel without prior knowledge of the channelID Yes this is correct 2. Interception of messages in transit Data involved is low risk, and can be secured by use of channel security ? Are we using TLS? Seems like we must otherwise anyone able to view message could spoof changes to version numbers ... more information needed... "Version" is probably a bad term. Really, this is an ETag. If SimplePush gets a value different than the one it had, it triggers an update request to the client. (The term "Version" comes from the original source paper for Google Thailfi.) If the message is intercepted, the bad guy gets a random number. Well I wouldn't say it is an E-Tag, the application might be using sequentially increasing integers as version numbers.

• we will only accept 64-bit integers as versions

3. PushServer DoS? This is a more valid concern. A UAID+CHID pair aren't considered valid until there's some traffic, and invalid pairs are cleaned up using garbage collection. High numbers of registrations from a single IP are also warning signs, but can be throttled back by the server. 4. Disclosure of channel URL

Action Items