Security/Reviews/InAppPayment

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.

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-21
ref: 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:
  1. The application does not receive any payment card data from the user
  2. 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)
  3. The payment card data is stored in a way that satisfies PCI DSS requirements
  4. The user receives clear, cancellable confirmation of what the payment will entail, from a non-spoofable source.
  5. 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
  6. 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

  1. Mozilla-operated servers do not persist payment card data and payment card data does not transit a Mozilla-operated server.
  2. 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.
  3. 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

  1. 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:
  1. A malicious application could make charges without a user's knowledge, or for a larger amount than the user expects
  2. A malicious application could make charges and then not provide the user with the expected service or content
  3. A malicious user, or network intermediary, could try to intercept payment flows from an app, to redirect funds to his own account
  4. A man-in-the-browser attacker could try to drive payment activities and confirmations in order to drive payments to a target site
  5. A malicious user could try to impersonate a payment API provider to fool the app into thinking a payment was completed
  6. A network attacker could try to capture the user's payment card data, or the user's payment authorization, by attacking servers
  7. 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:
    1. The application does not receive any payment card data from the user
    2. 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)
    3. The payment card data is stored in a way that satisfies PCI DSS requirements
    4. The user receives clear, cancellable confirmation of what the payment will entail, from a non-spoofable source.
    5. 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
    6. 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

    1. Mozilla-operated servers do not persist payment card data and payment card data does not transit a Mozilla-operated server.
    2. 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.
    3. 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

    1. 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.
    2. 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:
    1. A malicious application could make charges without a user's knowledge, or for a larger amount than the user expects
    2. A malicious application could make charges and then not provide the user with the expected service or content
    3. A malicious user, or network intermediary, could try to intercept payment flows from an app, to redirect funds to his own account
    4. A man-in-the-browser attacker could try to drive payment activities and confirmations in order to drive payments to a target site
    5. A malicious user could try to impersonate a payment API provider to fool the app into thinking a payment was completed
    6. A network attacker could try to capture the user's payment card data, or the user's payment authorization, by attacking servers
    7. 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.
    8. 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
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
Full Query
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%);

The given value "

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


Full Query
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.