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

From MozillaWiki
Jump to navigation Jump to search
(Created page with "=Access Information= == How is the application accessed? == Application is accessed in two ways. The client accesses via a WebSock connection. Third party servers access via a...")
 
 
(6 intermediate revisions by one other user not shown)
Line 37: Line 37:
=Accounts and Passwords=
=Accounts and Passwords=
While there are technically "accounts" no password is maintained for these. UAIDs are generated by the client and used solely to identify itself to the server.   
While there are technically "accounts" no password is maintained for these. UAIDs are generated by the client and used solely to identify itself to the server.   
==If the mechanism to prevent general access is a password, how is the signup process handled?==
N/A


==How is account information stored?==
Update Information associated with a given client is stored as a pair of UUID4 values. A User Agent ID (UAID) and a ChannelID. There is an option for REST endpoint hashing which uses a simple,reversible AES hash to prevent third party sites from potentially gaining unwarranted information about the connecting clients.
Update Information associated with a given client is stored as a pair of UUID4 values. A User Agent ID (UAID) and a ChannelID. There is an option for REST endpoint hashing which uses a simple,reversible AES hash to prevent third party sites from potentially gaining unwarranted information about the connecting clients.


==Are passwords properly stored within databases if applicable?==
=Session Management=
N/A
 
==Is a password policy in place?==
N/A
 
==Are accounts locked-out after a number of invalid logins?==
N/A
 
==Are passwords 8 characters or greater?==
N/A
 
==Do passwords use both numbers and letters (and possibly symbols)?==
N/A
 
==Is there a blacklist of common passwords?==
N/A
 
==Do passwords expire after X days and require a reset?==
N/A
 
==Are invalid logins logged?==
N/A
 
==Is there a lockout after X invalid attempts?==
N/A
 
==Is the error message for lockout generic (does not include if user/pass is valid)?==
N/A
 
==How are password resets handled (i.e. email, security question, etc.)?==
N/A
 
==Do emails sent after signup/reset contain a session link? (should not)==
N/A
 
==Do email verification codes expire after one use or 8 hours?==
N/A
 
==Is password reuse limited/prevented?==
N/A
 
==Session Management==
No Session cookies are used.
No Session cookies are used.


==Third-Party Resources==
=Third-Party Resources=
Only third party resources are source libraries included in the binary application.
Only third party resources are source libraries included in the binary application.


This code has been reviewed both by the golang community at large and by the local engineer.
This code has been reviewed both by the golang community at large and by the local engineer.


====Data Handling====
=Data Handling=
== What kind of data is transferred between the user and the application? ==
== What kind of data is transferred between the user and the application? ==
Client sends identifying UAID, and known channels (channels are ignored)
Client sends identifying UAID, and known channels (channels are ignored)
Line 168: Line 123:


=== Architecture Diagram ===
=== Architecture Diagram ===
http://i.imgur.com/L5LC0tj.png


An architecture diagram illustrates how the various components of the service communicate with one another.
External services, marked in yellow, communicate to the server which acts as a notification event proxy.
 
The goal of the architecture diagram is to give the audience a high-level visual representation of how the different components of a system will interact together. 
 
An example of this is the diagram below, which is from the old Mozilla F1 service.
 
[https://wiki.mozilla.org/images/thumb/7/78/F1design.png/392px-F1design.png Mozilla F1 Architecture Diagram]
 
The F1 service had multiple components:
* a Firefox Add-on that hosted a pane loaded from the Mozilla F1 service that facilitated posting ('sharing') content across multiple services
* a back-end that abstracted the 'sharing' process such that a core set of common functions to facilitate easy incorporation of addition services without client updates
 
Rather than providing a detailed assessment of how messages are passed between the various components, this diagram illustrates how the different components interact with one another, but not details about the interactions, or what data is shared between them.
 
The goal of this diagram is to provide a concise overview of the system that provides a frame of reference when someone new to the system is reviewing supporting documentation or code.
 
==== Key Attributes ====
* Clarity; brief descriptions of which components are communicating
* Illustrates the boundaries between different services
 
==== Additional Examples ====
*  [https://people.mozilla.com/~yboily/identity/assets/images-1/s31.b.jpeg BrowserID Protocol High Level]
*  [https://people.mozilla.com/~ckoenig/App-Marketplace.jpg Apps MarketPlace] TODO - Replace Me With A Simple Diagram!


=== Detailed Application Diagram ===
=== Detailed Application Diagram ===
A Detailed Application Diagram is essentially a Data-flow diagram;  a data flow diagram enumerates each application or service that is a component of a system, and illustrates each of the paths data can flow through.
The SimplePush server has been greatly simplified from the standard protocol in order to meet expected load issues. Where possible, stateful data has been eliminated or factored against (e.g. the normal protocol defines that the client return a list of known ChannelIDs for a given UAID that the server would filter incoming requests against. Since the client discards unknown ChannelIDs, the decision was made that those ChannelIDs would be passed to the client, and left to the client to discard.)
 
 
[https://wiki.mozilla.org/images/2/22/BrowserID-Threat-Model.png BrowserID Detailed Diagram]
 
Note that a data-flow diagram is only one example of how this information.  The goal is to effectively communicate to the audience how data moves through the system, where different operations are performed, and if detailed enough, how different roles within the system can access different operations.


When designing the detailed application diagram it can be useful to assemble a list of each of the subjects in a system.
There is some consideration being made that the data *not* be written to memcache immediately, but only if the client fails to ACK the data as it's being sent (client is offline or fails to ACK data sent by the connected server thread).
 
 
TODO - add references for subject/object/operations in relation to access control models.
 
==== Key Attributes ====
* Clarity; labels for objects are brief, and contain clear references that can be used to cross-reference other documentation
* Detailed; ensure that all roles and operations are clearly presented
 
==== Additional Examples====
* [https://wiki.mozilla.org/images/b/bf/MozillaF1-Diagram.png Mozilla F1 Detailed Application Diagram]
* [https://wiki.mozilla.org/images/e/ee/BrowserID-Protocol.png BrowserID Protocol]
* [https://people.mozilla.com/~ckoenig/App-Marketplace.jpg AppStore Threat Model]


=== Data-flow Enumeration ===
=== 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"
{| border="1" class="fullwidth-table"
Line 229: Line 140:
| align="center" style="background:#f0f0f0;"|'''Description'''
| 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"
|-
|-
|1.D||Identity Authority||Implementation Provider||The IP saves the keypair in the client
|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
In addition to including the subject, object, operation columns, it can be helpful to include an explicit list of fields which are considered sensitive.
|-
 
|4a||Client||App|| (OUT OF BAND) The client relays the Endpoint to the app, which then communicates it back to 3rdPartyServer for later use.
 
|-
==== Additional Examples ====
|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
* [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#1._Provisioning BrowserID Data-flow Enumeration]
 
=== Threat Analysis ===
 
When performing a security review of an application one of the most important components is a threat analysis.  There is a great deal of documentation on how to perform threat analysis, and a number of different techniques that can be used:
 
* [https://www.owasp.org/index.php/Threat_Risk_Modeling OWASP Threat Risk Modelling]
* [http://msdn.microsoft.com/en-us/security/aa570413 Microsoft Application Threat Modelling]
* [http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf NIST Risk Management Guide][pdf]
 
For the purposes of a Mozilla Security Review, the means by which someone identifies the threats and risks associated with an application is important, but not specified.  If you have questions about how to perform this type of analysis, please contact a member of our team! 
 
The resulting threat analysis should be formatted in a clear format, including the following details:
 
* ID - a identifier for the threat
* Title - a concise description of the threat
* Threat - a description of the threat
* Mitigations - a recommendation for a control that can be implemented [1]
* Threat Agent - a list of the potential actors considered that would exploit a vulnerability.
* Notes - Related comments that contribute to the analysis, but don't belong in other columns
* Rating - A qualitative scoring for a vulnerability in the context of this application [2]
* Impact - A qualitative score representing the impact should a vulnerability be exploited
* Likelihood - A qualitative score representing the likelihood of a vulnerability being exploited. [3]
 
See [https://wiki.mozilla.org/Security/RiskRatings Risk Ratings] for details of how to calculate the qualitative scores.
 
TODO - Glossary Threat, Threat Agent, Vulnerability, Exploit
[1] In the case of a threat analysis that contains multiple threats that can be resolved by one or more different controls it may be beneficial to include a separate control table, and list references to controls in that table instead.
[2] The rating is calculated by multiplying the impact by the likelihood.  This is a naive method, but it's what we have!
[3] In the case where different threat agents have different likelihoods, list the likelihoods highest to lowest, in the same order as the threat agents.
 
Below is an excerpt from the [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#Threat_Model BrowserID Threat Analysis]:
 
{| border="1" class="fullwidth-table sortable"
| align="center" style="background:#f0f0f0;"|'''ID'''
| align="center" style="background:#f0f0f0;"|'''Title'''
| align="center" style="background:#f0f0f0;"|'''Threat'''
| align="center" style="background:#f0f0f0;"|'''Proposed Mitigations'''
| align="center" style="background:#f0f0f0;"|'''Threat Agent'''
| align="center" style="background:#f0f0f0;"|'''Rating'''
| align="center" style="background:#f0f0f0;"|'''Likelihood'''
| align="center" style="background:#f0f0f0;"|'''Notes'''
| align="center" style="background:#f0f0f0;"|'''Impact'''
| align="center" style="background:#f0f0f0;"|'''Notes'''
|-
|-
| 1||SIA may introduce compliance issues||Operating a Secondary Identity Authority may induce compliance requirements with regards to logging user information||Part of the goal of BrowserID is to have Primary Identity Authorities take on this risk as part of their other operations.  This can be somewhat mitigated by eliminating support for the webfinger verification process.||Governments, Lawyers||12||3||Governments and other legal actors have the ability to request  information from us, either through subpoenas, NSLs, etc.  While we hold information that can link user identities to services this information will be a source of risk.||4 – Reputation||Although we are required to comply, and Mozilla would fight such a request to the degree permitted, we would still receive negative press.
|5a||Server||Client|| IFF the client is actively connected, Server conducts a flush (See step 3*)
|-
|-
| 2||Webfinger Information Leak||Use of the webfinger service for verification discloses each authentication attempt from the Relying Party to the Identity Authority||Implement verification using certificates||Malicious Identity Authority||25||5||This information disclosure is a part of the protocol.||5 – Privacy||This is probably a clear violation of our privacy policies.
|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.
|-
|-
| 3||Chrome Code Injection||Attacker controlled parameters could permit injection of script into browser chrome.||Ensure that any data controlled by the user or relying party is emitted using output encoding.||Malicious Relying Party, Malicious User, Malicious Identity Authority||4||1||Code review and testing should prevent this occuring.  The technical complexity of this attack is higher than a vanilla XSS.||4 – User||This gives an attacker the ability to execute code in the context of browser chrome.
|}
|}


=== Threat Analysis ===
A good deal of effort was put forth to reduce the amount of usable data and value of attack for this product.


==== Additional Examples ====
The service is designed to allow remote sites to "wake" an app on a user's device. All actual function happens on the client. If an attacker manages to either identify or use the two UUID4 entries, the most they could do is repeatedly wake an application until the app decides to re-register another ChannelID. An attacker could use this to possibly reduce battery life or increase data costs for a user, but even then, there are much more effective means of doing this.
* Mozilla F1 Threats [https://wiki.mozilla.org/Security/Reviews/F1#Threat_Model]
* BrowserID Threats [https://wiki.mozilla.org/Security/Reviews/Identity/browserid#Threat_Model]


=== Security Testing ===
=== Security Testing ===


The security test plan is a brief explanation of security testing that should be performed, and should include an explanation of what tasks are to be performed, and the approximate amount of time spent performing those tasks.
The security test plan is a brief explanation of security testing that should be performed, and should include an explanation of what tasks are to be performed, and the approximate amount of time spent performing those tasks.

Latest revision as of 19:54, 19 November 2013

Access Information

How is the application accessed?

Application is accessed in two ways. The client accesses via a WebSock connection. Third party servers access via a single REST PUT call.

Is the application internal or publicly available

This application is publicly available.

If it is internal, what mechanism prevents non-members from accessing it?

N/A

Are there links to user-only resources displayed to non-users?

No user information is displayed. In fact, very little information is actually stored or used in this application.

Are login pages secured with SSL over HTTPS?

There are no Login pages.

If HTTPS is used, is Strict Transport Security set?

Infrastructure and Backends

What languages do the applications use?

The application was written in Go.

What database language is used if applicable?

The application uses Memcache as a generic key/value data store.

Are the running versions up to date?

Currently running: go version devel +79a1fec35802 Fri May 24 12:37:42 2013 -0400 linux/amd64 memcached 1.4.13

What server is it running on?

Currently, the application is running on an AWS dev machine. ec2-54-244-98-201.us-west-2.compute.amazonaws.com (I can provide you general use ssh keys or you can provide a public key for OpsSec use.)

Accounts and Passwords

While there are technically "accounts" no password is maintained for these. UAIDs are generated by the client and used solely to identify itself to the server.

Update Information associated with a given client is stored as a pair of UUID4 values. A User Agent ID (UAID) and a ChannelID. There is an option for REST endpoint hashing which uses a simple,reversible AES hash to prevent third party sites from potentially gaining unwarranted information about the connecting clients.

Session Management

No Session cookies are used.

Third-Party Resources

Only third party resources are source libraries included in the binary application.

This code has been reviewed both by the golang community at large and by the local engineer.

Data Handling

What kind of data is transferred between the user and the application?

Client sends identifying UAID, and known channels (channels are ignored) Server returns list of channel updates for a given UAID (invalid channels are ignored by client) Third party server sends a PUT request to an Server generated endpoint triggering a channel update if valid, associated data for the PUT request is ignored.

Is this data generated by the user or generated automatically?

All data is programatically generated.

Can the data be trusted?

Generally, yes. Incoming data from the client is mostly ignored.

How is the data sent to the application (i.e. JSON format, plain-text, GET/POST, etc.)?

WebSocket uses JSON as the transport protocol.

How is the data handled by the server/application?

Server merely registers a self-expiring timestamp value in Memcache when a UAID.ChannelID pair is received.

Can the data be manipulated in transit?

Yes. Manipulation is irrelevant.

What happens if the data is altered?

Nothing. Client still receives the update.

What is done with the data once it is received (i.e. stored in a database, displayed to users)?

It is stored into Memcache, and then the client is notified if attached. If the client is not attached, an optional proprietary wake signal may be sent (out of band for this review) at which time the remote device may reconnect and accept the updates, sending an ACK message after receipt.

Is any data storage done via cookies? If so, what kind of data is stored via this method?

No.

Uploaded Data

There is no user meaningful data stored using this service.

Data Sensitivity

What kind of data is being stored and/or manipulated by the application?

A timestamp value is stored. This value is simply a placeholder as any data value could be used.

Does this data need to be encrypted in transit? In storage?

No.

What is the impact if this data is lost/stolen?

Someone just created a really annoying NNTP server.

Is secure/sensitive data sent over SSL?

No senstitive data is exchanged.

Application Administration

All real service management is performed locally by the client service. The server is gleefully ignorant of anything other than the user UAID.

Security Coding Flaws

Have all user inputs been sanitized?

Yes

Is a maximum size for data (input or uploads) defined?

No, data is discarded.

Do all URL variables pass through sanitization?

No, data is discarded.

Is data from databases escaped properly?

Yes

Are CSRF tokens used to prevent POSTs from outside websites?

POST values are not allowed.

If a database is used, are protections against SQL injection in place?

Database is not SQL based.

Is validation done on the server side (not just client-side)?

Data is discarded.

Is output encoded in addition to sanitization of input?

No.

Does the user ever send data to the OS level?

No.

Are x-frame options sent to “deny” or “sameorigin”?

No frames are used.

Is debug mode disabled?

Debugging merely increases logging output, and is controlled via server config options.

Additional Resources

Template for the above checks: https://docs.google.com/document/d/1SAzDuMwKUNN4_gdotqcv0oeZwLngjXjNYuZ2HZZaXp4/edit

Also, please view the WebAppSec Wiki: https://wiki.mozilla.org/WebAppSec

Security Review Documentation

Structure of a Security Review

This document covers five distinct activities and the documentation they produce when a security review is performed. Note that this guidance is prescriptive in that each component of a security review document should be produced, or a statement explaining why it wasn't should be included.

The goal of this document is to ensure that the Security Assurance team has a consistent format for the documentation we produce without enforcing a strict structure on how security review and testing is performed.

Architecture Diagram

L5LC0tj.png

External services, marked in yellow, communicate to the server which acts as a notification event proxy.

Detailed Application Diagram

The SimplePush server has been greatly simplified from the standard protocol in order to meet expected load issues. Where possible, stateful data has been eliminated or factored against (e.g. the normal protocol defines that the client return a list of known ChannelIDs for a given UAID that the server would filter incoming requests against. Since the client discards unknown ChannelIDs, the decision was made that those ChannelIDs would be passed to the client, and left to the client to discard.)

There is some consideration being made that the data *not* be written to memcache immediately, but only if the client fails to ACK the data as it's being sent (client is offline or fails to ACK data sent by the connected server thread).

Data-flow Enumeration

ID Origin Destination Description
1 Client Server Client connects via WebSocket protocol and sends a "hello" JSON packet containing the clients UAID.
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.
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.

Threat Analysis

A good deal of effort was put forth to reduce the amount of usable data and value of attack for this product.

The service is designed to allow remote sites to "wake" an app on a user's device. All actual function happens on the client. If an attacker manages to either identify or use the two UUID4 entries, the most they could do is repeatedly wake an application until the app decides to re-register another ChannelID. An attacker could use this to possibly reduce battery life or increase data costs for a user, but even then, there are much more effective means of doing this.

Security Testing

The security test plan is a brief explanation of security testing that should be performed, and should include an explanation of what tasks are to be performed, and the approximate amount of time spent performing those tasks.

Retrieved from "https://wiki.mozilla.org/index.php?title=CloudServices/Roadmaps/SimplePush-Server/SecCodeReview&oldid=765759"