CloudServices/Roadmaps/SimplePush-Server/SecCodeReview: Difference between revisions

CloudServices/Roadmaps/SimplePush-Server/SecCodeReview (view source)

Revision as of 23:37, 3 June 2013

205 bytes removed , 3 June 2013

→‎Data-flow Enumeration

Jrconlin

Confirmed users

1,021

edits

@@ Line 133: / Line 133: @@
 === Data-flow Enumeration ===
-Data-flow enumeration is an important supplement to the Detailed Application Diagram; it acts as a reference for someone reading the diagram to look up the nature of what information is associated with a call or request between two components.
-At a minimum, the flow enumeration should be a table indicating an identifier, subject, object, and the operation being performed.
-In the example below, an excerpt from the [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#1._Provisioning  BrowserID provisioning enumeration], the subject, object, and operation are labelled origin, destination, and description, respectively.
 {| border="1" class="fullwidth-table"
@@ Line 146: / Line 140: @@
 | align="center" style="background:#f0f0f0;"|'''Description'''
 |-
-|1.A||Relying Party||Implementation Provider|| An interaction with the Relying party invokes the Implementation Provider (IP).
+|1||Client||Server|| Client connects via WebSocket protocol and sends a "hello" JSON packet containing the clients UAID.
 |-
-|1.B||Implementation Provider||Identity Authority||The IP either has an expired certificate, or no certificate, and directs the client to an Identity Authority landing page for authentication.  This authentication process is out of scope of the protocol, and implementation dependent.
+|2||Server||Client|| Server responds with a "hello" JSON response. Server records that the UAID is now active and associates it to the listening websocket connection.
 |-
-|1.C||Identity Authority||Identity Authority||Code from the IP landing page invokes genKeyPair() to generate a keypair.
+|3a||Server||Client|| Server checks if there is outbound ChannelID updates for UAID and sends them as a "notification" packet"
+|-
+|3b||Client||Server|| Client "ack"s the Notification packet. Server deletes any "ack'd"  notifications and re-flushes (see step 3a) until no more notifications are present.
+|-
+|4||Client||Server|| Client registers a new ChannelID and receives a new "endpoint" URL
+|-
+|4a||Client||App|| (OUT OF BAND) The client relays the Endpoint to the app, which then communicates it back to 3rdPartyServer for later use.
+|-
+|5||3rdPartyServer||Server|| 3rdPartyServer PUTS to "endpoint". The specification requests that the server use "?v=..." however this version information is discarded by the Server. The server records the event to a record in memcache identified by UAID.ChannelID
+|-
+|5a||Server||Client|| IFF the client is actively connected, Server conducts a flush (See step 3*)
+|-
+|5b||Server||Magic|| IFF the client is not currently connected, an Proprietary Wake Up method may be employed. The client reconnects and starts at Step 1.
 |-
-|1.D||Identity Authority||Implementation Provider||The IP saves the keypair in the client
 |}
-In addition to including the subject, object, operation columns, it can be helpful to include an explicit list of fields which are considered sensitive.
-==== Additional Examples ====
-* [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#1._Provisioning BrowserID Data-flow Enumeration]
 === Threat Analysis ===