Security/Reviews/AppStore
Contents
- 1 Status
- 2 Team
- 3 Open issues/risks
- 4 Stage 1: Definition
- 5 Stage 2: Design
- 6 Stage 3: Planning
- 7 Stage 4: Development
- 8 Stage 5: Release
- 9 Stage 6: Post Implementation Review
- 10 Team status notes
Status
| Apps (Marketplace) | |
|---|---|
| Tracker Bug | bug 680570 |
| Stage | |
| Status | Green (Green, Yellow, Red?) |
| Release Target | |
| Health | - |
| Status Note | |
Team
| Product manager | Rick Fant |
| Feature manager | Caitlin Galimidi |
| Engineering lead | Wil Clouser |
| Security lead | Raymond Forbes |
| Privacy lead | |
| Localization lead | - |
| Accessibility lead | - |
| QA lead | Krupa Raj |
| UX lead | - |
| Product marketing lead | - |
| Additional members | - |
Open issues/risks
Stage 1: Definition
Introduction
Include brief summary of feature/project, and link back to core feature/product pages. Links:
- Primary Apps Home Page
- Meeting Notes
- Web Application Receipt Details
- Mozilla Market Place - Google Doc
Use Cases
Data Flows
Diagram
Data Type Definition
Stage 2: Design
Threat Model
| ID | Title | Threat | Proposed Mitigations | Threat Agent | Rating | Likelihood | Impact | Notes |
| 1 | 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. |
| 2 | 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. |
| 3 | 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. |
| 4 | 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 | |
| 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 | XSS vuln could allow malicious user to force purchase | If a XSS is found in the marketplace, this could be used to force a purchase. | A PIN is to be implemented that is required for purchases and in-app purchases. enable CSP on the marketplace site. 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 | |
| 7 | CSRF could force purchase. | If a XSS is found in the marketplace, this could be used to force a purchase. | A PIN is to be implemented that is required for purchases and in-app purchases. enable CSRF protection token on the marketplace site. 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 | |
| 8 | Compromise AMO web-heads | An attacker able to run arbitrary code on the AMO web-heads can indirectly sign arbitrary web applications that are in the review queue (any web application that passed the automated scan) via the celery service. The attacker can also directly sign a web application by requesting the signing from the signing service, without any further check. | Mitigation possibilities are being discussed. | System access | 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
Move paypal process to independent servers. https://bugzilla.mozilla.org/show_bug.cgi?id=759055
https://bugzilla.mozilla.org/show_bug.cgi?id=759058
temporarily encrypt pre-auth key: https://bugzilla.mozilla.org/show_bug.cgi?id=717444
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?
Incident Response Plan
https://bugzilla.mozilla.org/show_bug.cgi?id=759494
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 | - |
