Push API: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
(Replaced content with "#REDIRECT [[Security/Reviews/Push_API]")
Line 1: Line 1:
{{SecReviewInfo
#REDIRECT [[Security/Reviews/Push_API]
|SecReview name=Push API
|SecReview target=* https://www.dropbox.com/s/xa3gqxyd7ycpw0y/Push%20notification%20server%20APIs.docx
<bugzilla>
{
"id":"776501"
}
</bugzilla>
}}
{{SecReview
|SecReview feature goal=<b>Background documentation:</b> <br>
* https://www.dropbox.com/s/xa3gqxyd7ycpw0y/Push%20notification%20server%20APIs.docx
* https://bugzilla.mozilla.org/show_bug.cgi?id=776501
 
<b>Overview of feature:</b><br>
* allow a Web App to recieve notifications via a push mechanism
* Carrier provides a Notification server which stores and forwards all the messages to client on behalf of the application server
 
 
 
<b>Normal flow of actions</b><br>
(see linked document above for further detail)
# User powers on the handset
# First app that wants a PUSH API
# App asks gecko to listen to push messages
# Gecko if not previously connected, registers itself as a UA with notification server
# Gecko registers the Web App, (token and public key)
# Notification server stores this information in database, and generates a url to send back to UA.
# Gecko send url to Web App
# Web App sends url to App server
# When app wants to push, the app server sends a post to the URL provided
 
<b>Actors & communication</b><br>
Web App<-->Gecko<-->Notification Server (carrier)<--> Application Server (developer)
 
Communication
Web App
    - API Call: url register(WAToken, pbk)
Gecko (user agent)
    - https GET (retrieve UAToken)
    - web socket connection (Register UA, register  WA, getAllMessages, ACK)
    - udp datagram Wakeup packet
Notification Server
    - https POST API
Application Server
|SecReview alt solutions=* Previous solution, but not discussed due to time restrictions in this review.
|SecReview solution chosen=* need a way to get notifications to apps on the phone without maintaining a constantly open connection
* Solution developed in conjunction with initial carrier implementor
|SecReview threats considered=* <b>Spoof a message from the Application Server to the client</b>
Mitigation is that notification server will only accept a message which is signed. Each WAToken has an associated PBK key, if the message signature doesn't match, message is rejected.
To send a message, attacker needs public&private key pair and valid WAToken.
 
*<b> Retrieve another user's push notifications</b>
To receive a message, attacker needs WAToken only. Revocation method: App server just doesnt send messages to that WAToken any more (Application Server must provide a way for a client to get a new WAToken,
 
** All connections to be over HTTPs
** WAToken must be keep secret, generated on application server (like a session cookie)
** Compromise of WAToken not an issue if app doesn't send sensitive data via PUSH (i.e. seperate authentication prior to sensitive data access. This approach should be encouraged anyways, since other sensitive sits on carrier notification server)
|SecReview threat brainstorming=<b>Compromised app private key</b>
*if an attacker has the app's private key, if they can find out WAtoken and URL, they can send messages to users
* Access to private key alone doesn't grant anything (unless WAToken can be guessed).
* Currently no mechanism for the application server to tell the notification server that their key has been compromised
** Proposal to add a revoke mechanism which would allow an application to blacklist a public key by sending a signed known string or similar.
**Introduces a threat that the attacker can DoS an app's push notifications if they get the private key. Spoofing messages to users though is probably more disruptive and it is likely that an attacker with the key will have WATokens too
** Revoke mechanism must remove the registered PBK and add it to a list of blocked PBKs that will not be used to send messages in the future (see bug XXXXXX)
<b>Compromise UA token</b>
Any threat here? I don't think so - but what happens if you set you UA token to be the same as someone else? Any threats here?
 
<b>Hostile network - spoof notification server UDP message, or MITM get request</b>
Only listen for UDP datagram on network controlled by carrier (3g etc)?
 
<b> DoS of notification server </b>
Notification server doesn't authenticate app server, so an attacker can just spam the Notification server. Notification server could implement heuristic based blocking to block abusive traffic
 
<b>Privacy threats</b>
------------------
<b>a carrier knows what apps the user is using</b><br>
*An identifiable item in the db that shows the phone <-> web app relationship, this appears to leak what apps I am using to my carrier
** A carrier knows what apps you are using (can we avoid this?)
**With access to the database, could you uniquely identify a user?
<b>All messages go through the carrier server</b><br>
* Encourage the developer to ensure the message does not contain data - they are merely message to the user to say that "you have new information API available, you should come get it from the server"
*compromise this server and you get all messages for all users!
* apps could encrypt the data end to end (but probably wont, unless we provide an easy way to do it, mauybe the platform could provide this, unlikely?)
}}
 
{{SecReviewActionStatus
|SecReview action item status=In Progress
|Feature version=B2G Basecamp
|SecReview action items=}}
 
* Develop privacy guidance to stop developers from sending sensitive information through the notification server (pauljt/curtisk)
* Investigate and implement a revocation service for Push API (Fernando?/Pauljt)
* introduce a mechanism in gecko to generate a WAToken for the app (if the dev call calls the API with an empty WAToken, gecko gives you a secure one) (Thinker? pt to raise bug, cc jonas)
<bugzilla>
{
"id":"787959, 787965, 787963"
}
</bugzilla>

Revision as of 22:50, 3 September 2012

  1. REDIRECT [[Security/Reviews/Push_API]
Retrieved from "https://wiki.mozilla.org/index.php?title=Push_API&oldid=467147"