Security/Reviews/InAppPayment
Item Reviewed
In App Payment | |
Target | https://github.com/mozilla/apps-payment-server/blob/master/DESIGN.md
https://etherpad.mozilla.org/in-app-purchase-2012-03-21ref: http://datatracker.ietf.org/wg/jose/ |
Introduce the Feature
Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)
- in apps marketplace, an app will be able to initiate an in-app payment
- such as the purchase of virtual goods (and only virtual goods)
- The goal of an in-app payments API is to allow web content to initiate a payment from the user to a web application, with these properties:
- The application does not receive any payment card data from the user
- The user is only required to enter her payment card data once (shall we say, "per account" - but somewhere on the order of once a year or less)
- The payment card data is stored in a way that satisfies PCI DSS requirements
- The user receives clear, cancellable confirmation of what the payment will entail, from a non-spoofable source.
- The application receives clear, non-repudiatable confirmation that a payment has been completed, and has an audit trail to allow efficient responses to chargebacks and attempted fraud
- It is a non goal to support payments for non-virtual goods. The legal requirements involved in the purchase (and shipping) of goods are significantly different.
For Mozilla
- Mozilla-operated servers do not persist payment card data and payment card data does not transit a Mozilla-operated server.
- Mozilla must assume that the client is under the control of the attacker; we do not have a secure client on which we can position keys or secrets.
- The payment system should work in any modern browser, desktop or mobile, and should be a very smooth and easy experience on Firefox browsers.
Optional Goals
- The user should not be required to re-enter a PIN or password for every transaction; making a purchase should unlock payments for a short period of time. (I think this is a nice-to-have and maybe a bad idea in some cases).
What solutions/approaches were considered other than the proposed solution?
N/A
Why was this solution chosen?
(see other sections or information)
Any security threats already considered in the design and why?
- secret key with JSON web token for trusting a proper product and price
- signed not encrypted
Threat Model
- There are many ways an attacker could abuse an in-app payments model. The big ones are:
- A malicious application could make charges without a user's knowledge, or for a larger amount than the user expects
- A malicious application could make charges and then not provide the user with the expected service or content
- A malicious user, or network intermediary, could try to intercept payment flows from an app, to redirect funds to his own account
- A man-in-the-browser attacker could try to drive payment activities and confirmations in order to drive payments to a target site
- A malicious user could try to impersonate a payment API provider to fool the app into thinking a payment was completed
- A network attacker could try to capture the user's payment card data, or the user's payment authorization, by attacking servers
- The system could be so hard to use that nobody uses it.
Threat Brainstorming
- a malicious app can replay buy requests. we need a nonce or something to make sure a single buy request only happens once. (Can nonce the request with issued at time)
- feature idea: set per-device in-app payment protection (a timeout? a reauth?). Use case is to stop kids from making lots of purchases :)
- Property "SecReview feature goal" (as page type) with input value "* in apps marketplace, an app will be able to initiate an in-app payment
- such as the purchase of virtual goods (and only virtual goods)
- The goal of an in-app payments API is to allow web content to initiate a payment from the user to a web application, with these properties:
- The application does not receive any payment card data from the user
- The user is only required to enter her payment card data once (shall we say, "per account" - but somewhere on the order of once a year or less)
- The payment card data is stored in a way that satisfies PCI DSS requirements
- The user receives clear, cancellable confirmation of what the payment will entail, from a non-spoofable source.
- The application receives clear, non-repudiatable confirmation that a payment has been completed, and has an audit trail to allow efficient responses to chargebacks and attempted fraud
- It is a non goal to support payments for non-virtual goods. The legal requirements involved in the purchase (and shipping) of goods are significantly different.
For Mozilla
- Mozilla-operated servers do not persist payment card data and payment card data does not transit a Mozilla-operated server.
- Mozilla must assume that the client is under the control of the attacker; we do not have a secure client on which we can position keys or secrets.
- The payment system should work in any modern browser, desktop or mobile, and should be a very smooth and easy experience on Firefox browsers.
Optional Goals
- The user should not be required to re-enter a PIN or password for every transaction; making a purchase should unlock payments for a short period of time. (I think this is a nice-to-have and maybe a bad idea in some cases)." 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 "* secret key with JSON web token for trusting a proper product and price
- signed not encrypted
Threat Model
- There are many ways an attacker could abuse an in-app payments model. The big ones are:
- A malicious application could make charges without a user's knowledge, or for a larger amount than the user expects
- A malicious application could make charges and then not provide the user with the expected service or content
- A malicious user, or network intermediary, could try to intercept payment flows from an app, to redirect funds to his own account
- A man-in-the-browser attacker could try to drive payment activities and confirmations in order to drive payments to a target site
- A malicious user could try to impersonate a payment API provider to fool the app into thinking a payment was completed
- A network attacker could try to capture the user's payment card data, or the user's payment authorization, by attacking servers
- The system could be so hard to use that nobody uses it." 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 "* a malicious app can replay buy requests. we need a nonce or something to make sure a single buy request only happens once. (Can nonce the request with issued at time)
- feature idea: set per-device in-app payment protection (a timeout? a reauth?). Use case is to stop kids from making lots of purchases :)" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
Action Items
Action Item Status | In Progress | ||||||||||||||||||||||||||||||||||||
Release Target | ` | ||||||||||||||||||||||||||||||||||||
Action Items | |||||||||||||||||||||||||||||||||||||
4 Total; 1 Open (25%); 2 Resolved (50%); 1 Verified (25%); |
Who Action By When Completed date [NEW] new [DONE] Done [MISSED] Miss
mark giffin (MDN team) bug 740828 confirm that apps have a server to provide trusted connection between appserver and marketplace before marketplace rollout [NEW] new
markmayo bug 740824
how do we protect app secrets in the marketplace database? encrypted with a local key? encrypted with the HSM? (or equivalent protection
blocker) by marketplace rollout
[NEW] new
mark giffin (MDN team)bug 740830
what do app servers do in case of AppSecret compromise? need revocation/replacement mechanism (write up for MDN)
before marketplace roll-out. (for marketplace support of this feature, see bug 738368
[DONE] done
ID | Summary | Priority | Status |
---|---|---|---|
738368 | Allow developers to revoke compromised in-app payment secret | P2 | VERIFIED |
740824 | [Security Review][Action Item]In App Payment - App Secrets Protection | -- | RESOLVED |
740828 | [Security Review][Action Item]In App Payment - trusted connection | -- | NEW |
740830 | Secreview: In App Payment - AppSecret revocation/replacement | -- | RESOLVED |
4 Total; 1 Open (25%); 2 Resolved (50%); 1 Verified (25%);
" contains strip markers and therefore it cannot be parsed sufficiently.