Security/Reviews/SimplePush
Item Reviewed
| Simple Push API | |
| Target | https://wiki.mozilla.org/WebAPI/SimplePush
https://bugzilla.mozilla.org/show_bug.cgi?id=831833 Thialfi: http://research.google.com/pubs/pub37474.html Mozilla's Spec: https://wiki.mozilla.org/WebAPI/SimplePush Necko patch to receive UDP wakeup packets |
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
- Property "SecReview feature goal" (as page type) with input value "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)" 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 "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" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
Action Items
| Action Item Status | In Progress |
| 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)
pauljt pauljt::Web App Test of Server Component:: when we can. pauljt::Web App Test of Telefonica Component:: ASAP Jlebar::Review notification telefonica server:: ASAP |
|
