776419 - [Security Review][Action Item] Investigate marketplace JWT generation code

Status: RESOLVED WONTFIX

(Marketplace Graveyard :: General, defect)

Description

[Paul Theriault [:pauljt] (no longer reading bugmail)]

It is proposed that the marketplace will provide a feature that generates JWT for payments, so that apps don't need to manage app keys, or handle the generation of JWT code themselves. Exactly how this will work is currently being defined - this action is raised to track and review this feature.

Comment 1

[Kumar McMillan [:kumar]]

I'd like to get more info on how exactly this is proposed to work. I can't think of any way to do it that doesn't leave us vulnerable to the same DNS attacks that gives everyone free apps/goods on iOS http://gizmodo.com/5925795/this-method-to-get-iphone-and-ipad-in%20app-purchases-for-free-is-surprisingly-easy

Comment 2

[Kumar McMillan [:kumar]]

If the DNS / SSL attack risk is acceptable we could provide a JWT verification service as a possible solution here. We had this idea once, detailed in bug 740175

To be fair to Apple, it looks like they do provide documentation for how apps should verify receipts on their *own* server but the app developers never seem to actually do it. We could easily face the same problems.

Comment 3

[Antonio Manuel Amaya Calvo (:amac)]

Actually no. We face different problems :) On our implementation, the JWT must be checked only on the server side. In fact, the client side should not even have the data required (shared secret) to verify the JWT (because if it had, then it wouldn't be secret anymore). And in fact the receipt isn't event sent to the client, it's sent to the developer's server.

The problem we face thus is that while on Apple having a server presence for developers is optional, for us is mandatory. But the DNS/cert spoofing won't affect us. Well, unless developers decide that if onSuccess is called then the payment has been processed and they can give access. But if they do that, it would be probably easier for an user to just modify the app and call whatever onSuccess do on load time. Or just download it.

As I see it, anyway, payments on this scheme only make sense for server provided content. Because it's just client access, everything is going to be pirated to death.

Comment 4

[David Chan [:dchan]]

The current requirement is that a developer must have their own signing server. The developer also must register with payment providers to generate a secret used for signing requests. The secret only exists between the server and the payment processor which allows webapps to send a signing request to the developer server.

My understanding of this bug is that instead of the signing server being run by the developer, it would be run by the marketplace. This introduces additional complications in how to guard the app secrets and how the setup workflow would be. The rest of the receipt signing / checking workflow should be unchanged.

I'm assuming that the use case is for pure client apps with no server component.

Comment 5

[David Chan [:dchan]]

Looks like bug #776644 that Kumar is working on is what we want to review

Comment 6

[Fernando Jiménez Moreno [:ferjm]]

(In reply to David Chan [:dchan] from comment #4)
> The current requirement is that a developer must have their own signing
> server. The developer also must register with payment providers to generate
> a secret used for signing requests.
> The secret only exists between the server and the payment processor which allows 
> webapps to send a signing request to the developer server.

Apart from the developer server and the payment processor, the Marketplace would also share the app secret, in order to sign payment requests for application purchases on behalf of the developer.

> 
> My understanding of this bug is that instead of the signing server being run
> by the developer, it would be run by the marketplace. 

Yes.

The current status is that the developer is responsible for creating, encoding and signing his payment requests in the form of JWTs. All this work should be done on the developer's server.

The way I get the proposal is that the Marketplace would *expose* his JWT encoding and signing functionality as a service, so the developer could use it to encode and sign his payment requests. Apart from that, postback and chargeback verification services could also be exposed.

Anyway, I heard about this feature request a few days ago and I am probably not the best one to explain it, so I am CCing Ernesto Jiménez (TEF product manager) and Andreas Gal.

> This introduces
> additional complications in how to guard the app secrets and how the setup
> workflow would be. The rest of the receipt signing / checking workflow
> should be unchanged.
> 

As I mentioned before, it is planned that the Marketplace shares the app secret generated by the payment provider. For the specific case of TEF payment provider (BlueVia), all the interactions between the Marketplace and BlueVia regarding developers and app registration are mostly agreed and the integration efforts should be on good track.

> I'm assuming that the use case is for pure client apps with no server
> component.

I am not a security expert, so please correct me if I am wrong, but I can't see how that can happen on a secure way. Even if the Marketplace exposes all this functionality we are talking about, there would need to be a way to identify the app and secure the communication between the (client) app and the Marketplace, and the only ways that I can think about involves a B2B communication. So the way I see it, the application would still need to have a server side.

Comment 7

[Fernando Jiménez Moreno [:ferjm]]

Reading my previous comment I realized that the benefits of exposing a JWT generation tool by the Marketplace are not clear enough.

The main reason is, obviously, to ease the development process as much as possible. By delegating the JWT generation and verification responsability to the Marketplace, we might achieve:

- The developer wouldn't need to worry about setting up new payment providers on his application. All that he would need to do is just set up the new payment method on his Marketplace account.

- The developer wouldn't need to handle currency conversion on his application.

- The developer wouldn't need to do any server side crypto verification.

Comment 8

[Antonio Manuel Amaya Calvo (:amac)]

> > I'm assuming that the use case is for pure client apps with no server
> > component.
> 
> I am not a security expert, so please correct me if I am wrong, but I can't
> see how that can happen on a secure way. Even if the Marketplace exposes all
> this functionality we are talking about, there would need to be a way to
> identify the app and secure the communication between the (client) app and
> the Marketplace, and the only ways that I can think about involves a B2B
> communication. So the way I see it, the application would still need to have
> a server side.

I think there are two different scenarios here: 

* Buying complete apps on the Market. The app can be a pure client app with no server whatsoever, but from the point of view of the application you're using to buy the app (the Market app) the app being sold is just an special case of server side content, the cotent in this  case being the app. The transaction data is generated and verified on the market server. This, on the other hand, is the same than using the AppStore to buy applications, and isn't affected at all by the DNS/SSL tampering by the user. 
* A third party application wants to sell some in-app content (in-app purchases). In this case, in Apple's model, the developer can opt for not having a server at all (and be vulnerable to fraud) or having a server and verifying the receipts there (and thus avoid this kind of fraud). On our model the server is mandatory since the developer has to provide a callback URL to the payment provider to be informed of the success or failure. And because otherwise he would have to expose the secret on the app, as Fernando said, and thus it would not be a secret anymore. 

And what I was trying to say about server side content, is that in any case if the inapp payment is use to activate something that is already on the app, DNS fraud will be the less of his problem, considering anyone that buys the application will have access to it's source code. It's easier to just modify the app so it gives access to all the features than fooling it into believing its been paid for. 

Hope this arrive well formatted. I'm on vacation and writing on a phone screen isn't the best experience :)

Comment 9

[Kumar McMillan [:kumar]]

To clarify:

The original plan was to require an app to always use its own server to verify an in-app payment JWT with a shared secret key. This bug asked for a way to make it easier for developers so they do not need to verify JWTs on their own server.

Proposals:
1. "marketplace JWT generation code" -- I don't know what this means.
2. marketplace could provide a JWT verification service. This would allow apps to receive JWTs client side (or server side for more security) and make a POST to https://marketplace/verify-jwt to determine if it is valid or not. For comparison, Persona provides a similar verification service https://developer.mozilla.org/en-US/docs/BrowserID/Remote_Verification_API The app would never have to deal with the shared secret or any crypto libs (which can be hard to compile) at all in this scenario.

Comment 10

[Ernesto Jimenez]

Hi Kumar,

The idea would be to have the marketplace expose an API to:
1. generate the JWT
2. verify the JWT

From your comment in point 2, the app *would have to deal* with the shared secret or crypto libs if we offer 2 but not 1. You still need to deal with those things to generate the JWT.

In any case, developer convenience not having to deal with signatures themselves is just one of the points. As Fernando commented, this would have a set of benefits such as:

- Once the developer has set-up a payment provider, he can just enable a new one without having to change their app server to handle a new shared secret and JWT.

- We can align in terms of currency between Mozilla and BlueVia without the need of the developer to get involved.

- If you offer pricepoints to the developers, the market would enter the final price in the JWT according to the pricepoint selected by the developer. If you changed the price in the future, the developer wouldn't need to change her app server to update it with the new price.

What we discussed previously in the Work Week in Barcelona was having an API which would receive the details of the payment from the app and would return a set of JWT for the payment processors available for that application.

I think Andreas also suggested you would be providing libraries for developers to consume that API.

Comment 11

[Kumar McMillan [:kumar]]

Thanks, I understand the proposal better now. I agree that a generate/verify API like this would be useful and would ease the adoption of the payment system.

Comment 12

[David Chan [:dchan]]

A review of a generate/verify API shouldn't take that long. However I am unclear if we are currently developing the API.

I don't believe I am assigned to write the API, but can assist during the design and testing phases.

Comment 13

[David Chan [:dchan]]

:kumar
Is this still a basecamp feature? If not, I want to close off the bug.

The feature in question is whether marketplace will expose an API for generation / verification of JWT signature. The goal being for an app developer to not have to run a server and manage keys / signing themselves.

Comment 14

[Kumar McMillan [:kumar]]

Since this bug was filed we changed course on payments. For the v1 launch we will no longer require developers to create multiple JWTs -- they only have to create one JWT. It will be well documented on MDN or maybe here https://wiki.mozilla.org/WebAPI/WebPayment so I don't think a JWT code generator is needed anymore. If we need to add a generator in the future we will design one and bounce it off security for review.