Security/Reviews/Push API

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

• Property "SecReview feature goal" (as page type) with input value "Background documentation:
  • https://www.dropbox.com/s/xa3gqxyd7ycpw0y/Push%20notification%20server%20APIs.docx
  • https://bugzilla.mozilla.org/show_bug.cgi?id=776501

  Overview of feature:

  • 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

  
  

  Normal flow of actions (see linked document above for further detail)

  1. User powers on the handset
  2. First app that wants a PUSH API
  3. App asks gecko to listen to push messages
  4. Gecko if not previously connected, registers itself as a UA with notification server
  5. Gecko registers the Web App, (token and public key)
  6. Notification server stores this information in database, and generates a url to send back to UA.
  7. Gecko send url to Web App
  8. Web App sends url to App server
  9. When app wants to push, the app server sends a post to the URL provided

  Actors & communication

  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" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
• Property "SecReview solution chosen" (as page type) with input value "* 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" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
  • Property "SecReview threats considered" (as page type) with input value "* Spoof a message from the Application Server to the client

  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.

  • Retrieve another user's push notifications

  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)" 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 "Compromised app private key
  • 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)

  Compromise UA token 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?

  Hostile network - spoof notification server UDP message, or MITM get request Only listen for UDP datagram on network controlled by carrier (3g etc)?

  DoS of notification server 
  

  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

  Privacy threats

  ---

  a carrier knows what apps the user is using

  • 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?

  All messages go through the carrier server

  • 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?)" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.