Security/Reviews/AppStore: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 230: Line 230:


=== Critical Security Requirements ===
=== Critical Security Requirements ===
Itemize individual security blockers here. Reference components in section AppSec or OpSec subsections.
PIN required for purchases and in-app purchases. https://bugzilla.mozilla.org/show_bug.cgi?id=759021
These blockers must be addressed before the product can go live.


== Stage 4: Development ==
== Stage 4: Development ==

Revision as of 05:20, 28 May 2012

Status

Apps (Marketplace)
Tracker Bug bug 680570
Stage
Status Green (Green, Yellow, Red?)
Release Target
Health -
Status Note

Team

Product manager Ragavan Srinivasan
Feature manager -
Engineering lead Wil Clouser
Security lead Raymond Forbes
Privacy lead
Localization lead -
Accessibility lead -
QA lead -
UX lead -
Product marketing lead -
Additional members -

Open issues/risks

  • TODO Determine different purchase options and basic flow link
  • TODO Determine actual data stored on mozilla servers from purchases
  • TODO Determine data flow for checkout

Stage 1: Definition

Introduction

Include brief summary of feature/project, and link back to core feature/product pages. Links:

Use Cases

Published Docs

Data Types

Data Name Description Origin Classification Temporal Length
payKey identifier for payment specifics paypal private ephemeral
refund token submitted with paykey to facilitate refunds paypal private stored
seller paypal email identifier for paypal account AMO private stored
invoice ID uniquily identify transaction AMO private stored
trackingID uniquily identify transaction AMO private stored
payment status status of payment. Completeted, failed, pending, etc paypal private stored
refund status status of.refund Completeted, failed, pending, etc paypal private stored
pre-auth key allows direct purchases to paypal paypal private stored

Data Flows

Diagram

Appstore purchase dfd.png In-app payments.jpg

Architecture Diagram

Stage 2: Design

Threat Model

ID Title Threat Proposed Mitigations Threat Agent Rating Likelihood Impact Notes
1 Compromise Paypal API Key The Paypal API key is used for communication with paypal and identifies Mozilla. If this key is leaked, it is possible to impersonate Mozilla to Paypal. Separation of payment systems from the rest of AMO. Incident response process to include communication with payal to disable API key. Proper CEF logging key. Skilled Attacker 12 3 4 – Reputation
2 Compromise AMO database Currently, customer's paypal information resides in the AMO database. If the AMO database is compromised this would include paypal information. Separation of payment data from the rest of AMO. Incident response process to include communication with payal to disable pre-auth keys. Proper CEF logging key. Skilled Attacker 12 3 4 – Reputation for an actual compromise, this would require the paypal API key as well.
3 malicious access to apps device If a phone is stolen or given to a friend/family member, it is possible for that person to make purchases. A PIN is to be implemented that is required for purchases and in-app purchases. CEF logging on transactions to track excessive purchases. Incident response to deal wiht stolen phone. Malicious User 12 3 4 – Reputation In other systems (i.e. iOS, this i a configured parameter.
4 Malicious extension could steal browserid credentials A rogue extension could possibly steal credentials or cause transactions to happen. A PIN is to be implemented that is required for purchases and in-app purchases. CEF logging on transactions to track excessive purchases. Incident response to deal with stolen credentials. Malicious Developer 12 3 4 – Reputation It is not possible to siphon funds to any paypal account. Must be registered with marketplace.
5 Malicious App creates fake iframe An app could create an iframe in order to overlay a purchase iframe. A PIN is to be implemented that is required for purchases and in-app purchases. CEF logging on transactions to track excessive purchases. Incident response to deal with stolen credentials. Paypal account shows all purchases. Malicious App 12 3 4 – Reputation
6 Malicious App creates fake iframe An app could create an iframe in order to overlay a purchase iframe. A PIN is to be implemented that is required for purchases and in-app purchases. CEF logging on transactions to track excessive purchases. Incident response to deal with stolen credentials. Paypal account shows all purchases. Malicious App 12 3 4 – Reputation


User Interactions

Client Interactions

Server Interactions

Security Recommendations / Open Issues

CEF Logging Requirements

Authentication

  • bad password provided at login (or anywhere where user is prompted for auth)
  • bad username provided at login
  • account created
  • password changed
  • password reset requested
  • new privileged (e.g. reviewer, admin, etc) account created
  • account modified and granted additional rights (e.g. reviewer, admin, etc)

Authorization

Paypal

  • failed purchase

Denial of Service

Request Specific

Input Validation Exceptions

File Upload

  • Large number of file uploads
  • Attempt to upload something other than expected file

Business Test Cases

Document application specific test cases here

Privacy Risk Analysis

(Status of and link to privacy review and outcome here)

Stage 3: Planning

Application Security Requirements

Document individual requirements for the application here (e.g. CEF logging, captcha, etc)

It is expected that the Secure Coding Guidelines is followed but these requirements are especially important for this application.


Password Requirements

  • Threshold based CAPTCHA for login Restrict password guesses without CAPTCHA to 5.
  • Blacklist top bad passwords that could be selected by a user.

Account Requirements

  • Allow users to view last login time and IP address after authentication

Coding Requirements

  • Session based CSRF protection (e.g. not Django cookie based CSRF protection)
  • Clickjacking (x-frame-options) and XSS protection (CSP)

Other Requirements

  • Uploaded links must be verified against google safe browsing list (real time or daily cron)
  • Uploaded images must be strictly checked to validate only images are uploaded. More Info

SSL Requirements

  • SSL is required to the connection to paypal (user redirects and any backend connections)
  • The SSL cert must be strictly validated (specific code needed for backend connections)
  • HSTS must be enabled
  • No HTTP pages. Full HTTPS
  • Third party connections (e.g. twitter, facebook, paypal, etc) must link to the HTTPS page for that site. That may require rewriting the widget (twitter specifically)

Operation Security Requirements

Document network/platform security requirements here (e.g. IDS concerns, firewall changes, system hardening reqs, etc)

  • Secure Crypto Storage - HSM device needed for secure storage of any critical crypto keys
  • Separate & isolated network and storage devices required for appstore
  • AuditD - on all AppStore Servers - Bug 683747
  • OSSEC - on all AppStore Servers - Bug 683747


Mana Website Creation Form

Critical Security Requirements

PIN required for purchases and in-app purchases. https://bugzilla.mozilla.org/show_bug.cgi?id=759021

Stage 4: Development

Repeatable Security Test Cases

Document individual repeatable security test cases here. Include a reference to the source repo, and documentation that governs how to execute test cases.

Secure Coding Guidelines

Document specific secure coding guidelines to be followed and relate them to specific issues/requirements that are specified; capture bug ids related to those issues.

Code Review Milestones

Table 1 - itemized list of code review milestones {i.e. breakdown of specific components that will be reviewed} Table 2 - list of app components/modules that should trigger additional security review (e.g. auth, csrf, file upload handling, etc)

Stage 5: Release

Application Security Verification

These subsections should contain a list of the steps to be taken, and the status of each activity

Code Review

Automated Security Testing

Manual Security Testing

Operational Security Verification

ArcSight Information

Network Design Security Review

Database Security Review

Platform Security (Hardening & Specific Config Requirements)

Landing Criteria

This should be a table itemizing everything from Stage 3 - Critical Security Requirements, including status. For status Red=Unimplemented,Yellow=implemented,Green=tested and passed?

Stage 6: Post Implementation Review

Production Security Considerations

Document additional/ongoing work for this application (e.g. specific things to watch for in ArcSight, gaming behaviour, etc)

Post Implementation Tasks

Itemize process/kb changes developed from this project (e.g. secure coding guidelines, policy stuff, etc)


Team status notes

status notes
Products tbd -
Engineering tbd -
Engineering tbd -
Engineering tbd -
Engineering tbd -
Engineering tbd -
Engineering tbd -
Engineering tbd -
Engineering tbd -